Vercel vs Railway: Where Should Your Backend Run

Vercel and Railway both promise a deploy that takes minutes, but they run code in different shapes. Vercel runs your backend as functions that start per request and stop when the request ends. Railway runs your backend as a long-lived service, closer to a server you would run yourself, with databases on the same project canvas.

That difference decides most of the comparison: a backend made of request handlers next to a Next.js app fits Vercel, and a backend with WebSockets, queue consumers or long jobs fits Railway. This guide covers both, and Encore (infrastructure from code) for teams that want their backend in their own AWS or GCP account.

Vercel vs Railway at a glance

Each option is covered below, starting with Encore.

Running the backend in your own cloud with Encore

Encore is infrastructure from code for TypeScript and Go, with a platform that deploys into your own AWS or GCP account. Services run as long-lived containers on Fargate or Cloud Run, so WebSockets, queue consumers and long requests work as they would on Railway. Databases, topics and cron jobs are declared in code and provisioned in your AWS account or GCP project.

A checkout that stores the order and hands the receipt to a background consumer looks like this:

// orders/orders.ts
import { api } from "encore.dev/api";
import { Topic, Subscription } from "encore.dev/pubsub";
import { SQLDatabase } from "encore.dev/storage/sqldb";
import log from "encore.dev/log";

const db = new SQLDatabase("orders", { migrations: "./migrations" });

export interface OrderPlaced {
  orderId: string;
  email: string;
  totalCents: number;
}

export const orderPlaced = new Topic<OrderPlaced>("order-placed", {
  deliveryGuarantee: "at-least-once",
});

export const place = api(
  { expose: true, method: "POST", path: "/orders" },
  async (req: OrderPlaced): Promise<{ messageId: string }> => {
    const messageId = await orderPlaced.publish(req);
    return { messageId };
  },
);

const _ = new Subscription(orderPlaced, "send-receipt", {
  handler: async (event) => {
    const inserted = await db.queryRow`
      INSERT INTO receipts (order_id, email) VALUES (${event.orderId}, ${event.email})
      ON CONFLICT (order_id) DO NOTHING
      RETURNING order_id`;
    if (!inserted) return;
    log.info("receipt sent", { orderId: event.orderId });
  },
  retryPolicy: { maxRetries: 5, minBackoff: "10s" },
});

The migration in orders/migrations creates the receipts table the queries use:

-- orders/migrations/1_create_receipts.up.sql
CREATE TABLE receipts (
    order_id TEXT PRIMARY KEY,
    email TEXT NOT NULL
);

On Vercel the consumer would need a separate queue product, and on Railway a separate worker service. Here it is a subscription that becomes SNS and SQS on AWS or Pub/Sub on GCP, with retries and a dead-letter queue. encore run starts the database and a local Pub/Sub so the whole flow runs on your machine. Many teams keep the frontend on Vercel and call the Encore backend through a generated client.

The cron jobs docs cover scheduled work, and the deployment guide covers the push-to-deploy flow.

Vercel: functions next to your frontend

Vercel is the natural home for a Next.js app, and API routes deploy with it as functions. Preview deployments per branch, a global edge network and zero configuration make it a strong fit for the frontend.

The backend story follows from the function model: with Fluid compute, which is on by default for new projects, functions run for up to 300 seconds by default, according to the function limits. Cron Jobs are entries in vercel.json that call a function path on a schedule. Postgres, Redis and similar services come from Marketplace providers, and asynchronous work goes through Vercel Queues, a separate product. A backend that uses several of them is spread across several products and vendors.

Railway: long-running services and a project canvas

Railway runs your backend as a service that stays up, so WebSockets, in-memory caches and queue consumers behave as they do on your laptop. Postgres and Redis come from templates and connect through variable references such as ${{Postgres.DATABASE_URL}}, and preview environments copy the project per pull request.

On Railway, the trade-offs are operational: databases are services with volumes that you back up and upgrade, a queue means running a worker and a broker, and cron jobs are services that must exit when done, with runs at least five minutes apart. The optional Serverless setting sleeps idle services, which saves money and adds a cold start.

Cost, briefly

Vercel bills functions by usage and adds per-product charges for things like Marketplace databases and queues. Railway bills services and databases by resource usage. Which is cheaper depends on traffic shape: bursty, short requests favor functions, while steady load and background work favor long-running services. Check both current pricing pages before deciding.

How to choose

Pick Encore when the backend needs databases, queues and cron jobs in your own AWS or GCP account, with long-running services and a full local environment. See Encore vs Vercel and Encore vs Railway.

Pick Vercel when the backend is a set of light handlers next to a Next.js frontend. Pick Railway when you want long-running services and databases on one canvas and are comfortable operating the database yourself.

Related guides

• Vercel alternatives
• Railway alternatives
• Railway vs Fly.io
• Render vs Fly.io