PRACTICAL FIELD GUIDE
Replace hosted API keys when moving to self-hosting
Hosted machine keys are not exported as reusable secrets. The self-host runtime needs its own configured API credential and new application secret references.
MCPBackend editorial team · · Examples are illustrative
Put it into practice
- Inventory the server integrations that use hosted keys.
- Configure the runtime's new key through its secret environment and update intended integrations.
- Test allowed operations and document the self-hosted key's privilege model.
What this looks like
ILLUSTRATIVE EXAMPLE
An app switches the base URL to the exported runtime but continues sending a hosted key. The route exists while authentication fails.
A boundary to keep clear
The portable runtime's configured admin key is not a recreation of every hosted per-table key. Review the access design.
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.