Use your server

Authentication

Q: How is the bearer token enforced?

The check runs inside the deployed container itself, not on foro's own infrastructure in front of it. A small gate injected at build time reads the token and public flag from the container's environment and decides there, so a deployed server keeps authenticating requests correctly even if foro's own API is ever unreachable.

Q: How do I view or rotate the token?

The project's Settings tab shows the token masked, with a reveal toggle and a copy button. Rotating generates a new one immediately: the old token stops working the instant you confirm, and the container restarts to pick up the new value. There is no way to recover the old token once it's replaced.

Q: What happens if I make a project public?

The token check turns off entirely - anyone with the URL can call the server without a header. That fits something meant to be freely reachable, like a shared demo, and does not fit anything touching a real credential or real data, since there is no per-caller distinction once the check is off. Toggling either direction restarts the container.

Q: Can I use something other than a bearer token?

Yes - auth mode is a per-project setting in Settings → Server access, not a fixed model: none (no check at all, same as making a project public), token (the default described above), or oauth (the gate runs as an OAuth 2.1 resource server against the workspace's own Zitadel client instead of a static token).

Every deployed server starts with a bearer token the moment it goes live - the default auth mode, and it isn't a separate integration to wire up yourself. Callers send it as Authorization: Bearer <token> on every request to /mcp. Auth mode is a per-project setting, so a project can also switch to OAuth or turn the check off entirely.

Can I use something other than a bearer token?

Yes - auth mode is a per-project choice in Settings → Server access, not a fixed model. token (the default, covered below), none (no check at all, same effect as making a project public), or oauth, where the in-container gate runs as an OAuth 2.1 resource server against the workspace's own Zitadel client instead of a static token.

How is the bearer token enforced?

The token check runs inside your deployed container, not in front of it on the platform's own infrastructure. Every request is routed straight through; a small gate injected at build time reads the token and public flag from the container's environment and decides there. That means a deployed server keeps working even if the platform's own API is unreachable - nothing in the request path depends on it.

How do I view or rotate the token?

The project's Settings tab shows the token masked by default, with a reveal toggle and a copy button. Rotating generates a new one immediately: the old token stops working the instant you confirm, every MCP client still configured with it starts failing, and the container restarts to pick up the new value. There's a short confirmation step because rotation isn't reversible - there's no way to get the old token back once it's replaced.

What happens if I make a project public?

Flipping a project to public turns the token check off entirely - anyone with the URL can call the server without a header at all. That's the right setting for something meant to be freely reachable, like a shared demo; it's the wrong one for anything touching a real credential or real data, since there's no per-caller distinction once the check is off. Toggling either direction restarts the container, so the server is briefly unreachable while it comes back up.