Coming from Vercel
Move backend workloads while keeping the frontend on Vercel
Vercel can build a frontend and deploy backend code as Functions or as part of a multi-framework Vercel Services project. A common migration keeps the frontend on Vercel and moves its APIs and background workloads to Encore. In Encore, those workloads and their infrastructure are declared with the TypeScript or Go SDK and form an application model used for local development and deployment.
How the concepts map
| Vercel | Encore |
|---|---|
| Project environment | Encore environment |
| Vercel Service | One or more Encore services; the boundary is defined in application code |
| Function or route handler | Encore API endpoint within a service |
| Fluid compute configuration | Environment compute configuration; not a per-function declaration |
| Cron Job | Cron job calling an API endpoint |
| Marketplace Postgres integration | SQL database or an external database |
| Marketplace KV or Redis integration | Cache for supported operations, or external Redis |
| Vercel Queues (Beta) topic and consumer group | Pub/Sub topic and subscription, after reviewing delivery semantics |
| Vercel Blob | Object storage or continued use as an external service |
| Environment variable | Secret, constant, or external configuration |
| Preview deployment | Preview environment |
These primitives are declared in application code using TypeScript or Go.
An Encore endpoint is not deployed as an independently configured Vercel Function. Encore analyzes calls and resource usage across the application and deploys services according to the target environment.
Move backend routes
Define Vercel API routes, route handlers, or server actions that form a public backend contract as Encore API endpoints. For a Vercel Services project, map routes and service bindings before deciding which boundaries to preserve. Keep rendering and frontend-only server logic on Vercel when it benefits from the framework's request lifecycle.
Update the frontend to call the Encore environment URL. For browser requests, configure the required CORS behavior and authentication explicitly. Do not move server actions mechanically: code coupled to framework rendering, cookies, or cache invalidation may be better left on Vercel, calling Encore as its backend.
Long-running or asynchronous work should not be mapped solely by function duration. Use Pub/Sub when work is driven by an event and cron jobs when it is scheduled. When replacing Vercel Queues, review retention, retries, ordering, idempotency, and deployment isolation rather than treating its topics and consumer groups as exact equivalents.
Move data and scheduled work
Vercel storage products and marketplace integrations are separate services, so migration depends on the provider behind each integration.
- For Postgres, either keep the provider as an external dependency or transfer data to an Encore database. Encore Cloud can directly connect supported existing RDS, Cloud SQL, and Neon databases; other providers require a data transfer or self-hosted mapping.
- Encore caching is not a full Redis interface. Confirm required commands and persistence behavior before replacing a KV or Redis integration.
- Move Blob objects to an Encore bucket only after accounting for object keys, metadata, access URLs, upload flows, and consistency during cutover. Blob can remain external in the interim.
- Recreate Vercel Cron Jobs as Encore cron declarations. Encore cron invokes an API endpoint; confirm the schedule, authentication assumptions, time zone, retries, and idempotency.
Move sensitive environment variables to Encore secrets. Variables still needed by the frontend or its Vercel build remain in Vercel. Values exposed to browser bundles are not secrets and should not be copied into Encore merely to hide them.
Deployments and domains
The frontend and backend can use separate deployment workflows. Vercel can continue producing frontend preview deployments while Encore creates backend preview environments. If previews must be paired, pass the relevant Encore preview URL to the frontend build or use a stable development environment; this association is not automatic.
Use an Encore custom domain for the backend, or proxy an API path from the frontend domain. Verify cookies, CORS, OAuth callback URLs, CSP rules, and any firewall allowlists before switching traffic.
Migration plan
- Separate frontend rendering concerns from backend APIs and background work.
- Move one API route group to an Encore service and call it from the Vercel deployment.
- Move only the environment variables required by that backend code.
- Decide separately whether each database and storage integration stays external or migrates.
- Recreate cron and asynchronous work, then test retries and duplicate delivery.
- Pair preview deployments if required, verify the production domain, and shift API traffic.
Vercel-specific features such as ISR, Routing Middleware, image optimization, and framework cache controls are frontend or platform concerns rather than Encore equivalents. They can remain on Vercel.
For shared guidance, see Coming from a PaaS. Vercel behavior referenced here is documented in Functions, Services, Queues, Cron Jobs, Environment Variables, and Storage.