Deploy OpenConnector + Postgres

Auth gateway for AI agents: 1500+ SaaS APIs via MCP, HTTP and OpenAPI

Deploy OpenConnector + Postgres

Just deployed

/var/lib/postgresql/data

Deploy and Host OpenConnector on Railway

OpenConnector is an open-source auth gateway between AI agents and SaaS APIs. You connect accounts once (OAuth or API keys) and your agents call more than 1500 providers, including GitHub, Gmail, Slack, Notion and Linear, through MCP, plain HTTP, an SDK, a CLI or OpenAPI, without ever seeing the raw credentials.

About Hosting OpenConnector

This template runs the official ghcr.io/oomol-lab/open-connector image, pinned to a release, next to a PostgreSQL database. Connections, encrypted credentials, OAuth app settings, runtime tokens and the action audit log all live in Postgres, so redeploys and upgrades keep your data. Database migrations run automatically before every start.

Every secret is generated per deploy: the encryption key for stored credentials, the admin token for the web console, and a runtime token for agents. Nothing is reachable anonymously.

Common Use Cases

  • Give Claude, Cursor, Codex or any MCP client access to your SaaS accounts through one MCP endpoint
  • Let backend agents call provider actions over HTTP with scoped, revocable tokens instead of raw API keys
  • Run one shared credential vault for a team's agents, with per-token action and connection limits
  • Keep OAuth refresh handling, retries and audit logs out of your agent code

Dependencies for OpenConnector Hosting

  • OpenConnector (official image, Node.js)
  • PostgreSQL 18 (Railway's standard Postgres image)

Deployment Dependencies

Implementation Details

First login. Open the service's public URL. The web console asks for a token: copy OOMOL_CONNECT_ADMIN_TOKEN from the OpenConnector service's Variables tab and paste it in.

Connect an agent over MCP. Point your MCP client at https:///mcp with the header Authorization: Bearer . You can use OOMOL_CONNECT_RUNTIME_TOKEN from the Variables tab, but it is better to mint a separate token per agent in the console's Access tab. Those tokens can be limited to specific actions, providers and connections, and revoked one at a time.

Call actions over HTTP.

curl -X POST https:///v1/actions/hackernews.get_top_stories \
  -H "Authorization: Bearer " \
  -H "content-type: application/json" -d '{"input":{}}'

OAuth providers. Each OAuth provider needs your own OAuth app. The console shows the exact callback URL to register, built from OOMOL_CONNECT_ORIGIN (set to your Railway domain automatically). If you add a custom domain, update OOMOL_CONNECT_ORIGIN to https://your.domain and re-register the callback.

Back up the encryption key. OOMOL_CONNECT_ENCRYPTION_KEY encrypts every stored credential. If it is lost or changed, stored credentials cannot be decrypted and every account must be reconnected.

Optional settings (add to the OpenConnector service at any time):

  • OOMOL_CONNECT_ALLOWED_ACTIONS / OOMOL_CONNECT_BLOCKED_ACTIONS: deployment-wide action allow and deny lists, e.g. github.*,slack.*
  • OOMOL_CONNECT_ALLOWED_PROXIES: providers that may be called through the raw API proxy
  • OOMOL_CONNECT_ALLOWED_CUSTOM_OAUTH: allow per-connection OAuth apps (* or a service list)
  • OOMOL_CONNECT_JWKS_URI, OOMOL_CONNECT_JWT_ISSUER, OOMOL_CONNECT_JWT_AUDIENCE: accept JWTs from your identity provider on /v1 and /mcp
  • OOMOL_CONNECT_TRANSIT_FILE_BACKEND=s3 plus the OOMOL_CONNECT_S3_* variables: keep transit files in a bucket

Storage and scaling. Transit files (temporary uploads handed between agents and providers, 24 hour lifetime) are kept on local disk and do not survive a redeploy. Everything durable is in Postgres. To run more than one replica, move transit files to S3 first.

Upgrading. Change the image tag on the OpenConnector service to a newer release. Pending migrations are applied automatically on the next start.

Troubleshooting. If the service fails to start with a schema error, check that Postgres is running. Migrations need the database to be reachable before the server starts.

Why Deploy OpenConnector 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 OpenConnector on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.


Template Content

More templates in this category

View Template
Chat Chat
Chat Chat, your own unified chat and search to AI platform.

okisdev
117
View Template
NEW
Möbius v0.1 Personal AI OS
Self-hosted AI agent that builds and runs apps for you, with memory.

bento
1
View Template
stella
Self-host stella with web, API, Postgres, Redis, and object storage.

Jan Kubica
7