Cloudflare Workers Alternatives in 2026: Where to Run Backends That Outgrow the Edge

Cloudflare Workers run JavaScript in V8 isolates in hundreds of locations, start in milliseconds and work well for request rewriting, auth at the edge, redirects and small APIs. Teams look for alternatives when the backend grows past that shape: a dependency needs a Node.js API Workers do not implement, an image or PDF job hits the 128 MB memory limit per isolate or the CPU time limit per request, the data has to live in Postgres in one region, or work needs to continue for minutes in the background.

This list covers six alternatives for backends that have outgrown the edge model, starting with the option that deploys full TypeScript and Go services into your own AWS or GCP account.

Cloudflare Workers alternatives at a glance

Full backends in your own AWS or GCP with Encore

Encore is infrastructure from code for TypeScript and Go, with a platform that provisions and deploys into your own AWS or GCP account. Services run on the full Node.js or Go runtime on Fargate, EKS, Cloud Run or GKE, so the libraries that failed on Workers work unchanged, and the databases, queues, cron jobs and buckets the code declares become RDS, SQS and SNS, and S3 on AWS or Cloud SQL, Pub/Sub and GCS on GCP.

A Worker that stores links in KV and counts clicks maps to an endpoint, a Postgres table and a Pub/Sub topic. Publishing enqueues the click so the redirect returns as soon as the message is accepted:

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

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

interface Clicked {
  slug: string;
}
const clicked = new Topic<Clicked>("link-clicked", {
  deliveryGuarantee: "at-least-once",
});

export const resolve = api(
  { expose: true, method: "GET", path: "/links/:slug" },
  async ({ slug }: { slug: string }): Promise<{ url: string }> => {
    const row = await db.queryRow<{ url: string }>`
      SELECT url FROM links WHERE slug = ${slug}
    `;
    if (!row) throw APIError.notFound("link not found");
    // Publish enqueues locally; the subscriber counts the click without blocking the redirect path beyond the enqueue.
    await clicked.publish({ slug });
    return { url: row.url };
  },
);

const _ = new Subscription(clicked, "count-clicks", {
  handler: async ({ slug }) => {
    await db.exec`UPDATE links SET clicks = clicks + 1 WHERE slug = ${slug}`;
  },
});

The migration in links/migrations/1_create_links.up.sql creates the table:

CREATE TABLE links (
    slug TEXT PRIMARY KEY,
    url TEXT NOT NULL,
    clicks BIGINT NOT NULL DEFAULT 0
);

With a links/encore.service.ts exporting new Service("links"), encore run starts Postgres locally, runs the topic in memory and serves the API with a local development dashboard for traces. Pub/Sub handlers retry on error and have dead-letter queues in the cloud, and cron jobs replace Cron Triggers. Teams keeping their files in R2 can point Encore's object storage at Cloudflare R2 while the services run on AWS or GCP.

Encore provisions an IAM role for the service on AWS, keeps secrets in Secrets Manager or Secret Manager, and deploys on every push with the GitHub integration. Coding agents get the same short loop Workers offer: one declaration in code, encore run to test against real Postgres, and a deploy that provisions the resources. Cloud access sits with Encore's IAM role, not the agent.

Encore is regional rather than edge-distributed, so a pure edge use case such as rewriting every request at the closest location still belongs on a CDN.

Best fit: teams whose Workers API has grown into a backend with Postgres, queues and scheduled jobs, and who want it in their own AWS or GCP account.

AWS Lambda

AWS Lambda

Lambda runs functions on full runtimes for Node.js, Python, Java, .NET and Ruby, and Go or Rust through the OS-only runtime, with up to 10,240 MB of memory and a maximum timeout of 15 minutes. It sits inside your AWS account next to RDS, SQS and S3, and scales per request. Cold starts are longer than isolate start times, connections to Postgres from many concurrent functions usually need RDS Proxy, and the surrounding API Gateway, IAM and event source configuration lives in Terraform, CDK or SAM.

Best fit: teams already on AWS who want per-request scaling with full runtimes and are comfortable managing the configuration around the functions.

Google Cloud Run

Google Cloud Run

Cloud Run runs any container image, scales to zero and back, and allows request timeouts of up to 60 minutes, as described in the Cloud Run request timeout docs. Containers remove the runtime restrictions entirely, Cloud Run jobs cover batch work, and Cloud SQL and Pub/Sub are available in the same project. You write and maintain the Dockerfile and the deployment configuration.

Best fit: teams on GCP who want container-level freedom with serverless scaling.

Vercel Functions

Vercel

Vercel Functions run Node.js, Python, Go and other runtimes next to a frontend deployed on Vercel, with Fluid compute reusing instances across concurrent requests. They suit API routes that belong to a Next.js or other frontend app. Databases and queues come from marketplace integrations, and long-running background work is outside what the platform is built for.

Best fit: frontend-led teams whose backend is a set of API routes next to the web app.

Deno Deploy

Deno Deploy

Deno Deploy runs TypeScript on the Deno runtime out of the box, with npm package support through Deno's Node.js compatibility and Deno KV as a key-value database you provision per app. It is a close move for teams who like Workers' developer experience and mostly need better compatibility. Relational data still lives in an external database.

Best fit: teams who want the isolate model with broader npm compatibility.

Fly.io

Fly.io

Fly.io runs your container as Firecracker microVMs in regions you choose, close to users like an edge platform but with long-lived processes, full runtimes, persistent volumes and managed Postgres. Background workers and WebSocket servers run as ordinary processes. You manage machine counts, regions and the fly.toml configuration, and the resources live in Fly.io rather than in your own cloud account.

Best fit: teams who want multi-region long-running processes without going through AWS or GCP.

How to choose

Stay on Workers for logic that has to run at the closest location on every request, such as auth checks, redirects and header rewriting. When the backend needs Postgres in one region, queues and scheduled jobs, the deciding question is where it should live: Encore, Lambda and Cloud Run put it in your own AWS or GCP account, with Encore provisioning the infrastructure from code instead of separate configuration. Vercel Functions and Deno Deploy stay closest to the hosted serverless model, and Fly.io suits multi-region processes on its own platform.

Related guides

• Vercel alternatives
• Render alternatives
• How to deploy a Node.js app to AWS
• Deploy to AWS without Kubernetes