--- 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: "https://vercel.com/kb/guide/migrate-render-to-vercel" published: 2026-08-11 last_updated: 2026-10-22 authors: Ben Sabic related_resources: - title: "Migrate a Python API from Render to Vercel" url: "https://vercel.com/kb/guide/migrate-a-python-api-from-render-to-vercel" description: "Move a FastAPI, Flask, or Django API from Render to Vercel Functions. Translate render.yaml and replace persistent disks, background workers, and cron jobs." - title: "Running Docker on Vercel" url: "https://vercel.com/kb/guide/docker" description: "Learn how to run Docker on Vercel by deploying OCI container images as Vercel Functions, storing them in Vercel Container Registry (VCR), and running containers in Vercel Sandbox." - title: "The Complete Guide to Vercel Services" url: "https://vercel.com/kb/guide/vercel-services" description: "Vercel Services let you deploy multiple frontends and backends in one project on a shared domain. Learn how to define services in vercel.json, route requests by path prefix, and connect services with generated environment variables." install_vercel_plugin: npx plugins add vercel/vercel-plugin --- To migrate from Render to Vercel, move data off persistent disks and deploy HTTP services through framework detection or a [Dockerfile.vercel](https://vercel.com/docs/functions/container-images). Set the port and environment variables, then recreate cron jobs and service connections. Continuous workers can use [Vercel Daemons](https://vercel.com/docs/daemons), subject to the Public Beta limits described below. ## Should your app move? Render builds services from native language runtimes, from Dockerfiles, and from prebuilt Docker images. Check how each workload handles requests, stores data, and shuts down before choosing its Vercel destination: 1. Does it serve HTTP requests or consume work? Vercel Functions running container images need an HTTP server. Continuous queue consumers can use Daemons. 2. Does it write to an attached disk? Move persistent data to a managed database, cache, or blob store before moving the service. 3. Can it stop within the destination's shutdown grace period? Container Functions allow 30 seconds after `SIGTERM`. Daemons default to 30 seconds and allow a configurable grace period. Render's default is also 30 seconds, with a configurable maximum of 300 seconds for services without persistent disks. Check the remaining runtime limits in "What doesn't map from Render" before proceeding. If you're still weighing the platforms, [Running Docker on Vercel vs Render](https://vercel.com/kb/guide/docker-on-vercel-vs-render) compares them directly. ## 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 | For an HTTP service, a service under `services` in `vercel.json`, with a caller-side binding for internal access | | Cron job | A cron job in `vercel.json`, triggered by an HTTP GET to your chosen path | | Background worker | [Vercel Daemons](https://vercel.com/docs/daemons) for continuous workers, subject to Public Beta limits | | Persistent disk | No equivalent; move data to a managed database, cache, or blob store first | | Environment variables | Environment variables in project settings; use Secret variables for credentials | | `PORT` (defaults to 10000) | Traffic goes to port 80 unless you set `PORT` in project settings | | Blueprints (`render.yaml`) | `services` and `rewrites` for HTTP services, `daemons` for workers, and `crons` for schedules in `vercel.json`; storage needs a separate plan | | Pre-deploy command | A CI release task that must succeed before production promotion | | Health check path | No matching `healthCheckPath` option in the container Function configuration; test the endpoint before cutover | HTTP container Functions run 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 web service, private service, background worker, and cron job. For each one, record whether it uses a native runtime, Dockerfile, or prebuilt image, plus any attached disk, health check path, pre-deploy command, and `PORT` override. Include database and queue dependencies and note private-network connections. Choose an HTTP deployment, Daemon, or scheduled handler for each workload. Check disk storage and network access before moving it, and compare its requirements with the limits 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. Update the application to use its new storage before moving the service. Export database contents with the database's backup tools and copy ordinary files separately. Render's [disk transfer and backup guidance](https://render.com/docs/disks) distinguishes these cases. Plan how to capture writes made during the move, or pause writes for the final copy. Verify the transferred data before switching the application, and retain the source until you have checked the new deployment. ### 3\. Check framework detection before writing any config If your Render HTTP 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. Use a container when your backend needs a language or runtime Vercel doesn't detect, system libraries such as FFmpeg or Chromium, or a Docker-based build you also use in other environments. #### Migrating a Python API FastAPI, Flask, and Django APIs can use [Vercel's native Python runtime](https://vercel.com/docs/functions/runtimes/python) when their Python version and dependencies are supported. Vercel installs the declared packages and loads the application's entrypoint, so you don't carry over Render's server Start Command or set `PORT` for this path. Follow [Migrate a Python API from Render to Vercel](https://vercel.com/kb/guide/migrate-a-python-api-from-render-to-vercel) for Python version pins, dependency configuration, entrypoints, and database checks. The Dockerfile setup and listening-port instructions below apply to HTTP container deployments. ### 4\. Configure container images for HTTP services and workers For an HTTP service, 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 traffic to the container Function. During the build, Vercel builds the image and pushes it to Vercel Container Registry. If your Render service deploys from a prebuilt image, start from the Dockerfile that produces that image. For a continuous worker, add a [daemon configuration](https://vercel.com/docs/daemons/config-reference) under `daemons` in `vercel.json`. Set `root` to the worker's source directory, `entrypoint` to its Dockerfile path relative to that directory, and `instances` to the required count in each region. Set the startup command in the image or the daemon's `command` field. ### 5\. Set the port and environment variables On Render, your web server binds to `0.0.0.0`, and the `PORT` environment variable defaults to `10000`. For a Vercel container Function serving HTTP, traffic goes to port `80` unless you set `PORT` in project settings. If your server already reads `PORT` from its environment, set the project variable to the port it should listen on. Configure Vercel's routing port in project settings rather than relying on an `ENV PORT` instruction in the Dockerfile. Daemons consume work without an inbound HTTP port. Recreate the remaining Render environment variables in project settings and choose their target environments. Store credentials as [Secret variables](https://vercel.com/docs/environment-variables/sensitive-environment-variables), with separate values for testing and production. Review connection strings before copying them. If you keep a Render Postgres database, your Vercel application needs its [external connection URL](https://render.com/docs/postgresql-creating-connecting), TLS, and permitted external access. Render's internal database URL is for services on its private network. Check the container networking restrictions below before relying on an IP allowlist. ### 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 sends 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 schedules use UTC. Protect the handler with [`CRON_SECRET`](https://vercel.com/docs/cron-jobs/manage-cron-jobs) and reject requests unless their `Authorization` header matches `Bearer`, one space, and the secret's value. The user agent alone does not authenticate a request. Check the schedule syntax and Function duration limits before moving each job. Render permits only one active run of a cron job, while Vercel jobs can overlap. Use a lock where serialization is required, and make repeated invocations safe. For the HTTP services in a Render Blueprint, declare [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 exposes one to the internet. For container services, set `runtime` to `container` and `entrypoint` to the Dockerfile path relative to that root: ```json { "services": { "web": { "root": "web/" }, "api": { "root": "api/", "runtime": "container", "entrypoint": "Dockerfile.vercel" } }, "rewrites": [ { "source": "/api/(.*)", "destination": { "service": "api" } }, { "source": "/(.*)", "destination": { "service": "web" } } ] } ``` For private HTTP calls, declare a [binding on the calling service](https://vercel.com/docs/services/bindings). Vercel injects the target service's URL into the named environment variable and grants the caller access without adding a public route. Render private services can use other protocols, so confirm that the service you're moving exposes an HTTP interface. If a calling service uses Vercel's Go or Rust runtime, build it as a container image to use bindings. ### 7\. Test the migration before cutover Run `vercel dev` to test HTTP services together locally. Container services require the `docker` CLI and a running Docker daemon. Test Daemon images separately with Docker, because Daemons do not run in `vercel dev` or preview deployments. Before the project's [first deployment](https://vercel.com/docs/deployments/environments), configure test credentials in the Production environment, which that first deployment always uses. Set every Daemon instance count to `0` until you are ready to transfer worker ownership, and keep Vercel cron jobs disabled during testing. Leave your existing domain on Render. After that first deployment, commits to a non-production branch normally create previews. On the generated URL, check the port wiring, service routes, and database access. Invoke the protected cron handler manually to test its behavior; the schedule runs only in production. Move Render pre-deploy tasks into CI and require them to pass before [promoting the production deployment](https://vercel.com/docs/cli/deploying-from-cli). When ready for the final HTTP check, replace the test credentials with production values. Stage it with `vercel --prod --skip-domain` to use those values without assigning production domains. When the checks pass, promote the deployment and [configure your custom domain](https://vercel.com/docs/domains/working-with-domains/add-a-domain) using the DNS values Vercel provides. Drain and stop the Render workers before raising the Daemon instance counts, and disable Render's schedules before enabling their Vercel replacements. Verify production requests and job results before retiring the Render services. ## What doesn't map from Render Persistent disks have no equivalent on Vercel. Before migrating, move their data to a managed database, cache, or blob store from the Vercel Marketplace. Worker operating requirements. Daemons provide a path for continuous workers, but the [Public Beta limits](https://vercel.com/docs/daemons/limits) can affect the move. You must set instance counts, and there is no autoscaling or preview execution. Daemons also cannot receive inbound traffic, use persistent local storage, or serve as binding targets. Keep a worker on Render if those constraints prevent the migration. The pre-deploy command. Move Render's release tasks into CI and make successful completion a condition of production promotion. Use a [staged production deployment](https://vercel.com/docs/cli/deploying-from-cli) when you need to finish those tasks before assigning production domains. Keep database changes compatible with the Render version that remains live during the cutover. The health check path. Render's `healthCheckPath` is not an option in the published container Function configuration. Test the HTTP endpoint on the generated deployment URL before assigning production domains. These deployment tests do not recreate Render's ongoing runtime health checks. Secure Compute and Static IPs. Neither is supported for Functions running custom container images, and the standard Vercel Functions limits apply. If your Render service reaches a database through an IP allowlist, resolve that connection requirement before moving. Configurable shutdown. During a Render deployment, the old instance receives `SIGTERM` 60 seconds after traffic switches. Its shutdown delay defaults to 30 seconds and can be extended to 300 with `maxShutdownDelaySeconds`, except on services with persistent disks. Vercel container Functions scale down after 5 minutes without production traffic or 30 seconds without preview traffic. They receive `SIGTERM` and have a fixed 30-second cleanup period. Daemons have a separate [`terminationGracePeriodSeconds`](https://vercel.com/docs/daemons/config-reference) setting, which defaults to 30 seconds and accepts values from 0 to 3600. ## Frequently asked questions ### Do I need to change my Dockerfile to move from Render to Vercel? For an HTTP service that fits Vercel Functions, you can start by copying or renaming the file to `Dockerfile.vercel` or `Containerfile.vercel`. Workers use the Dockerfile named in their daemon configuration. Check the HTTP port separately. Render defaults `PORT` to `10000`; Vercel routes container Function traffic to `80` unless you set `PORT` in project settings. If your server reads that variable, you can keep its port-selection code. Use project settings for the routing port, even if the Dockerfile also defines `ENV PORT`. ### What replaces Render's pre-deploy command? Run the release task in CI and make production promotion depend on its success. With a [staged production deployment](https://vercel.com/docs/cli/deploying-from-cli), you can complete migrations and checks before assigning production domains. Render runs pre-deploy commands on a separate instance, but your CI runner still needs the task's dependencies, credentials, and network access. ### Can I move my Render background workers to Vercel? Yes, continuous workers such as queue consumers can run as [Vercel Daemons](https://vercel.com/docs/daemons). Package the worker in a container image and declare its source directory, Dockerfile, and instance counts under `daemons` in `vercel.json`. During the Public Beta, Daemons run only in production and do not autoscale, so check those limits before moving the worker. ### Can I keep using render.yaml? No. Vercel does not read `render.yaml`, so translate each Blueprint resource into the appropriate configuration. In `vercel.json`, use `services` with top-level rewrites for HTTP services, `daemons` for continuous workers, and `crons` for schedules. Move environment variables into project settings and plan storage separately. ### Does Render's health check path map to Vercel? Render's `healthCheckPath` does not map to an option in the published Vercel container Function configuration. Test your HTTP endpoint on the deployment's generated URL and require those checks to pass before production promotion. These release checks do not reproduce Render's ongoing runtime health checks. ## 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) ## Related Resources - [Migrate a Python API from Render to Vercel](https://vercel.com/kb/guide/migrate-a-python-api-from-render-to-vercel): Move a FastAPI, Flask, or Django API from Render to Vercel Functions. Translate render.yaml and replace persistent disks, background workers, and cron jobs. - [Running Docker on Vercel](https://vercel.com/kb/guide/docker): Learn how to run Docker on Vercel by deploying OCI container images as Vercel Functions, storing them in Vercel Container Registry (VCR), and running containers in Vercel Sandbox. - [The Complete Guide to Vercel Services](https://vercel.com/kb/guide/vercel-services): Vercel Services let you deploy multiple frontends and backends in one project on a shared domain. Learn how to define services in vercel.json, route requests by path prefix, and connect services with generated environment variables. ## More Vercel Services guides - [How to migrate from Google Cloud Run to Vercel](/kb/guide/migrate-cloud-run-to-vercel): Move a Cloud Run service or worker to Vercel. Compare runtimes, preserve Google Cloud access, and plan jobs, validation, and production cutover. - [How to use Vercel Container Registry](/kb/guide/how-to-use-vercel-container-registry): Push, store, and pull OCI container images with Vercel Container Registry, then deploy them to Vercel Functions and Vercel Sandbox. - [How to migrate from Fly.io to Vercel](/kb/guide/migrate-fly-io-to-vercel): Move an app from Fly.io to Vercel. Map configuration, choose Functions or Daemons, plan persistent storage, and verify the production cutover.