PRACTICAL FIELD GUIDE
Keep the self-hosted SQLite database on a persistent volume
A running container is not a durable storage plan by itself. The exported runtime imports into persistent storage, which must survive normal container replacement.
MCPBackend editorial team · · Examples are illustrative
Put it into practice
- Inspect the provided volume configuration and the location of the active database.
- Test a normal restart with disposable data and verify persistence.
- Create and test a backup procedure before relying on the self-hosted deployment.
What this looks like
ILLUSTRATIVE EXAMPLE
A container is recreated successfully, but an incorrectly configured ephemeral database disappears with it.
A boundary to keep clear
Removing a data volume is destructive. Do not use volume deletion as a routine restart or update step.
MCPBackend context
Managed hosting and a portable export solve different operational needs. Write/storage caps block writes, while the API-request cap blocks data requests including reads. The exported runtime covers compatible CRUD, auth and row policies; it does not include the hosted dashboard, MCP server, webhooks, billing, metering or managed backups.
Take the next step
Inspect the current project contract, try the change with disposable data, and verify the result through the same credentials your app will use. Record the expected response and one denied-access case before release.
Sources and further reading
These references explain the underlying protocols and design principles. For supported MCPBackend operations and exact request shapes, inspect your project’s generated API contract.