PRACTICAL FIELD GUIDE
Why users sign in again after self-hosting an export
The exported runtime uses a new JWT secret, so hosted user tokens are not a session migration mechanism. Existing compatible password hashes can remain while users establish new sessions.
MCPBackend editorial team · · Examples are illustrative
Put it into practice
- Configure fresh runtime secrets and verify the imported user data in a controlled environment.
- Point the app at the new API and clear old hosted sessions.
- Test login and owner-scoped requests with an existing disposable account.
What this looks like
ILLUSTRATIVE EXAMPLE
An exported account logs in with its existing password but receives a newly signed token from the self-hosted runtime.
A boundary to keep clear
Do not copy the hosted signing secret to preserve sessions. Configure the export's intended secret boundary and plan the sign-in transition.
MCPBackend context
Application email/password authentication is separate from the developer dashboard login and MCP OAuth connection. The current app-user tokens are project-scoped and do not automatically expire. Do not assume built-in refresh, password reset, per-token revocation or social login; check supported behavior before designing those flows.
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.