How to Move a Node.js Backend from Vercel to AWS

Many Node.js backends on Vercel started as a few files in api/ or app/api/ next to a Next.js frontend: a POST /api/orders function that writes to Postgres from the Neon integration, a GET /api/invoices/[id] that hands out a Blob URL, and a vercel.json with a crons entry that hits /api/cron/expire every hour. It starts to pinch when the functions need background work that outlives a request, when connection counts from many short-lived function instances hit the database limit, or when the backend has to run in an AWS account the company controls.

This guide moves the backend part onto Encore in your own AWS account and leaves the frontend on Vercel. The API becomes a long-running service with its own database, schedule and bucket, tested locally with encore run, and the frontend switches to calling its URL. The generic Vercel to AWS migration guide covers the hosting side, including moving the frontend.

Vercel to AWS mapping for a Node.js backend

Encore: the backend as one service with its infrastructure in the code

Encore combines an open source infrastructure SDK for TypeScript and Go with a platform that provisions what the code declares in your own AWS or GCP account. The functions become endpoints in a service that stays running, which holds a connection pool to Postgres and can publish work to a queue, and encore run starts the service with Postgres and a local bucket so the whole backend runs on a laptop without the Vercel CLI.

Install the CLI and create the Encore app in its own directory, such as backend/ next to the Next.js app:

API routes become endpoints

The Postgres connection that each function opened from POSTGRES_URL becomes a database declared once per service. The existing schema goes into numbered SQL files in shop/migrations:

// shop/db.ts
import { SQLDatabase } from "encore.dev/storage/sqldb";

// Replaces the managed Postgres add-on: a local database under `encore run`,
// RDS when deployed to AWS.
export const db = new SQLDatabase("shop", { migrations: "./migrations" });

Each route handler becomes an endpoint with typed input and output. Validation errors and missing rows turn into 400 and 404 responses through APIError:

// shop/orders.ts
import { api, APIError } from "encore.dev/api";
import { db } from "./db";

export interface Order {
  id: number;
  email: string;
  totalCents: number;
  status: string;
}

export const createOrder = api(
  { expose: true, method: "POST", path: "/orders" },
  async (p: { email: string; totalCents: number }): Promise<Order> => {
    if (!p.email.includes("@") || p.totalCents < 0) {
      throw APIError.invalidArgument("a valid email and a non-negative total are required");
    }
    const order = await db.queryRow<Order>`
      INSERT INTO orders (email, total_cents) VALUES (${p.email}, ${p.totalCents})
      RETURNING id, email, total_cents AS "totalCents", status`;
    return order!;
  },
);

export const getOrder = api(
  { expose: true, method: "GET", path: "/orders/:id" },
  async ({ id }: { id: number }): Promise<Order> => {
    const order = await db.queryRow<Order>`
      SELECT id, email, total_cents AS "totalCents", status FROM orders WHERE id = ${id}`;
    if (!order) throw APIError.notFound("order not found");
    return order;
  },
);

Without the /api prefix from Vercel, either add it to each path or rewrite it on the frontend side. Endpoints are documented in the local development dashboard, and encore gen client writes a typed TypeScript client the Next.js app can import, as the client generation docs describe.

Vercel Cron becomes a cron job

A crons entry in vercel.json calls a route over HTTP, which means the route is public unless you check the CRON_SECRET header. An Encore cron job calls a private endpoint instead, which is not reachable from the internet:

// shop/jobs.ts
import { api } from "encore.dev/api";
import { CronJob } from "encore.dev/cron";
import { db } from "./db";

// Only touches rows that are still pending, so a repeated run is harmless.
export const expirePending = api(
  { expose: false, method: "POST", path: "/internal/expire-pending" },
  async (): Promise<{ cancelled: number }> => {
    const rows = await db.queryAll`
      UPDATE orders SET status = 'cancelled'
      WHERE status = 'pending' AND created_at < now() - interval '24 hours'
      RETURNING id`;
    return { cancelled: rows.length };
  },
);

// Replaces the scheduler entry on the old platform.
const _ = new CronJob("expire-pending", {
  title: "Cancel orders left pending for a day",
  every: "1h",
  endpoint: expirePending,
});

Cron jobs do not run under encore run, so call the endpoint directly while developing. Once deployed, remove the crons entry from vercel.json in the same release.

Blob becomes a bucket

Files the app stored in Vercel Blob move to an object storage bucket. The frontend asks the API for a short-lived signed URL and downloads from S3 directly:

// shop/uploads.ts
import { api } from "encore.dev/api";
import { Bucket } from "encore.dev/storage/objects";

// Replaces files written to a mounted volume or a hosted blob store:
// a local bucket under `encore run`, S3 when deployed to AWS.
export const invoices = new Bucket("invoices");

export const uploadInvoice = api(
  { expose: true, method: "POST", path: "/invoices/:id" },
  async ({ id, contents }: { id: string; contents: string }): Promise<{ key: string }> => {
    const key = `invoice-${id}.txt`;
    await invoices.upload(key, Buffer.from(contents), { contentType: "text/plain" });
    return { key };
  },
);

export const invoiceLink = api(
  { expose: true, method: "GET", path: "/invoices/:id/link" },
  async ({ id }: { id: string }): Promise<{ url: string }> => {
    const { url } = await invoices.signedDownloadUrl(`invoice-${id}.txt`, { ttl: 300 });
    return { url };
  },
);

For larger files, signedUploadUrl lets the browser upload straight to the bucket as well. Running it all locally:

Pointing the frontend at the new API

Add the production frontend's domain to allow_origins_with_credentials under the global_cors key in encore.app if the browser sends cookies, as the CORS docs describe, and set the API URL as an environment variable in the Vercel project. Unauthenticated requests from any origin are allowed by default.

After you connect your AWS account and push, Encore provisions the RDS database, the S3 bucket, the schedule and the Fargate service in your own account, and provisions an IAM role for the service. Each pull request can get a preview environment, which pairs with Vercel's preview deployments of the frontend.

A coding agent can carry a feature across both halves in one branch: the endpoint and its table in backend/, the page that calls it in the Next.js app, with encore run and next dev side by side to check the result.

The manual AWS path

Without Encore, the closest match to Vercel functions on AWS is Lambda:

• Package each route as a Lambda function, or the whole Express app with an adapter, behind API Gateway or a Lambda function URL.
• Create an RDS for PostgreSQL instance in a VPC and put RDS Proxy in front of it, because each concurrent Lambda instance opens its own connection.
• Move Blob files to an S3 bucket, grant the functions s3:GetObject and s3:PutObject, and generate presigned URLs with the AWS SDK.
• Replace the crons entries with EventBridge Scheduler schedules that invoke the functions.
• Store environment variables in Secrets Manager and read them at cold start.

An ECS service on Fargate avoids the connection problem at the cost of a load balancer, a task definition and an image pipeline.

Moving the data

Postgres created through Vercel now runs on Neon, which accepts standard pg_dump connections. Pause writes on the frontend, dump in custom format and restore the data into the Encore database:

Use the direct (non-pooling) connection string for the dump, since pg_dump does not work well through a transaction-mode pooler, and check the pg_dump docs if you need to exclude tables. Copy Blob files to the bucket with a one-off script that lists them and uploads each one with the same key.

How to choose

• Encore if you want the backend as a long-running service with its database, schedule and bucket in TypeScript, running in your own AWS account, and the frontend left where it works well.
• Manual AWS with Lambda and RDS Proxy if you want to keep the function-per-route model and already manage AWS with Terraform or CDK.

Vercel alternatives covers frontend and full-stack platforms, and How to deploy Node.js to AWS compares every AWS compute option.

Related guides

• How to migrate from Vercel to AWS
• How to move a Node.js backend from Heroku to AWS
• How to move a Node.js backend from Railway to AWS
• How to deploy Node.js to AWS
• Vercel alternatives