Railway vs Cloudflare: How Their Architectures Differ and When to Use Each

At a high level, you can build and deploy applications on Railway or Cloudflare’s Developer Platform, and the day-to-day experience can feel similar in several ways:

• You don’t interact with traditional infrastructure. Neither service requires you to manage servers, apply OS patches, or work with virtual machines. You avoid low-level operational work such as handling hardware, maintaining SSL certificates, or configuring firewalls.
• Each operates its own global datacenters rather than relying on another Cloud (e.g. AWS, Azure or GCP).
• For compute primitives, pricing is usage based. You’re only billed on active CPU and memory rather than idle capacity.
• Both provide compute and storage primitives suited for modern application development.
• Each offers an integrated developer workflow with features such as:
• Logging
• Metrics
• Environment variables and secrets management
• Git-based deployments with instant rollbacks
• Automatic preview environments for every pull request

While the surface feels similar, the underlying models are not. Railway and Cloudflare make different architectural choices, and impose different constraints which will make you architect your app in a different way. Understanding these differences is essential when choosing one platform or when deciding how to combine them in a single architecture.

Cloudflare is built around an edge-first model. Its main compute primitive, Workers, runs short-lived and stateless functions across Cloudflare’s global network. The network consists of thousands of machines spread across hundreds of locations. Each machine hosts the Workers runtime, workerd, which is based on the V8 engine used by Chromium and Node.js. The environment exposes many Web Platform APIs such as fetch, Streams, and Web Crypto. Not every browser API is available, although coverage continues to expand.

Cloudflare’s global network locations

This model abstracts away all infrastructure, scales automatically based on demand, and provides a lightweight way to run logic close to users. It is a good fit for small, stateless request-response paths, low-frequency workloads, and event-driven systems with minimal overhead.

That said, the serverless model introduces limits that developers need to be aware of.

A Worker runs inside a single-threaded event loop, similar to other JavaScript runtimes. A single instance may handle multiple concurrent requests, and those requests can interleave whenever the runtime awaits an asynchronous operation such as fetch. There is no guarantee that two requests from the same user reach the same instance, and there is no guarantee that different users are isolated from one another. Since global variables belong to the instance rather than the user or request, Cloudflare recommends avoiding global state or treating it as a best-effort cache only. Your code must be written with these constraints in mind.

For example, this code looks innocent, but the value here can jump forward, backward, or get reset depending on how Workers are scheduled:

let counter = 0; // the value here can jump forward, backward, or get reset depending on how Workers are scheduled

export default {
  async fetch() {
    counter++;
    return new Response(counter.toString());
  }
}

Workers also have strict resource limits. The memory cap is 128 MB. CPU time is limited to five minutes for an HTTP request and fifteen minutes for a Cron Trigger. Wall-clock time is not restricted, which means a Worker can continue running as long as the client remains connected. This enables streaming, long-lived responses, and background work via event.waitUntil. What you cannot exceed is your CPU budget. When CPU time runs out, the request terminates.

For example, this task will hit CPU limits even if the client stays connected:

export default {
  async fetch() {
    let sum = 0;
    // long-running task not-fit for running inside a Worker
    for (let i = 0; i < 5_000_000_000; i++) {
      sum += i;
    }
    return new Response(sum.toString());
  }
}

These limits rule out certain classes of workloads on Workers. Anything long-running is a poor fit, including:

• Data processing such as ETL jobs, imports, exports, or analytics pipelines
• Media processing such as transcoding or batch image operations
• Report generation including PDFs or large exports
• Infrastructure tasks such as backups or CI-style jobs
• Billing systems that compute usage, invoices, or retries
• User-level operations such as data merges or account cleanup

Workloads that depend on persistent connections also do not work well:

• Chat systems and live messaging
• Dashboards, tickers, or other real-time analytics
• Collaborative editing and user presence
• Delivery and location tracking
• Push notifications
• Signaling for voice or video calls

All of these expect state that survives across invocations or lasts longer than a single request. Workers have no filesystem and no reliable way to keep state in memory, so they require external systems or for you to introduce additional Cloudflare primitives/services such as:

• Durable Objects: A Durable Object is a special kind of Worker that combines compute with attached, strongly consistent storage. Each Durable Object has a globally unique identifier, which allows you to route requests to a specific object from anywhere in the world. Since the compute and storage are colocated, access is fast and consistent. Durable Objects behave like single-threaded actors: they can hold in-memory state while active, coordinate between clients, handle WebSockets, batch work, or schedule tasks with alarms. When idle, the object hibernates and its in-memory state is cleared, so anything important must be persisted. Storage per object is limited, CPU time follows Worker limits, and each object handles requests sequentially. The main drawback of durable objects is they’re Cloudflare-specific, so if you rely on them, you risk being locked-in.
• Cloudflare Containers: these provide a more familiar execution model and support long-running tasks. Containers start when needed, sleep when idle, and use completely ephemeral disk. When a container shuts down or restarts, its disk is reset to the image. Instance types are fixed with predefined vCPU, memory, and disk sizes. Persistent disk is not supported, and cold starts can take several seconds depending on image size and startup time. They’re not designed to be running 24/7
• Cloudflare Realtime: suite of tools designed to help you build real-time applications
• Cloudflare Images: build an image pipeline where you can store, resize and optimize images

The end result is a distributed system created not because the product requires it, but because the platform architecture makes it unavoidable. Stateless compute at the edge is powerful, but it forces you to assemble multiple primitives to handle state, coordination, batching, or anything that needs to run continuously.

Railway is built around running long-lived containers. Instead of executing short functions inside an isolated JavaScript runtime, Railway gives you full control of a containerized environment.

A service on Railway behaves like a normal server that stays online, keeps its state in memory, and runs whatever language or runtime you choose. The difference is that you only pay for the CPU, memory, and disk your service actively consumes, not for idle instance capacity.

Railway uses a custom builder that takes your source code or Dockerfile and builds a container without any configuration. Whether you deploy a Go API, a Python worker, a Rust binary, a Node.js application, a WebSocket server, or something entirely custom, the platform treats them all the same.

There is no single-threaded event loop, no automatic eviction of memory, and no routing behavior that affects state. Your process stays alive, and your state stays with it.

This makes a difference in even the simplest examples. A counter stored in memory behaves exactly how you expect because the container is long-lived:

// This works as expected on Railway.
// The process is long-lived, so state is stable.

let counter = 0;

import { serve } from "bun";

serve({
  port: 3000,
  fetch(req) {
    counter++;
    return new Response(counter.toString());
  }
});

Railway services run in a single region that you choose. This provides consistent latency, predictable performance, and control over where your data lives. If you want to run globally, you deploy the same service to multiple regions.

Current regions include:

• US West, California
• US East, Virginia
• EU West, Amsterdam
• Southeast Asia, Singapore

Railway regions

When it comes to scaling, each service can scale up to the limits of your plan. On the Pro Plan, a single instance can use up to 32 vCPU and 32 GB of memory. If you need more resources, you can scale horizontally by deploying replicas.

This predictable execution model is one of the main advantages of long-running containers.

Railway also supports persistent volumes, which allow your service to write to disk and preserve that state across restarts. This is essential for workloads such as embedded databases, local caching, indexing, search engines, or any application that needs durable on-disk storage. Cloudflare does not offer anything equivalent, since Workers and Containers both use ephemeral storage.

Railway abstracts away machine provisioning, networking, and OS maintenance, but it does not restrict how your application behaves. You retain access to:

• Persistent volumes
• Long-running processes that never scale to zero
• Custom binaries and system packages
• Background workers, schedulers, and queues
• WebSocket, gRPC, TCP, and any network protocol your container supports
• Multi-process and multi-threaded applications
• Large in-memory workloads such as embeddings, ML inference, or high-performance caching

Railway’s compute model is straightforward: you get a long-running container with predictable resources, stable in-memory state, persistent disk, and the freedom to run any workload that fits inside a process. This makes it a strong foundation for backends, databases, stateful systems, real-time applications, AI workloads, and anything that requires consistent performance without the execution limits of a serverless platform.

The trade-off is that Railway is regional by design. It does not include global routing, a CDN, DNS, or an edge security layer. These are exactly the areas where Cloudflare complements Railway well, and where using the two platforms together becomes a natural fit.

Cloudflare provides several storage primitives, each aimed at a specific use case. They are designed around the serverless execution model rather than around general-purpose application storage. The constraints shape how you build data-heavy or stateful systems.

• Cloudflare KV: Globally distributed key-value store optimized for high read throughput. KV is eventually consistent, which makes it suitable for configuration, feature flags, cached data, and lookups that do not require immediate correctness. It is not appropriate for workflows that depend on coordinated writes or strong consistency.
• Cloudflare D1: SQLite-backed relational database. D1 has size limits, per-query limits, and regional constraints. It works well for small applications and read-heavy workloads, but it is not meant for large datasets, transactional systems, or workloads with high write volume. It behaves more like embedded storage exposed through a serverless interface than a full production database engine.
• Cloudflare R2: S3-compatible Object storage service with no egress fees. R2 is a good fit for user uploads, static files, large assets, and backups.
• Workers Analytics Engine: structured event storage system for analytics and telemetry from Workers. It accepts up to twenty blobs, twenty doubles, and one index per writeDataPoint call. Blob size cannot exceed 16 KB per data point. Each index must be under 96 bytes. You can write a maximum of 25 data points per invocation. Data is retained for three months. These limits make Analytics Engine suitable for lightweight analytics, but not for large pipelines or long-term storage.

Cloudflare’s offerings cover configuration, small relational data, file storage, and short-lived analytics. They work well for serverless functions, but they are not designed to act as a full application storage layer. Large datasets, heavy write workloads, low-latency local access, or complex indexing require a different model.

This is one of the reasons why Cloudflare Hyperdrive exists. It sits on top of external databases and acts as a latency optimization layer. It improves cross-region access by routing connections through Cloudflare’s network. Hyperdrive is not a database itself. It is a proxy that gives Workers a faster path to a remote Postgres/MySQL instance, but the underlying database still lives somewhere else (e.g. on Railway)

Railway has first-class support for Databases. You can one-click deploy any open-source database:

• Relational: Postgres, MySQL
• Analytical: Clickhouse, Timescale
• Key-value: Redis, Dragonfly
• Vector: Chroma, Weviate
• Document: MongoDB

Check out all of the different storage solutions you can deploy.

One-click deploy databases on Railway

Railway takes a general-purpose approach to storage. Instead of offering multiple narrow serverless primitives, Railway gives you full databases and persistent disk that behave like traditional long-running systems.

You get strong consistency, predictable query performance, proper indexing, connection pooling, extensions, and full control over schema design. There are no artificial constraints on dataset size, table count, query complexity, or write volume. You can tune configuration files, mount custom volumes, and run additional processes alongside them. The platform does not impose database-specific limits.

Because storage is deployed in the same infrastructure and communicate over the same network, it makes high-throughput, I/O-heavy workloads viable. It also allows you to design processing pipelines or indexing systems that depend on predictable filesystem behavior.

Railway abstracts away machine provisioning, networking, container orchestration, and OS maintenance. What it does not abstract away is control over what you can deploy. You have the freedom to choose the database, storage engine, or file format that fits your workload instead of forcing the workload to fit the platform. This makes Railway suitable for everything from relational databases to vector stores, blob processing pipelines, embedded engines, and custom storage-backed services.

Cloudflare’s networking stack is one of the most mature and feature-rich parts of the platform. Almost everything Cloudflare does is built on top of this network, and every request flows through it before it reaches your application. The result is a system that handles routing, security, performance, and reliability at a global scale without requiring any infrastructure work on your end.

Cloudflare operates its own global network with data centers in hundreds of locations. Incoming traffic is automatically routed to the closest location, which reduces latency and distributes load across the network. You do not manage servers, proxies, load balancers, or edge nodes. The network handles that by default.

Cloudflare also acts as a fully integrated DNS provider. DNS changes propagate quickly and are globally available, and features like proxying, Workers, caching, SSL, and traffic filtering layer directly on top of your DNS records.

Cloudflare is also a domain registrar, so you can buy and manage domains directly from the same platform that handles DNS and request routing. This keeps your entire networking configuration in one place instead of splitting it across providers.

All inbound requests pass through Cloudflare’s edge. At this point the network can cache responses, optimize delivery, terminate TLS, compress data, upgrade protocols such as HTTP/2 or HTTP/3, or apply traffic steering rules. Cloudflare’s CDN is tightly integrated with its compute and DNS layers, so static assets and cacheable responses are served from the closest location without any configuration on your part.

Security is built into the request path. Cloudflare includes DDoS protection, bot mitigation, IP reputation filtering, traffic shaping rules, and a firewall that you can script or configure per route. Since this inspection happens before your backend is reached, it shields your origin from most forms of abusive or malicious traffic.

Workers tie directly into this routing layer. Since every request hits Cloudflare first, you can run logic at the edge before your backend sees anything. This makes it easy to handle authentication, A/B logic, request validation, rate limiting, redirects, or short-circuiting requests entirely. When combined with caching, many requests never reach your application at all.

If your application has a global audience, or if you want to centralize DNS, routing, edge compute, and security, Cloudflare’s networking model fits naturally. It is designed to front your application and absorb the complexity of global ingress. The end result is a consistent entry point for traffic, fast response times around the world, and a strong security boundary around your backend.

Railway’s networking model is designed to be simple and predictable. Each service runs in a region you choose, and Railway exposes it through public networking, private networking, or both. There is no edge layer or additional routing logic. Traffic reaches your container directly, and your application decides how connections behave.

Railway provides two primary networking modes: public networking and private networking.

Public and Private Networking

Public networking makes a service accessible on the public internet. Once your application listens on the correct port, Railway can assign a generated domain or attach a custom domain you own. TLS certificates are issued automatically through Let's Encrypt. If you use Cloudflare, DNSimple, Namecheap, or another DNS provider, you create a CNAME or ALIAS record pointing to the target Railway provides. Railway handles verification, certificate issuance, and routing traffic to the correct internal port.

Private networking gives services within the same project their own internal network. Each service receives an internal hostname under railway.internal, and traffic to that hostname resolves to the service’s private address. This allows APIs, databases, queues, caches, and workers to communicate without being exposed publicly. Your public service becomes the gateway, while internal components stay private.

The internal network is isolated per project and per environment. Services in different environments cannot communicate through it, and browser-based clients cannot access it because it exists entirely inside Railway’s infrastructure. Private networking supports both IPv4 and IPv6, and most frameworks listen correctly when bound to 0.0.0.0 or ::. For applications that need dual-stack support, listening on :: covers both address families.

Railway also provides a TCP Proxy for workloads that do not use HTTP. This lets you expose databases or custom protocols through a generated TCP endpoint. A service can expose HTTP and TCP at the same time when needed.

The advantage of this model is that Railway does not alter or filter requests. Your container receives the connection exactly as it was sent. Any protocol is allowed. Long-lived connections behave naturally. Internal services talk to each other through the private network, and public services simply bind to a port and receive traffic.

Network simplicity is intentional. Railway handles DNS mapping, TLS certificates, internal addressing, and proxy configuration. You control how your application behaves on top of it.

Railway and Cloudflare solve different parts of the stack, and many applications benefit from using both. Railway provides long-lived containers, persistent storage, and stateful compute. Cloudflare provides global ingress, caching, DNS, and programmable logic at the edge. When paired, you get stable regional backends with reliable global reach.

A common pattern is to run the core of your application on Railway and place Cloudflare in front of it. Railway handles APIs, background workers, databases, and any workload that needs sustained compute or state. Cloudflare handles everything that needs to run close to users: DNS, CDN, edge routing, caching, simple request logic, security filtering, and path rewriting.

Workers are a good fit for light pre-processing. They can validate requests, apply rate limits, add or remove headers, handle redirects, filter traffic, or respond from cache. When the logic becomes heavy, involves state, or requires sustained CPU or memory, the request is forwarded to a Railway service where the application has full control of runtime and storage.

If Workers need to talk directly to a Railway-hosted database, Hyperdrive can help reduce cross-region latency. Hyperdrive is not a database, but a routing layer that accelerates connections from the edge to your existing Postgres instance. This keeps your database on Railway while giving Workers faster access for read-heavy or latency-sensitive paths.

This split keeps each platform focused on its strengths. Cloudflare handles global entry points. Railway handles the application logic.

A straightforward arrangement looks like this:

• Static assets hosted on Cloudflare
• The main backend running on Railway
• Workers acting as an edge layer for routing or validation
• AI, ML inference, or batch compute running inside Railway containers
• Event ingestion through Cloudflare Queues, processed by a Railway worker service

This pairing keeps global traffic fast and resilient while keeping your backend simple and stateful. Cloudflare gives you worldwide reach and protection. Railway gives you predictable compute, persistent storage, and the freedom to design your application without the constraints of a serverless execution environment.

Railway and Cloudflare both aim to reduce infrastructure complexity, but they do so from opposite directions. Cloudflare starts at the edge and works inward. Railway starts with application servers and works outward.

Cloudflare’s model is built around global reach, fast ingress, and lightweight logic that runs as close to users as possible. Its primitives are designed to be small, distributed, and stateless. Workers are fast to start and easy to scale, but the environment imposes limits on execution time, memory, and state. Durable Objects and Containers fill some gaps, but they extend a serverless-first architecture rather than replace it. Cloudflare excels at routing, caching, DNS, and shaping traffic before it reaches your backend.

Railway’s model is built around long-lived processes, persistent storage, and full control of the execution environment. A service is a container that behaves like a normal server. You get predictable performance, stable in-memory state, and the ability to run any workload that fits inside a Linux process. Databases run continuously with colocated storage. Background workers, schedulers, and real-time connections all behave naturally. Railway focuses on application compute, not edge distribution.

Both platforms share the same goal: make infrastructure feel invisible. They just take different routes to get there.

If your application is stateful, compute-heavy, or relies on a specific runtime or storage engine, Railway is the natural foundation. If your application serves a global audience, needs caching or routing at the edge, or benefits from request handling close to users, Cloudflare fits that layer well. Most modern architectures benefit from using both. Cloudflare becomes the front door for traffic, and Railway becomes the place where the actual application logic and data live.

The key is to lean into each platform’s strengths rather than force them into roles they were not designed for.

That is the practical takeaway: use Cloudflare to make your application globally accessible and protected, and use Railway to run the parts of your system that need state, storage, or sustained compute. The boundary between the two becomes clear, and the architecture becomes easier to reason about and evolve over time.