Deploy ContextForge MCP Gateway + Postgres

Deploy and Host ContextForge MCP Gateway on Railway

ContextForge is IBM's open-source MCP gateway and registry. It puts MCP servers, REST APIs and A2A agents behind one authenticated endpoint, lets you bundle their tools into virtual MCP servers, and adds an Admin UI, API tokens, teams, RBAC, rate limiting and observability.

About Hosting ContextForge MCP Gateway

This template runs the official ghcr.io/ibm/mcp-context-forge:v1.1.0 image with PostgreSQL for durable state and Redis for the cache and session registry shared by the gunicorn workers. The gateway runs its own database migrations on boot, listens on port 4444, and reports ready at /ready only when Postgres and Redis both answer. Every credential is generated at deploy time, and ContextForge itself refuses to start if a signing secret is weak or a password is still changeme. Self registration is closed, Basic auth is off, and SSRF protection keeps its strict defaults.

Common Use Cases

• One MCP endpoint for many servers: federate remote MCP servers and expose curated virtual servers to Claude, Cursor or any MCP client
• Wrap REST APIs as MCP tools: register an HTTP endpoint once and call it as a tool
• Central auth for agents: issue scoped, expiring API tokens per team instead of sharing upstream keys
• Governance: RBAC, rate limits, audit and metrics in front of every tool call
• A2A agent registry: expose agents as tools inside virtual servers

Dependencies for ContextForge MCP Gateway Hosting

• PostgreSQL: included, stores users, tokens, servers, tools and metrics
• Redis: included, cache and multi-worker session state
• No external API keys required to boot: add upstream MCP servers and LLM providers later from the Admin UI

Deployment Dependencies

• ContextForge documentation
• Container deployment guide
• ContextForge GitHub repository

Implementation Details

First steps after deploy:

1. Copy PLATFORM_ADMIN_EMAIL and PLATFORM_ADMIN_PASSWORD from the ContextForge service variables.
2. Sign in at https:///admin.
3. Create an API token, register an MCP server or REST tool, and group tools into a virtual server.
4. Point your MCP client at https:///servers//mcp with Authorization: Bearer .

Key variables:

PORT=4444
HOST=[::]
DATABASE_URL=postgresql+psycopg://...@${{Postgres.RAILWAY_PRIVATE_DOMAIN}}:5432/contextforge
CACHE_TYPE=redis
JWT_SECRET_KEY=${{secret(64)}}
AUTH_ENCRYPTION_SECRET=${{secret(64)}}
PLATFORM_ADMIN_PASSWORD=${{secret(32)}}
PUBLIC_REGISTRATION_ENABLED=false
SSRF_ALLOW_PRIVATE_NETWORKS=false

SSRF protection blocks private, loopback and cloud metadata addresses. Public MCP servers work immediately. To reach an MCP server inside the same Railway project, add its private range to SSRF_ALLOWED_NETWORKS (for example ["fd12::/16"]) or use its public domain. Do not rotate AUTH_ENCRYPTION_SECRET after storing upstream credentials.

Why Deploy ContextForge MCP Gateway on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying ContextForge MCP Gateway on Railway, you get an authenticated MCP gateway with Postgres, Redis, generated secrets, health checks, managed SSL, and private networking to the rest of your stack.