Deploy and Host Nango with Railway

Nango is the open-source unified API for product integrations — connect 400+ APIs (Salesforce, HubSpot, GitHub, Slack, Notion, and more) with managed OAuth, sync, and webhooks. This template deploys a complete self-hosted Nango stack on Railway in a single click.

About Hosting Nango

Self-hosting Nango means running three coordinated services: the Nango server (API and admin dashboard), a PostgreSQL database that stores encrypted integration credentials and sync state, and a Redis instance for queues and caching. The official Nango Docker image bundles a static Connect UI server alongside the API, but running them in one container is fragile — if either process exits, both die. This template runs them as two services from the same image instead, each with its own auto-generated public domain. Postgres and Redis are Railway managed plugins. Every credential at rest is AES-256 encrypted with a key generated at deploy time.

Common Use Cases

• Internal automations that pull data from your customers' SaaS tools (CRMs, ticketing systems, accounting platforms).
• Customer-facing OAuth flows where you don't want to maintain provider-specific client logic.
• Background syncs that mirror third-party data into your own database for analytics.
• White-labeled integration marketplaces inside your product.
• Replacing fragile homegrown OAuth + webhook code with a single managed layer.

Dependencies for Nango Hosting

• PostgreSQL 16 — primary store for connections, configs, and encrypted credentials (Railway managed plugin).
• Redis 7 — queue and pub/sub layer for the background workers Nango ships in-process (Railway managed plugin).
• Nango Server — nangohq/nango-server:hosted-0.70.4 Docker image (the API + dashboard process).
• Nango Connect UI — the same image, started with a command override that runs only the static UI server.

Deployment Dependencies

• Nango repository
• Nango self-hosting docs
• nangohq/nango-server on Docker Hub

Implementation Details

• Health check. Nango exposes GET /health (immediate liveness) and GET /ready (returns 200 only after DB is reachable). The template uses /ready so Railway only routes traffic once the database is fully migrated.
• Encryption key. Nango refuses to start if NANGO_ENCRYPTION_KEY is not a valid base64-encoded 32-byte value. The template generates one at deploy time using ${{secret(43, "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789+/")}}=, which produces exactly the openssl rand -base64 32 shape. Do not regenerate this key after first deploy — every credential in the database is encrypted with it. Losing it means losing every stored integration.
• PORT env var. The upstream image bakes in PORT=8080 as a default. Railway's edge proxy routes traffic to whatever PORT is set to, regardless of what port the app actually binds. The template overrides PORT=3003 on the API service and PORT=3009 on the Connect UI service so edge → container routing works correctly.
• Connect UI command override. The Connect UI service runs the same image as the API service with a start-command override of sh -c "npm run -w @nangohq/connect-ui serve:unsafe" so only the static file server runs. This avoids the upstream entrypoint's wait -n pattern where the API container dies if the Connect UI process exits — a behavior the Nango source code itself flags as "not recommended for production".

Why Deploy Nango on Railway?

Railway provisions the full stack — application, database, cache, public TLS domains — in one click and with no infrastructure config. You get private networking between services for free, managed backups on the Pro plan, per-service auto-updates with maintenance windows, and a single bill for everything. Compared to wiring Nango onto a VPS or Kubernetes cluster yourself, the time-to-first-OAuth-callback drops from hours to under five minutes.

After Deploy

1. Wait for all four services to reach the SUCCESS state in the Railway dashboard (typically 60–90 seconds).
2. The Nango Server service has the API and admin dashboard. Open its public domain — you'll be prompted for HTTP basic auth. Username: admin. Password: copy the value of NANGO_DASHBOARD_PASSWORD from the service's Variables tab (Railway generated a random 32-character string at deploy time).
3. Inside the dashboard, Integrations → New lets you wire up your first OAuth provider. Your OAuth callback URL is https:///oauth/callback — paste this into your OAuth app's redirect URI settings on the provider side.
4. Important: back up Postgres regularly. The encryption key is single-source-of-truth — if you lose the database, every stored credential becomes unreadable even with the key.

Updates

nango-server and nango-connect-ui are pinned to a specific Nango release tag. To upgrade, change the Docker image tag in each service's Settings → Source. Nango ships every 2–5 days; check the releases page before bumping. The image tag scheme is hosted-X.Y.Z, not bare semver — Railway's automatic semver detection requires vX.Y.Z, so cross-version auto-updates won't work, but SHA-change updates on the same tag do.

Not Included

• Elasticsearch / logs UI — adds ~1 GB RAM and 30 GB storage; off by default (NANGO_LOGS_ENABLED=false). Add an Elasticsearch service and set NANGO_LOGS_ENABLED=true plus NANGO_LOGS_ES_URL to enable.
• Email (Mailgun) and WorkOS SSO — only needed for the team-signup flow. Self-hosted uses basic auth instead.
• E2B sandboxes — for remote sync functions. Add E2B_API_KEY to enable.

Source

• Template source: https://github.com/ramadan-omar/nango-railway-template (replace with your repo if you fork)
• Nango: https://github.com/NangoHQ/nango