Secure your self-hosted MCP server

A self-hosted mcp-core server holds the login details of your shop, database and other systems, so it deserves the same care as the systems themselves. This page lists what keeps it safe: a recent version, a closed port or a proxy with HTTPS, one token per person, tight file permissions and tool logins that can do no more than needed. Most of it takes a few minutes once.

Which mcp-core version should you run?

Run 2.3.3 or later. Versions before 2.3.1 showed a connection picker on /oauth/authorize without a login, which gave anyone who could reach the server access to a license with one connection. 2.3.2 also stops the tokens that picker handed out, and 2.3.3 requires PKCE for every connector setup. Update from the folder of your bundle:

./mcp-update.sh

Run it again whenever a new version comes out; keep mcp-core up to date explains versions and pinning. A connector you once set up through the old picker connects again with the Connect AI link of its connection.

Should mcp-core be reachable from the internet?

Only through a reverse proxy with HTTPS, and only when you need it. The compose file from your bundle binds the container to 127.0.0.1, so out of the box nothing outside the host can reach it. Claude Desktop and Claude Code on the same machine work with that.

Claude.ai and Claude Desktop on another computer need a public HTTPS address. Then:

1. Keep MCP_BIND in .env at 127.0.0.1, so the container port itself stays closed.
2. Put a reverse proxy in front (nginx, the proxy rules in Plesk, Caddy) with a valid certificate, and forward only /mcp, /oauth, /.well-known and /health to http://127.0.0.1:3200.
3. Set SERVER_URL in .env to the public address, for example https://mcp.example.com, and run ./mcp-update.sh.
4. Open only ports 80 and 443 (and SSH) in the firewall of the server.

Never publish port 3200 directly and never serve mcp-core over plain HTTP: the token travels with every request.

How should you handle connection tokens and Connect AI links?

Treat each token like a password. The Connect AI link (https://your-server/mcp/<token>) contains the token, so the link is the password too.

• Give every person or device its own seat (Connection). Then you can stop one without touching the others. See how to add a teammate.
• Don’t paste tokens or links in chat, tickets or e-mail, and keep them out of git.
• When someone leaves or a link may have leaked, use Regenerate token or Revoke on the Connections tab in My Account → Licenses. The server picks it up at the next license check; run ./mcp-update.sh to apply it at once.
• A reverse proxy writes requested paths to its access log, and the Connect AI link is a path. Keep those logs readable only for administrators, or leave the token out of the log format.

Which files hold secrets, and who may read them?

These files in the bundle folder hold credentials:

• .env: your license key, the token of the first connection and any tool settings you added.
• .env.registry: the login for the image registry. Every license has its own, and ./mcp-update.sh fetches the current one by itself before each update.
• state/: the signed license check, the installation id and encrypted copies of the login details you entered on the portal.
• claude-plugin/.mcp.json: the token of the first connection for Claude Code.

Make them readable for the owner only and keep them out of version control:

chmod 600 .env .env.registry claude-plugin/.mcp.json
chmod 700 state

Back the folder up encrypted. Don’t copy state/ to a second server to run another install: the license check is tied to the installation it was made for, and a copy simply stops working.

How much access should each tool login have?

No more than the work you ask Claude to do. A token that leaks can only do what the logins behind it allow.

• Database: a separate user with only SELECT on the tables Claude needs, and the exclude list for everything else. See Database MCP setup.
• WooCommerce: a REST API key with Read permission unless Claude has to change orders or products.
• WordPress: an application password of a separate user with the lowest role that still works, never your own administrator account.
• Plesk, Missive, Lightspeed and the others: a key or user meant for this purpose, so you can withdraw it without changing anything else.

Give connections that only need to look things up the read-only mode. A read-only connection never gets the write tools, whatever its login could do. Entitlements vs tool modes explains the difference.

Which settings should you check when you use OAuth?

Only relevant with AUTH_STRATEGY=oauth. The default apikey needs none of this.

• Use long, unique passwords for the users in OAUTH_USERS; store only the bcrypt hashes.
• Set OAUTH_CLIENT_SECRET, so a stolen login code alone is not enough.
• Leave OAUTH_REDIRECT_URIS empty unless you use a client other than Claude. Empty allows Claude’s own callback and local addresses only, which stops a phishing link from sending a login code elsewhere.
• After 10 wrong passwords from one address or for one username, logins wait 15 minutes. Behind a reverse proxy this works per visitor as long as the proxy runs on the same host or a private network.

How do you keep the host itself safe?

• Install operating system and Docker updates.
• Log in over SSH with a key, not a password, and only as the users who need it.
• Don’t run other services you don’t need on the same server.
• Leave LICENSE_ENDPOINT at the https address from your bundle. mcp-core refuses a plain http license address, so the license key never travels unencrypted.

What do you do if a token or login leaks?

1. Regenerate the token of the affected connection on the Connections tab, or revoke it, and run ./mcp-update.sh.
2. Change the tool logins that connection used: the database password, the API key, the application password.
3. Look through logs/ for requests you don’t recognise (Token accepted lines name the connection).
4. If your license key itself leaked, contact us for a new one.

Is there a short checklist?

• mcp-core 2.3.3 or later, updated with ./mcp-update.sh.
• Port 3200 bound to 127.0.0.1; remote access only through HTTPS.
• One connection per person or device; regenerate or revoke when someone leaves.
• .env, .env.registry, state/ and .mcp.json readable for the owner only, not in git.
• Tool logins with the least access that works, read-only connections where possible.

For how tokens are checked on every request, see MCP authentication. For the files in the bundle, see MCP Core download and zip contents.