PRACTICAL FIELD GUIDE
Rehearse an Eject export before you need it
An export becomes an operational exit path only after you have restored and tested it. Rehearse with an appropriate project copy and a clear plan for credentials and hosted-only services.
MCPBackend editorial team · · Examples are illustrative
Put it into practice
- Download the SQL export and project-specific runtime package through the supported flow.
- Configure fresh secrets and a persistent SQLite volume, then start the runtime.
- Verify records, login, row policies and app requests while listing services that need replacement.
What this looks like
ILLUSTRATIVE EXAMPLE
The data API works after restore, but a webhook-driven workflow stops because hosted webhooks are not part of the exported runtime.
A boundary to keep clear
Do not retire the hosted project before verifying the replacement and its backup, monitoring and access setup.
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.