Storage and application state
Store durable application data in a database or storage service you provision separately. Builder keeps build outputs for deployment, not a customer database, a writable persistent filesystem, or a backup of your data.
Choose storage by purpose
| Data | Where it belongs |
|---|---|
| Static HTML, CSS, images, and frontend bundles | The version's static build output |
| Temporary computation and disposable caches | App-local memory/files only when loss is acceptable |
| Uploads and durable object data | A separately provisioned object store such as Azure Blob Storage |
| Durable records and conversation/session state | A separately provisioned database |
| Credentials | Supported identity or sensitive configuration; centralized secrets accessed by app code where appropriate |
Static output is a deployed artifact, not a runtime upload directory. Changes to static source require another build and deployment. App-owned persistent disks, Azure Files mounts, and writable shared volumes are not exposed in the documented Builder App contract. Do not rely on files written by a web process surviving restarts, redeployments, or replica changes. No filesystem capacity or persistence guarantee is established by this preview documentation.
External storage
Provision the storage service independently, configure an accessible endpoint, and grant only the required data permissions. Use the app's managed identity or the service's server-side authentication, and keep credentials out of browser assets. For Blob Storage, use the Azure Storage identity authorization guidance and the SDK for your language. An Azure management role alone may not grant permission to read or write blobs. Keep uploads private unless intentional, validate file sizes/types, and authorize both upload and download operations.
See connecting to services for the integration checklist and networking for private-endpoint limitations. Builder does not provision or mount the external store automatically. External storage has independent pricing, lifecycle, retention, and backup settings.
Versions, cleanup, and rollback
Retained-version activation restores code and that version's variables; it does not roll back an external database or uploaded files. Design schema and data changes to work with versions you might reactivate. Finite artifact retention does not replace source control or a data backup.
Deleting the Builder App does not delete a separately provisioned database, storage account, vault, or user-assigned identity. Review and remove test data and separately owned resources intentionally. See deployments and versions for retained-artifact behavior.