Railway - Application Hosting Platform

Railway is a platform-as-a-service (PaaS) designed to remove infrastructure configuration from the developer’s path. The core workflow is: connect a GitHub repository, Railway detects the runtime and framework, and the application is deployed. No Dockerfiles required unless you want them. No load balancers to configure, no VPCs to design, no IAM roles to untangle. For developers who want to ship an API or background worker without spending a week on cloud configuration, Railway is the practical alternative.

Railway was founded in 2020 and has grown significantly among the developer tools community, particularly for side projects, startups, and small teams that need production-grade hosting without a dedicated DevOps engineer.

The problem Railway solves

Deploying a Node.js API or Python service to AWS or GCP requires making many decisions before the first request is handled: which compute service (EC2, ECS, Lambda?), how to package the application (Docker, zip, AMI?), how to configure networking (VPC, subnets, security groups), how to handle TLS (ACM certificates, load balancer configuration), how to manage secrets (SSM Parameter Store, Secrets Manager), how to set up logging (CloudWatch log groups, retention policies), and how to automate deployments (CodeDeploy, GitHub Actions, ECR pipeline).

Each of these is a legitimate, learnable skill. For a team with an application to run, they are overhead that delays shipping.

Railway handles all of it automatically. A Node.js repo gets a Node.js environment with automatic TLS, environment variable management, log streaming, and deployment on every push. The tradeoff is control: Railway’s abstractions are opinionated. When you need that control back, compliance requirements, GPU workloads, fine-grained networking, Railway is not the right tool.

How deployment works

Railway connects to your GitHub repository and watches for pushes. On each push to the configured branch:

1. Railway pulls the latest code
2. Nixpacks (Railway’s open-source build system) analyzes the repository and detects the runtime: Python (checks for requirements.txt, pyproject.toml, Pipfile), Node.js (checks for package.json), Go (checks for go.mod), Ruby, Java, and others
3. Nixpacks builds the application into a container image without requiring a Dockerfile
4. The new image is deployed with zero-downtime rollover if health checks pass
5. The previous deployment is kept and can be restored instantly via the Railway dashboard

You can override any step: provide your own Dockerfile, customize the build command via railway.toml, or set the start command explicitly. Railway uses your Dockerfile if one is present, bypassing Nixpacks.

Supported runtimes

Railway can deploy anything that can be containerized. Nixpacks has built-in support for:

• Node.js: including Next.js, Express, NestJS, Fastify
• Python: Flask, FastAPI, Django, Streamlit
• Go
• Ruby: Rails
• Java / Kotlin: Spring Boot
• PHP: Laravel
• Rust
• Static sites: via a Nixpacks static provider
• Docker: any custom Dockerfile

For AI workloads, Railway runs Python-based inference APIs and data pipelines well. It does not currently offer GPU instances. For GPU inference, see vLLM on Modal or AWS SageMaker.

Services architecture

Railway organizes deployments around services within a project. A project is a collection of services that share a private network and can reference each other’s environment variables.

Services within the same project communicate using Railway’s private networking. The API service can reach the database using the internal hostname (e.g., postgres.railway.internal:5432) rather than the public connection string, faster and not exposed to the internet.

Environment variables and secrets

Each service has its own set of environment variables, managed in the Railway dashboard or via the Railway CLI. Railway supports variable references that let one service’s variables reference another service’s variables:

DATABASE_URL=${{Postgres.DATABASE_URL}}
REDIS_URL=${{Redis.REDIS_URL}}

This means when Railway provisions a PostgreSQL add-on and generates the connection string, your application service automatically receives the correct value without manual copy-pasting. Railway also supports shared variables at the project level (available to all services).

Secrets are encrypted at rest. Railway does not expose secret values in build logs.

Database add-ons

Railway provides managed database services that deploy as services within your project:

• PostgreSQL: fully managed Postgres, automatic backups, pitr available on paid plans
• Redis: managed Redis, useful for caching, sessions, and task queues
• MongoDB: managed MongoDB
• MySQL

Add-on databases are treated as services: they appear in the project canvas, connect over the private network, and their connection strings are injectable as variables into other services. For more sophisticated Postgres requirements (row-level security, pgvector, auth), consider pairing Railway deployment with a Supabase database.

How to deploy a Node.js API to Railway

Step 1: Prepare the repository

Ensure the app listens on process.env.PORT. Railway sets PORT automatically.

// server.js
const express = require('express');
const app = express();
const PORT = process.env.PORT || 3000;

app.get('/health', (req, res) => res.json({ status: 'ok' }));
app.listen(PORT, () => console.log(`Server running on port ${PORT}`));

Step 2: Create a Railway project

• Go to railway.app and sign in with GitHub
• Click “New Project” → “Deploy from GitHub repo”
• Select your repository
• Railway detects Node.js via package.json and begins the build

Step 3: Add a database (optional)

• In the project canvas, click “+ New” → “Database” → “PostgreSQL”
• Click your API service → “Variables” → add DATABASE_URL=${{Postgres.DATABASE_URL}}

Step 4: Set environment variables

• In your API service settings, add any required secrets: JWT_SECRET, OPENAI_API_KEY, etc.

Step 5: Configure a custom domain (optional)

• In your service settings → “Networking” → add your domain
• Railway provides DNS instructions; a CNAME pointing to your Railway app

Step 6: Monitor

• The “Deployments” tab shows build logs, deployment history, and rollback controls
• The “Metrics” tab shows CPU, memory, and network usage

Railway CLI for local development:

npm install -g @railway/cli
railway login
railway run node server.js  # injects production env vars locally

Pricing

Usage is billed at $0.000463/GB-hour (memory) + $0.000231/vCPU-hour. A small Node.js API using 256MB and 0.25 vCPU runs approximately $4-5/month beyond the included credit.

Railway vs Render vs Heroku vs Fly.io

Railway and Render are the closest competitors. Railway’s project canvas (visual service map) and variable references make multi-service setups easier to reason about. Render’s pricing model is more predictable for static workloads. Fly.io gives more low-level control and is better suited to latency-sensitive applications that need edge deployment.

Networking: private services

Not every service should be publicly accessible. A background worker that processes a task queue has no reason to accept HTTP traffic from the internet. In Railway, set a service to have no public networking, it exists only on the private network, reachable from other services in the project.

This is the correct architecture for a queue consumer: the API service pushes jobs to Redis, the worker service reads from Redis (using REDIS_URL on the private network), processes jobs, and writes results to the database. Neither the worker nor the database is exposed to the internet.

When not to use Railway

Railway is the right tool for a specific range of workloads. It is not the right tool when:

• Compliance requirements: SOC 2, HIPAA, PCI-DSS. Railway does not offer the audit controls, data residency guarantees, and compliance documentation that regulated industries require. Use AWS or GCP with appropriate configurations.
• GPU inference: Railway does not offer GPU instances. For running local LLMs, use Modal, AWS SageMaker, or a self-managed GPU server. See vLLM .
• Fine-grained networking control: Custom VPC peering, PrivateLink to other AWS services, complex routing rules. Railway’s networking is intentionally simple.
• Very high traffic with cost predictability: At scale, Railway’s per-resource pricing can exceed a reserved-instance AWS deployment. Run the numbers above ~$500/month.
• Long-running CPU-intensive workloads: Railway is optimized for web services and workers, not for batch ML training jobs.

For projects that start on Railway and grow: the migration path to AWS ECS or GCP Cloud Run is straightforward because Railway’s Docker-based deployment means your application is already containerized.

Sources

1. https://railway.app/
2. https://docs.railway.app/
3. https://nixpacks.com/