--- title: How to migrate from Render to Vercel description: "Migrate from Render to Vercel: map web services, cron jobs, and containers to their equivalents, and handle what doesn't move." url: /kb/guide/migrate-render-to-vercel canonical_url: "https://vercel.com/kb/guide/migrate-render-to-vercel" published: 2026-08-11 last_updated: 2026-08-11 authors: Ben Sabic related: - /docs/functions/container-images - /kb/guide/docker-on-vercel-vs-render - /docs/frameworks/more-frameworks - /docs/cron-jobs - /docs/services - /kb/guide/migrate-fly-io-to-vercel - /kb/guide/migrate-railway-to-vercel - /kb/guide/migrate-cloud-run-to-vercel - /kb/guide/does-vercel-support-docker-deployments - /blog/dockerfile-on-vercel install_vercel_plugin: npx plugins add vercel/vercel-plugin --- To migrate from Render to Vercel, move any data off persistent disks, let framework detection deploy services built on a supported framework, add a [`Dockerfile.vercel`](https://vercel.com/docs/functions/container-images) for the rest, set the `PORT` environment variable in project settings, and recreate your environment variables and cron jobs. Background workers stay behind or get restructured. This guide maps each Render concept to its Vercel equivalent, walks the migration in seven steps, and states plainly what has no equivalent. ## Should your app move? Render builds services from native language runtimes, from Dockerfiles, and from prebuilt Docker images. All three paths can land on Vercel, but the service itself has to fit. Three questions settle it: 1. Does it answer HTTP requests? Vercel Functions running container images are expected to open an HTTP server. Web services fit. Background workers and other always-on processes that never receive a request don't. 2. Does it write to an attached disk? Render persistent disks have no Vercel equivalent. The data has to move to a managed database, cache, or blob store before the service does. 3. Can it shut down in 30 seconds? On Vercel, a scaled-down container receives `SIGTERM` with a 30-second grace period. Render lets you stretch its shutdown delay to 300 seconds; Vercel does not. If you answered yes to the first and third and can relocate any disk data, the migration is mechanical from here. If you're still weighing the platforms rather than planning the move, [Running Docker on Vercel vs Render](https://vercel.com/kb/guide/docker-on-vercel-vs-render) compares them directly; this guide assumes the decision has been made. ## How do Render concepts map to Vercel? | On Render | On Vercel | | ----------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | Web service on a native runtime (Build Command and Start Command) | Framework detection deploys Express, FastAPI, Django, Go, and many others with minimal configuration | | Web service on the Docker runtime | A `Dockerfile.vercel` at the project root, built and pushed to Vercel Container Registry during the build | | Web service from a prebuilt image | The Dockerfile that produces that image, added as `Dockerfile.vercel`; Vercel builds and pushes the image itself during the build step | | Private service | A service under the `services` key in `vercel.json`, internal by default | | Cron job | A cron job in `vercel.json`, triggered by an HTTP GET to your chosen path | | Background worker | No equivalent; restructure around HTTP and cron, or keep it on Render | | Persistent disk | No equivalent; move data to a managed database, cache, or blob store first | | Environment variables | Environment variables in project settings, with sensitive values supported | | `PORT` (defaults to 10000) | Traffic goes to port 80 unless you set `PORT` in project settings | | Blueprints (`render.yaml`) | The `services` key plus `rewrites` in `vercel.json` | | Pre-deploy command | No equivalent; run migrations from CI | | Health check path | No equivalent; validate on a preview deployment | Containers deployed this way run as Vercel Functions on Fluid compute with Active CPU pricing: you're billed for CPU when your code actively runs, not while it waits on I/O. ## Migration steps ### 1\. Inventory your Render services List every service and note its type: web service, private service, background worker, or cron job. For each one, record the runtime (native, Docker, or prebuilt image), any attached disk, the health check path, the pre-deploy command, and any `PORT` override. Web services and cron jobs move directly. Background workers and disk-backed services need a decision first; see "What doesn't map from Render" below. ### 2\. Move data off persistent disks Vercel has no persistent disk, so anything your service writes to an attached disk needs a new home before you migrate: a managed database, a cache, or blob storage. Backing services like these are available through the Vercel Marketplace. Do this step first, since it's the one most likely to require code changes. ### 3\. Check framework detection before writing any config If your Render service uses a native runtime with a Build Command and a Start Command, such as `npm install` and `npm start`, you may not need a container at all. Vercel deploys a [long list of frameworks](https://vercel.com/docs/frameworks/more-frameworks) with minimal configuration, including Express, Fastify, NestJS, Koa, Hono, FastAPI, Flask, Django, Go, Next.js, Nuxt, SvelteKit, and Astro. Reach for a container when detection doesn't apply: a backend in a language or runtime outside the list, system libraries such as FFmpeg or Chromium, a framework Vercel doesn't detect, or a need for identical behavior across environments. ### 4\. Add a Dockerfile.vercel where you need a container Place a `Dockerfile.vercel` (or `Containerfile.vercel`) at the root of the project. Vercel [detects the file automatically](https://vercel.com/docs/functions/container-images) and adds a rewrite that routes all traffic to the container image; during the build step, the image is built and pushed to Vercel Container Registry. If your Render service deploys from a prebuilt image, start from the Dockerfile that produces that image, because Vercel builds and pushes the image itself as part of the build. ### 5\. Set the port and environment variables On Render, your server binds host `0.0.0.0` and the `PORT` environment variable defaults to 10000. On Vercel, the container must open an HTTP server, and traffic goes to port 80 unless you set `PORT` in the project settings. If your server already reads `PORT` from the environment, set that variable in project settings and you're done. An `ENV PORT` line in the Dockerfile does not control Vercel's routing; only the project setting does. While you're in project settings, recreate the remaining Render environment variables. Sensitive values are supported, so credentials move here too. ### 6\. Recreate cron jobs and multi-service wiring Render cron job services become [Vercel cron jobs](https://vercel.com/docs/cron-jobs) declared in `vercel.json`. Vercel triggers each one with an HTTP GET request to the configured `path` on your production deployment, so the job's logic becomes an HTTP handler. Requests carry the `vercel-cron/1.0` user agent, and the timezone is always UTC. If a Render Blueprint runs several services together, declare them with [services](https://vercel.com/docs/services) in `vercel.json`, each with its own `root`. Services are internal by default; a top-level rewrite with a service `destination` is what exposes one to the internet. For a service you want built as a container image, set `runtime` to `container` and `entrypoint` to the Dockerfile path relative to the service root: ```json { "services": { "web": { "root": "web/" }, "api": { "root": "api/", "runtime": "container", "entrypoint": "Dockerfile.vercel" } }, "rewrites": [ { "source": "/api/(.*)", "destination": { "service": "api" } }, { "source": "/(.*)", "destination": { "service": "web" } } ] } ``` Render private services that only other services call map to bindings: the calling service declares a binding, and Vercel injects the target service's URL as an environment variable, so services reach each other without hardcoded URLs and without a public route. ### 7\. Run it locally, deploy, and validate on a preview `vercel dev` runs your container locally; it requires the `docker` CLI and a running Docker daemon. With services configured, `vercel dev` runs all of them together. Then push a commit: every commit gets an immutable preview deployment with its own URL. Check the port wiring, the cron handler, and the service routing on the preview before sending production traffic. This is also the moment to move anything that lived in Render's pre-deploy command, such as database migrations, into your CI pipeline. ## What doesn't map from Render Persistent disks. There is no equivalent on Vercel. Move the data to a managed database, cache, or blob store from the Vercel Marketplace before migrating the service. Background workers and always-on processes. Vercel's model is request-driven, so a process that runs around the clock without receiving requests doesn't fit. Restructure the work around HTTP endpoints and cron jobs, or keep the worker on Render and split the system across both platforms. The pre-deploy command. No hook runs between the build finishing and the deployment going live on Vercel. Run database migrations and similar release tasks from CI instead. The health check path. The container image docs define no health-check configuration. Validate each deployment on its preview URL before it serves production traffic. Secure Compute and Static IPs. Neither is supported with custom container images yet, and the standard Vercel Functions limits apply. If your Render service reaches a database through an IP allowlist, plan around this before moving. Configurable shutdown. Render sends `SIGTERM` 60 seconds after cutover and `SIGKILL` if the process outlives the shutdown delay, which defaults to 30 seconds and is configurable up to 300 via `maxShutdownDelaySeconds`. On Vercel, a function with no production traffic for 5 minutes (30 seconds in preview) scales down, and the container receives `SIGTERM` with a fixed 30-second grace period. Cleanup work has to finish within those 30 seconds. ## Frequently asked questions ### Do I need to change my Dockerfile to move from Render to Vercel? Usually not, beyond naming: Vercel detects a Dockerfile.vercel or Containerfile.vercel at the project root, so rename or copy your existing Dockerfile. The main difference is the port: Render sets the PORT environment variable to 10000 by default, while Vercel routes traffic to port 80 unless you set PORT in project settings. If your server reads PORT from its environment, it runs on both platforms without a Dockerfile change. An ENV PORT line in a Dockerfile does not control Vercel routing; set the variable in project settings instead. ### What replaces Render's pre-deploy command? Nothing directly: Vercel has no hook that runs between the build finishing and the deployment going live. Move database migrations and similar release tasks into your CI pipeline so they run before the new deployment takes traffic. Render's pre-deploy command already executes on a separate instance from your running service, so tasks written for it tend to port to CI without changes. ### Can I move my Render background workers to Vercel? No. Render background workers can't move to Vercel as they are: Vercel's model is request-driven, so a worker that runs around the clock pulling jobs from a queue has no equivalent. Restructure the work around HTTP endpoints and cron jobs, or keep the worker on Render and run the two platforms side by side. ### Can I keep using render.yaml? No. Vercel does not read render.yaml, so Blueprint definitions need translating. A multi-service Blueprint maps to the services key in vercel.json, with top-level rewrites deciding which paths reach each service, and cron schedules are declared in vercel.json as well. Environment variables move into project settings. ### Does Render's health check path map to Vercel? No. Vercel's container image documentation defines no health-check path configuration. Validate each change on its preview deployment instead, before the change reaches production traffic. ## Related resources - Migrate to Vercel from [Fly.io](https://vercel.com/kb/guide/migrate-fly-io-to-vercel), [Railway](https://vercel.com/kb/guide/migrate-railway-to-vercel), or [Google Cloud Run](https://vercel.com/kb/guide/migrate-cloud-run-to-vercel) - [Does Vercel support Docker deployments?](https://vercel.com/kb/guide/does-vercel-support-docker-deployments) - [Run any Dockerfile on Vercel](https://vercel.com/blog/dockerfile-on-vercel) - [7 ways to use Docker containers on Vercel](https://vercel.com/i/7-ways-to-use-docker-containers-on-vercel) - [Render web services documentation](https://render.com/docs/web-services)