Deploy Kong Gateway OSS
A Kong Gateway OSS deployment running in hybrid mode
kong-cp
kong/kong:3.9.1
Just deployed
kong-db
railwayapp-templates/postgres-ssl:17
Just deployed
/var/lib/postgresql/data
kong-dp
kong/kong:3.9.1
Just deployed
Deploy and Host Kong Gateway OSS on Railway
Kong Gateway OSS is an open-source, high-performance API gateway and reverse proxy designed to handle authentication, rate-limiting, observability, traffic routing, and plugin-based extensibility. It sits in front of your services to securely and efficiently manage API traffic at scale.
Quickstart
Deployment
- Generate mTLS certificates
openssl req -new -x509 -nodes -newkey ec:<(openssl ecparam -name secp384r1) \
-keyout ./tls.key -out ./tls.crt -days 1095 -subj "/CN=kong_clustering"
- Create a new Railway project
- Add the Kong Gateway OSS template to your project
- Configure the Control Plane (CP) and Data Plane (DP) nodes and add the necessary secrets generated from step 1
- Deploy your Kong Gateway OSS instance
Post-Deployment
- Change the pre-deploy command of the kong-cp service to
kong migrations up && kong migrations finish- This step ensures that whenever you choose to swap out the docker image (probably to install a custom plugin), the migrations are run to ensure the database schema is up-to-date.
- Redeploy the kong-cp service
- Add your services to Kong Gateway OSS
- Test your API traffic
About Hosting Kong Gateway OSS
This Kong Gateway OSS template involves provisioning a database, configuring the Control Plane (CP), and running one or more Data Plane (DP) nodes to process traffic. The CP stores configuration and syncs it to each DP. Railway simplifies this setup by providing a managed environment where services can be connected with minimal manual wiring—database volumes, networking, secrets, and scaling are all handled through the platform’s UI. This lets you focus on API governance and routing instead of infrastructure complexity.
Common Use Cases
- Centralized API gateway for microservices
- Rate-limiting, authentication, and observability enforcement
- Traffic shaping, blue-green deployments, and zero-downtime routing
Dependencies for Kong Gateway OSS Hosting
- PostgreSQL database for Kong CP state
Deployment Dependencies
- Kong Gateway OSS documentation: https://docs.konghq.com
- Kong Docker images: https://hub.docker.com/r/kong/kong
Implementation Details
This template is a Kong Hybrid Deployment running on Railway, consisting of:
- kong-cp → kong node running as control plane
- kong-dp → kong node running as data plane
- kong-db → A shared PostgreSQL database used only by the Control Plane
Control Plane (kong-cp)
Purpose
The Control Plane:
- Stores all configuration in PostgreSQL
- Runs the Admin API
- Hosts Kong Manager GUI
- Pushes configuration to all Data Planes
- Accepts secure mTLS cluster connections from Data Planes
Key Behaviors (Based on Env Vars)
| Variable | Description |
|---|---|
KONG_ROLE=control_plane | Enables CP mode |
KONG_DATABASE=postgres | CP uses Postgres for config |
KONG_PG_* | These point to the kong-db Railway service |
KONG_ADMIN_LISTEN="0.0.0.0:8001" | Admin API exposed |
KONG_ADMIN_GUI_LISTEN="0.0.0.0:8002" | Kong Manager GUI exposed |
KONG_CLUSTER_LISTEN="0.0.0.0:8005 ssl" | CP listens for DP connections |
KONG_CLUSTER_TELEMETRY_LISTEN="0.0.0.0:8006 ssl" | CP receives DP telemetry |
KONG_ADMIN_GUI_URL | Public GUI URL |
KONG_ADMIN_GUI_API_URL | Backend API URL routed via Railway TCP proxy |
How CP → Database Works
The Railway diagram shows a dashed arrow from kong-cp → kong-db, meaning:
- Railway automatically injects
PGHOST,PGUSER,PGPASSWORD, etc. - CP connects without manual configuration.
Data Plane (kong-dp)
Purpose
The Data Plane:
- Does not use a database
- Does not run an Admin API
- Receives configuration from the CP over mTLS
- Serves proxy traffic to end-users
Key Behaviors (Based on Env Vars)
| Variable | Description |
|---|---|
KONG_ROLE=data_plane | Enables DP mode |
KONG_DATABASE=off | No Postgres connection |
KONG_PROXY_LISTEN="0.0.0.0:8000" | Public-facing proxy |
KONG_ADMIN_LISTEN=off | No Admin API for security |
KONG_CLUSTER_CONTROL_PLANE="${{kong-cp.RAILWAY_PRIVATE_DOMAIN}}:8005" | Connects to CP for config |
KONG_CLUSTER_TELEMETRY_ENDPOINT="${{kong-cp.RAILWAY_PRIVATE_DOMAIN}}:8006" | Telemetry to CP |
KONG_CLUSTER_CERT / KONG_CLUSTER_CERT_KEY | Required for mTLS handshake |
KONG_PROXY_URL | Public URL of the DP proxy |
DP ↔ CP Communication
The Railway diagram shows kong-dp → kong-cp via a dashed line, matching:
- Port 8005 (config sync)
- Port 8006 (telemetry)
Both use Railway’s private service network, which avoids exposing CP internals publicly.
Database (kong-db)
Purpose
- A PostgreSQL instance used only by the Control Plane
- Stores all Kong configuration (routes, services, consumers, etc.)
- The Data Plane never connects to the database
Notes
- Public networking disabled; database can only be accessed internally
High-Level Flow
- CP boots, connects to Postgres, exposes Admin API + GUI.
- DP boots, connects to CP via mTLS, downloads config.
- DP serves traffic on port 8000.
- Admin actions are performed on CP, stored in Postgres, and pushed to DPs.
Why Deploy Kong Gateway OSS 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 Kong Gateway OSS 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
kong-cp
kong/kong:3.9.1KONG_CLUSTER_CERT
Base64-encoded certificate for cluster mTLS (required)
KONG_CLUSTER_CERT_KEY
Base64-encoded private key for cluster mTLS (required)
kong-dp
kong/kong:3.9.1KONG_CLUSTER_CERT
Base64-encoded certificate for cluster mTLS (required)
KONG_CLUSTER_CERT_KEY
Base64-encoded private key for cluster mTLS (required)