How to migrate from Cloudflare Workers to a VPS

For a successful migration from Cloudflare Workers to a VPS, it is necessary to move application logic to the Node.js or Bun runtime, replace proprietary KV, D1, and R2 storage with open-source equivalents (Redis, PostgreSQL, MinIO), and configure a reverse proxy. This allows you to remove CPU execution time limits and reduce costs when scaling on servers starting from $5 per month.

Moving from serverless solutions to your own servers is a natural stage in a project's development when platform limitations start to hinder growth or the budget. Cloudflare Workers is attractive because of its easy start, but as logic becomes more complex, developers face strict CPU usage limits (50ms on the free tier and up to 30s on the paid tier), a lack of support for many NPM packages, and a specific API. In this article, we will look at how to migrate from cloudflare workers to a VPS while maintaining performance and reliability.

Reasons to migrate from cloudflare workers to dedicated resources

The main drivers for migration are usually economic feasibility and the technical limitations of the V8 Isolates runtime. Unlike standard virtual machines, Workers operate in a restricted environment where there is no access to the file system or full socket connections without additional layers.

CPU and Memory Limits

In Cloudflare Workers, code execution time (CPU time) is strictly limited. If your script performs complex mathematical calculations, image processing, or heavy cryptography, you will quickly hit the 50ms limit. On a VPS, you get full access to CPU resources (e.g., 2-4 cores at 3.0+ GHz) without artificial interruptions. This is especially critical if you plan to use the server for machine learning tasks, which you can read more about in the article Bare-metal vs VPS for ML inference on CPU: which is more profitable.

Cost at High Traffic

Cloudflare charges based on the number of requests. When reaching millions of requests per day, bills begin to grow exponentially. Renting a VPS with a fixed price ($10–$20 per month) allows you to handle virtually unlimited traffic, limited only by network bandwidth (usually 1 Gbps) and hardware power. This situation is also common when using other PaaS solutions, which is why many look for ways on how to move from Railway to VPS in 2026.

Choosing a Stack: Node.js or Bun as a workers alternative

When looking for a suitable workers alternative, the choice of runtime becomes a key factor. Cloudflare Workers use a subset of APIs close to the browser (Fetch API), so your code will not run "as is" in standard Node.js without adaptation.

Bun — The Closest Experience to Workers

Bun is a modern runtime that supports Fetch API, Request, and Response out of the box. This makes it an ideal candidate for migration. A simple example of a server in Bun that replaces Worker logic:

Bun.serve({
  port: 3000,
  async fetch(request) {
    const url = new URL(request.url);
    if (url.pathname === "/api") {
      return new Response(JSON.stringify({ status: "ok" }), {
        headers: { "Content-Type": "application/json" },
      });
    }
    return new Response("Not Found", { status: 404 });
  },
});

Node.js and Fastify/Hono

If you need maximum stability and a huge ecosystem of libraries, Node.js remains the standard. To minimize code changes, it is recommended to use the Hono framework. It was originally developed for Edge environments (Workers) but works perfectly on Node.js via adapters. This significantly simplifies workers migration, as routing and middleware remain identical.

Replacing Cloudflare Infrastructure (KV, D1, R2) on a VPS

The most difficult part of the move is replacing Cloudflare's proprietary data storage services with their open-source equivalents. On a VPS, you manage the data yourself, which gives more flexibility but requires setting up backups.

Workers KV Alternative: Redis or Dragonfly

Workers KV is a key-value store with eventual consistency. On a VPS, the best choice is Redis. It provides latency of less than 1 ms and supports complex data types (lists, sets), which are not available in KV.

• Installation: sudo apt install redis-server
• Memory Capacity: Depends on your VPS plan (from 2 GB RAM).
• Performance: Up to 100,000+ operations per second on a single core.

Replacing D1 with PostgreSQL or SQLite

Cloudflare D1 is based on SQLite. If your application is small, you can continue using SQLite locally on the VPS. However, for high-load systems, it is better to switch to PostgreSQL. This will give you full transactions, window functions, and high reliability. The database migration process often matches what is described in the guide on how to move from Fly.io to VPS.

R2 → MinIO or S3-Compatible Storage

Cloudflare R2 is S3 without egress fees. On a VPS, you can deploy MinIO. This is a self-hosted object storage that is fully compatible with the AWS S3 API. If your VPS has 50-100 GB NVMe drives, you will get a massive boost in read/write speed compared to a remote cloud.

Step-by-Step Workers Migration Plan: From Code to Deployment

The workers migration process requires a systematic approach to avoid downtime. We recommend using Docker to package the application, making it portable and independent of the server environment.

1. Code Adaptation: Replace Cloudflare global objects (e.g., env.MY_KV) with environment variables or configuration files. Use the dotenv library for Node.js.
2. Creating a Dockerfile: Write a configuration to build the image. Example for Bun:

   
   FROM oven/bun:latest
   WORKDIR /app
   COPY package.json .
   COPY bun.lockb .
   RUN bun install
   COPY . .
   EXPOSE 3000
   CMD ["bun", "run", "index.ts"]
           

3. Database Setup: Deploy PostgreSQL or Redis in Docker containers or install them directly in the OS.
4. Data Transfer: Export data from KV via the Wrangler CLI and import it into Redis. For D1, use an SQL dump.

Many developers who decide to migrate from cloudflare workers note that using Docker simplifies life not only during deployment but also during local development. Similar steps are taken when the task is how to move from Vercel/Netlify to VPS.

Configuring the Network Layer when moving cloudflare to vps

When using Cloudflare Workers, you didn't have to worry about SSL certificates, DDoS protection, and load balancing. When moving cloudflare to vps, these tasks fall on your shoulders (or Nginx configurations).

Nginx as a Reverse Proxy

Nginx will accept incoming requests and forward them to your application (Node.js/Bun) running on a local port. This is standard practice for ensuring security and enabling horizontal scaling.

server {
    listen 80;
    server_name api.yourdomain.com;

    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

SSL and Security

To obtain free SSL certificates, use Certbot (Let's Encrypt). It is also recommended to keep Cloudflare in "Proxy" mode (orange cloud) to use their DDoS protection and CDN, but point the traffic to the IP of your new VPS. This way, you keep the benefits of the Cloudflare global network but get rid of Workers' limitations.

Cost and Performance Comparison

Below is a table comparing characteristics and costs when using Cloudflare Workers versus a typical VPS from Valebyte. Data is based on average figures for projects with a load of 5-10 million requests per month.

Feature	Cloudflare Workers (Paid)	VPS (Standard Plan)	Advantage
CPU Time Limit	30 seconds	No limits	VPS
RAM	128 MB	2 GB - 16 GB	VPS
Cost (10M req)	~$5.00 + KV/D1 costs	$5.00 - $12.00 (fixed)	VPS (at scale)
Data Storage	KV / D1 (paid limits)	SSD/NVMe (included)	VPS
Cold Starts	0-50ms	0ms (always running)	VPS

As seen from the table, at a comparable base price, a VPS offers orders of magnitude more resources. This is especially important for applications requiring persistent connections (WebSockets), which are significantly more expensive in Workers or have session lifetime limits.

Monitoring and Logging After Migration

In Cloudflare Workers, logs are available through the control panel or wrangler tail. On a VPS, you will need to set up your own monitoring system. To start, PM2 is sufficient for managing Node.js processes and viewing logs in real-time.

• PM2: Automatically restarts the application on crashes and allows viewing logs with the pm2 logs command.
• Grafana + Prometheus: For deep monitoring of CPU, RAM, and network traffic load.
• Uptime Kuma: A simple self-hosted tool to check your API availability.

Don't forget that owning the infrastructure gives you full control over your data. You can store logs for years for security audits without overpaying for cloud storage volume. If you previously used Heroku, the process of setting up monitoring on a VPS will be familiar to you; more on this in the article How to move from Heroku to VPS in 2026: a step-by-step guide.

Latency and Geo-distribution

One of the main arguments for Workers is the "Edge" — executing code as close to the user as possible. When moving to a single VPS, latency for users on the other side of the world may increase. However, for most applications, a latency of 100-150 ms is not critical, while the database speed on the same server (locally) is significantly higher than accessing a remote KV or D1 from an Edge function.

If low latency is critical, you can rent two cheap VPSs in different regions (e.g., Europe and the US) and configure GeoDNS through Cloudflare. This will still be cheaper and more powerful than using Enterprise plans of serverless platforms.

Conclusions

Migration from Cloudflare Workers to a VPS is justified if your application requires more than 50 ms of CPU time, file system access, or predictable costs at high traffic volumes. The optimal choice for moving code is the Bun or Node.js environment with the Hono framework, and for the database — a combination of PostgreSQL and Redis on a server with an NVMe drive.