Railway vs Cloudflare: two platforms solving different problems in 2026

• Railway is a full-stack application platform that runs persistent containers, databases, cron jobs, and workers on its own infrastructure, billed per second for CPU and RAM
• Cloudflare is a global network and developer platform; its compute layer spans Workers (serverless, edge), Containers (any language, Workers Paid plan), and a suite of storage primitives including D1, R2, KV, and Durable Objects
• The two platforms rarely compete directly: Railway targets teams deploying traditional full-stack applications, while Cloudflare targets teams building edge-first or network-adjacent workloads

Comparing Railway and Cloudflare requires understanding that they start from different positions. Railway is an application deployment platform. Cloudflare is a network platform that has expanded into developer compute. The overlap exists, but it is narrow.

Railway is a full-stack cloud platform that deploys web apps, servers, databases, and workers from a Git repo or Docker image. It runs on Railway Metal, Railway's own infrastructure. Services run as persistent containers billed per second based on actual CPU and RAM consumption. The platform provides a visual project canvas, private networking between services, preview environments per pull request, and one-click rollbacks.

Cloudflare operates a global network across 300+ locations handling CDN, DNS, DDoS protection, and WAF for a large portion of internet traffic. Its developer platform runs on top of that infrastructure. Workers is a serverless runtime that executes JavaScript and WASM at the edge using V8 isolates. Containers, available on the Workers Paid plan, extends Workers to run any language or runtime as container instances spun up on-demand. The storage layer includes D1 (serverless SQLite), R2 (object storage), KV (global key-value), Durable Objects (stateful compute), and Queues.

The two platforms differ in execution model, infrastructure philosophy, storage, networking, and pricing structure.

Railway runs persistent containers. A deployed service stays running continuously, holds state in memory, maintains open connections, and handles requests as they arrive. It supports TCP, HTTP, gRPC, and WebSockets. There is no function invocation model and no request-based execution boundary.

Cloudflare Workers runs JavaScript and WASM inside V8 isolates at the edge. The free tier allows 50ms of CPU time per request. The paid tier defaults to 30 seconds of CPU time per request, configurable up to 5 minutes. Memory per isolate is limited to 128 MB. Workers do not run persistent processes; each invocation is stateless unless connected to Durable Objects or external storage.

Cloudflare Containers, available on the Workers Paid plan, runs container images spun up on-demand and controlled by Worker code. Containers support resource-intensive workloads that require more CPU, memory, or a full Linux environment. They are not always-on like Railway services; instances start on-demand and stop when idle.

Railway runs any open-source database as a service within a project. Postgres, MySQL, Redis, and others deploy from templates and run as persistent containers alongside your application. Volumes attach to services with 3,000 read/write IOPS. Built-in backups, disk usage metrics, and object storage are included.

Cloudflare does not host traditional managed databases. Its storage layer is built around primitives designed for edge workloads. D1 is a serverless SQLite database that runs queries within the Workers CPU and memory limits. R2 provides object storage with no egress fees. KV is a globally distributed key-value store optimised for read-heavy workloads, with eventual consistency. Durable Objects provide strongly consistent stateful compute with their own SQL storage. Hyperdrive connects Workers to external databases to reduce connection latency.

Teams that need a persistent Postgres or MySQL instance cannot run it on Cloudflare's developer platform directly.

Railway provides private networking between services within a project at up to 100 Gbps. Services communicate over private hostnames without exposing traffic to the public internet. TCP, HTTP, gRPC, and WebSocket connections all work across services.

Cloudflare provides Service Bindings between Workers for direct internal invocation, Workers VPC for connecting Workers to private networks via Cloudflare Tunnel or Cloudflare Mesh, and Private Links for connecting to external VPCs on AWS, Azure, and GCP. Inbound traffic to Workers is HTTP and WebSockets. Workers support outbound TCP connections. Arbitrary inbound TCP requires Cloudflare Spectrum (Enterprise) or Cloudflare Tunnel.

Railway connects to a Git repository and deploys on every push. It supports GitHub repo deployment, Docker image deployment, and local deployment via the Railway CLI. Preview environments spin up per pull request with their own services and databases. One-click rollbacks are available from the dashboard. Config as code is supported via TOML or JSON.

Cloudflare offers Workers Builds for Git-connected deployments of Workers, triggering on push to GitHub or GitLab. Cloudflare Pages provides Git-connected CI/CD for static sites and full-stack framework deployments. Preview deployments are created per commit and per pull request on Pages. Workers also support versioned preview URLs for testing before production deployment.

Railway charges for running time regardless of request volume. A service that sits idle between requests still consumes CPU and RAM. Cloudflare Workers charges per request and per CPU millisecond actually consumed, with no charge during idle time. For workloads with variable or low request volume, Workers can be significantly cheaper. For always-on services with steady traffic, Railway's per-second model is predictable and straightforward.

Railway fits teams deploying full-stack applications with persistent services, long-running processes, and databases that need to run together in a single project. It fits teams that want a visual project canvas, Git-connected deployments, and per-second billing without managing infrastructure configuration. It does not fit teams that need global edge distribution or request-based pricing for low-volume workloads.

Cloudflare fits teams building edge-first applications where global low-latency execution matters, or teams invested in the Workers ecosystem using R2, D1, and KV as storage primitives. It fits teams that need network-level features like WAF, DDoS protection, and DNS alongside compute. It does not fit teams that need always-on persistent servers, traditional managed databases, or arbitrary inbound TCP without Enterprise-tier products.

The two platforms can also be used together. Railway runs the persistent backend and database layer. Cloudflare handles DNS, CDN, DDoS protection, and edge logic in front of it.

Northflank provides a deployment platform that covers persistent containers, managed databases, workers, cron jobs, and preview environments within a single control plane. It supports both CPU and GPU workloads, secure sandboxes for running AI-generated code, and persistent and ephemeral execution modes with no session limits.

Unlike Railway, it is built with platform engineering and DevOps workflows in mind, with environment-level RBAC, templated infrastructure, API-first configuration, and Kubernetes under the hood. Unlike Cloudflare, it provides a full-stack deployment target with Git-native CI/CD rather than a set of composable network primitives.

Deployment options include managed cloud, bring-your-own-cloud (including bare-metal and on-premises), and customer VPC deployments, giving teams control over where their infrastructure runs without changing how they deploy.

Railway runs a Node.js API as a persistent container with long-lived connections, in-memory state, and direct database access within the same project. Cloudflare Workers runs Node.js-compatible code at the edge in a stateless execution model with a 30-second CPU time limit per request by default. For APIs that require persistent connections, connection pooling, or stateful in-memory operations, Railway is the more direct fit. For APIs handling high request volume with short execution times and where global low-latency matters, Workers is worth evaluating.

Cloudflare does not host Postgres or MySQL. Its storage layer consists of D1 (serverless SQLite), R2 (object storage), KV (global key-value), and Durable Objects (stateful compute). Teams that need Postgres can connect Workers to an external Postgres instance via Hyperdrive, which pools and caches connections to reduce latency. Railway runs Postgres as a native service within the same project.

Yes. A common pattern is to run persistent backend services and databases on Railway and use Cloudflare in front for DNS, CDN caching, DDoS protection, and WAF rules. Cloudflare Workers can also handle edge logic, routing, or authentication before requests reach Railway services.

Railway charges per second for CPU and RAM consumed by running containers, regardless of request volume. A service that is idle between requests still incurs compute charges. Cloudflare Workers charges per request and per CPU millisecond consumed, with no charge when idle. For workloads with low or variable request volume, Workers is typically cheaper. For always-on services with steady traffic, Railway's per-second model is predictable and straightforward.

The Workers free tier allows 50ms of CPU time per request. The Workers Paid plan defaults to 30 seconds of CPU time per request, configurable up to 5 minutes by setting the cpu_ms value in the Wrangler configuration. Memory per isolate is limited to 128 MB on both plans.