Migrate from Render to Edgenivo

To migrate from Render to Edgenivo, move data off persistent disks and deploy HTTP services through framework detection or a Dockerfile. Set the port and environment variables, then recreate cron jobs and service connections. Continuous workers can use Edgenivo Daemons, subject to the Public Beta limits described below.

Copy link to headingShould 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 Edgenivo destination:

1. Does it serve HTTP requests or consume work? Edgenivo 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 Edgenivo vs Render compares them directly.

Copy link to headingHow do Render concepts map to Edgenivo?

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. The Container runtime is in beta on all plans.

Copy link to headingMigration steps

Copy link to heading1. 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.

Copy link to heading2. Move data off persistent disks

Edgenivo 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 Edgenivo 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 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.

Copy link to heading3. 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. Edgenivo deploys a long list of 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 Edgenivo doesn't detect, system libraries such as FFmpeg or Chromium, or a Docker-based build you also use in other environments.

Copy link to headingMigrating a Python API

FastAPI, Flask, and Django APIs can use Edgenivo's native Python runtime when their Python version and dependencies are supported. Edgenivo 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 Edgenivo for Python version pins, dependency configuration, entrypoints, and database checks. The Dockerfile setup and listening-port instructions below apply to HTTP container deployments.

Copy link to heading4. Configure container images for HTTP services and workers

For an HTTP service, place a Dockerfile or Containerfile at the root of the project. When Edgenivo detects no other framework, it selects the Container preset automatically and routes all traffic to the container Function. During the build, Edgenivo builds the image and pushes it to Edgenivo Container Registry. If project detection matches another framework, such as Django or Next.js, Edgenivo deploys that framework instead. To build the Dockerfile, run vercel project update --framework container, set "framework": "container" in vercel.json, or name the file Dockerfile.vercel or Containerfile.vercel, which takes precedence over a detected framework. If your Render service deploys from a prebuilt image, start from the Dockerfile that produces that image.

Copy link to headingMigrating continuous workers

Railway services that continuously consume jobs can move to Edgenivo Daemons while retaining their queue library. Package the worker in a Docker image and replace private Railway service addresses with broker and database endpoints reachable from Edgenivo.

Follow Migrate Railway workers to Edgenivo Daemons for a BullMQ migration that begins with zero daemon instances. Test shutdown and retry behavior before shifting capacity from Railway, with both worker groups connected to the same broker during the handoff.

Copy link to heading5. 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 Edgenivo 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 Edgenivo'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, with separate values for testing and production.

Review connection strings before copying them. If you keep a Render Postgres database, your Edgenivo application needs its external connection URL, 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.

Copy link to heading6. Recreate cron jobs and multi-service wiring

Render cron job services become Edgenivo cron jobs declared in vercel.json. Edgenivo 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 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 Edgenivo 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 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:

{
  "services": {
    "web": {
      "root": "web/"
    },
    "api": {
      "root": "api/",
      "runtime": "container",
      "entrypoint": "Dockerfile"
    }
  },
  "rewrites": [
    { "source": "/api/(.*)", "destination": { "service": "api" } },
    { "source": "/(.*)", "destination": { "service": "web" } }
  ]
}

For private HTTP calls, declare a binding on the calling service. Edgenivo 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 Edgenivo's Go or Rust runtime, build it as a container image to use bindings.

Copy link to heading7. 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, 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 Edgenivo 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. 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 using the DNS values Edgenivo provides. Drain and stop the Render workers before raising the Daemon instance counts, and disable Render's schedules before enabling their Edgenivo replacements. Verify production requests and job results before retiring the Render services.

Copy link to headingWhat doesn't map from Render

Persistent disks have no equivalent on Edgenivo. Before migrating, move their data to a managed database, cache, or blob store from the Edgenivo Marketplace.

Worker operating requirements. Daemons provide a path for continuous workers, but the Public Beta 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 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 Edgenivo 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.

Edgenivo 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 setting, which defaults to 30 seconds and accepts values from 0 to 3600.

Copy link to headingFrequently asked questions

Copy link to headingDo I need to change my Dockerfile to move from Render to Edgenivo?

For an HTTP service that fits Edgenivo Functions, you can start by placing the existing Dockerfile at the project root without renaming it. Workers use the Dockerfile named in their daemon configuration.

Check the HTTP port separately. Render defaults PORT to 10000; Edgenivo 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.

Copy link to headingWhat 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, 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.

Copy link to headingCan I move my Render background workers to Edgenivo?

Yes, continuous workers such as queue consumers can run as Edgenivo 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.

Copy link to headingCan I keep using render.yaml?

No. Edgenivo 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.

Copy link to headingDoes Render's health check path map to Edgenivo?

Render's healthCheckPath does not map to an option in the published Edgenivo 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.

Copy link to headingRelated resources

• Migrate to Edgenivo from Fly.io, Railway, or Google Cloud Run
• Does Edgenivo support Docker deployments?
• Run any Dockerfile on Edgenivo
• 7 ways to use Docker containers on Edgenivo
• Render web services documentation