Harden and iterate

You have a deployed, authenticated, observable MCP server. The remaining work is the gap between “works for me” and “works for users over months.” Every item here is a small, well-scoped change you can ship one PR at a time.

1. Move OAuth state to Postgres

The provider from step 5 keeps clients, pending authorizations, and authorization codes in Maps. They reset on every deploy and don’t cross instances. That’s fine for one box; the moment you scale to two it breaks.

Two new tables, one new module, then point the provider at it.

CREATE TABLE IF NOT EXISTS oauth_clients (
  client_id           TEXT         PRIMARY KEY,
  client_secret_hash  TEXT,
  metadata            JSONB        NOT NULL,
  registered_at       TIMESTAMPTZ  NOT NULL DEFAULT NOW()
);

CREATE TABLE IF NOT EXISTS oauth_codes (
  code            TEXT         PRIMARY KEY,
  client_id       TEXT         NOT NULL REFERENCES oauth_clients(client_id) ON DELETE CASCADE,
  redirect_uri    TEXT         NOT NULL,
  code_challenge  TEXT         NOT NULL,
  scopes          TEXT[]       NOT NULL DEFAULT '{}',
  state           TEXT,
  github_user_id  BIGINT,
  github_login    TEXT,
  expires_at      TIMESTAMPTZ  NOT NULL
);

CREATE INDEX IF NOT EXISTS oauth_codes_expires_idx ON oauth_codes (expires_at);

Then refactor provider.ts so clientsStore, the pending map, and the codes map all read/write Postgres via the pg.Pool. The function bodies are tiny - one INSERT and one SELECT apiece. The interface doesn’t move; mcpAuthRouter keeps working as-is.

A periodic DELETE FROM oauth_codes WHERE expires_at < NOW() is worth scheduling - a Render cron job that runs every 10 minutes does the trick:

- type: cron
  name: notes-mcp-oauth-gc
  runtime: node
  schedule: "*/10 * * * *"
  buildCommand: corepack enable && pnpm install --frozen-lockfile && pnpm build
  startCommand: node dist/scripts/gc-oauth.js
  envVars:
    - key: DATABASE_URL
      fromDatabase:
        name: notes-mcp-db
        property: connectionString

Same fromDatabase wiring the web service already uses. Each consumer declares its own block - covered in detail in the Postgres wiring step.

2. Scope data to the authenticated user

Right now every authenticated caller sees every other caller’s notes. The fix is one column and one WHERE clause.

ALTER TABLE notes ADD COLUMN IF NOT EXISTS owner_sub TEXT;
CREATE INDEX IF NOT EXISTS notes_owner_sub_idx ON notes (owner_sub, created_at DESC);

Tool handlers receive the auth context via the extra argument the SDK threads through. Read sub off it and filter every query:

server.registerTool(
  "notes.create",
  { /*...unchanged... */ },
  async ({ title, body }, { authInfo }) => {
    const sub = authInfo?.extra?.sub as string | undefined;
    if (!sub) throw new Error("Missing identity");
    const note = await store.create({ title, body, ownerSub: sub });
    return { /*...unchanged... */ };
  },
);

recent(limit) becomes recent({ ownerSub, limit }) and the SQL gains WHERE owner_sub = $1. Same for getById. Five-minute change end-to-end; the auth context was already there waiting to be used.

3. Rotate the JWT signing secret

JWT_SIGNING_SECRET was set with generateValue: true, so Render has the only copy. Rotating it is a Render Dashboard click:

1. Open the Environment tab for the web service Find JWT_SIGNING_SECRET and hit the regenerate icon.
2. Confirm Render generates a new value and rolls the service.
3. Existing tokens are invalidated Anyone with a token issued under the old secret hits verifyAccessToken and gets a 401. The MCP client transparently re-runs the OAuth flow.

The trade-off is the blip: in-flight requests using the old token fail once. For real production you’d run two signing keys in parallel during a rotation window (publish both as JWKS, accept either, sign with the new one). For most internal MCP services the blip is acceptable.

4. Limit who can sign in

Right now anyone with a GitHub account can authenticate. Two clean ways to scope that down - pick what matches the workload.

const allow = (process.env.ALLOWED_GITHUB_LOGINS ?? "")
 .split(",").map((s) => s.trim()).filter(Boolean);
if (allow.length && !allow.includes(user.login)) {
  return res.status(403).send(`Sign-in for @${user.login} is not authorized.`);
}

const ALLOWED_ORG = process.env.ALLOWED_GITHUB_ORG;
if (ALLOWED_ORG) {
  const membershipResp = await fetch(
    `https://api.github.com/user/memberships/orgs/${ALLOWED_ORG}`,
    {
      headers: {
        Authorization: `Bearer ${ghToken}`,
        Accept: "application/vnd.github+json",
      },
    },
  );
  if (membershipResp.status !== 200) {
    return res
     .status(403)
     .send(`@${user.login} is not a member of ${ALLOWED_ORG}.`);
  }
  const membership = (await membershipResp.json()) as { state: string };
  if (membership.state !== "active") {
    return res
     .status(403)
     .send(`@${user.login}'s membership in ${ALLOWED_ORG} is pending.`);
  }
}

5. Scaling and capacity

Render’s web service plans scale up and out independently. The dimensions that matter for this server:

The Render scaling docs cover the configuration; the architectural call (pin sessions vs. go stateless) depends on whether your tools need server-initiated messages.

6. The week-one watchlist

The metrics that catch real problems before users tell you. Set Render alerts on each.

Render Metrics gives you the first five out of the box; the last one you’ll get from your own structured logs.

7. Add tests (the template gave you a starting point)

The template includes a tests/ folder and a vitest.config.ts. Re-run them to confirm the existing tests still pass:

npm test

A few high-value additions for the surface you added:

• A test that posts to /.well-known/oauth-protected-resource and asserts the JSON shape (catches a broken PUBLIC_URL early).
• A test that posts to /mcp without an Authorization header and asserts 401 + the WWW-Authenticate response header.
• A test that mints a JWT directly with provider.verifyAccessToken-compatible claims, hits /mcp with it, and asserts a successful tool call.

Each one is ~15 lines and runs in under 1s - wire them into the npm test script and have CI gate merges to main before flipping autoDeploy: true in the Blueprint.

8. Where to go next

The skills the agent and the docs both reach for if you want to keep building:

• Render web services - port binding, custom domains, autoscaling.
• Postgres on Render - the full HA, replicas, and pooling story.
• Background workers - if your tools need to do long async work (LLM batch jobs, data sync), move it off the request path.
• Render Workflows - when “background worker” stops being enough and you need retries, fan-out, and durable state.
• MCP authorization spec - the source of truth for what you implemented; useful when an MCP client behaves unexpectedly.
• render-examples/mcp-server-typescript - the template’s repo. Watch it for upstream changes (SDK bumps, transport updates) you might want to cherry-pick.