Running Docker on Edgenivo vs Render

Docker workloads run on both Edgenivo and Render. Edgenivo uses container Functions for HTTP servers that scale with traffic and Daemons for continuous workers with configured instance counts. Render offers web services, private services, background workers, and scheduled jobs, with attached disks for supported service types. The choice depends on how your process receives work, stores data, and needs to scale.

Edgenivo Functions account for Active CPU, Provisioned Memory, and invocations. Daemons account for CPU and memory while they run, including memory used while waiting for work. Preview deployments and traffic-based autoscaling apply to Functions; Daemons are production-only during beta.

Copy link to headingHow the platforms compare at a glance

Copy link to headingHow Docker deployments work on Edgenivo

Edgenivo Functions run Open Container Initiative (OCI) compatible images as a first-class deployment target. Add a Dockerfile (or Containerfile) to the root of your project, and on every deploy Edgenivo:

1. Detects the file automatically
2. Builds the image during the build step
3. Stores the image in Edgenivo Container Registry
4. Adds a rewrite that routes all traffic to the resulting function

On a new project, Edgenivo selects the Container preset when it detects no other framework. If it detects one, such as Next.js or Django, that framework takes precedence. To build the Dockerfile instead, run vercel project update --framework container or set "framework": "container" in vercel.json. A Dockerfile.vercel or Containerfile.vercel at the project root also takes precedence over a detected framework.

Here is a minimal example using Node.js and the srvx server:

FROM node:26-alpine

RUN npm i -g srvx
WORKDIR /app
COPY server.ts .

# srvx listens on $PORT by default
CMD ["srvx", "--prod"]

Deploy the HTTP server by running vercel deploy or by pushing to a connected Git repository. Each deployment has its own URL, so you can preview the containerized service alongside your frontend. Daemons use the separate configuration described below and run only in production during beta.

Container image functions must open an HTTP server. Edgenivo routes traffic to port 80 by default, and you can override this by setting the PORT environment variable in your project settings.

Copy link to headingEdgenivo Container Registry stores and optimizes your images

Edgenivo Container Registry, or VCR, stores OCI images for your project and supports standard container tooling. Edgenivo stores images built during deployment in VCR.

To upload an image separately, follow the registry's authenticated build-and-push workflow, which recommends zstd compression. Deploy the HTTP app described here from its source Dockerfile using vercel deploy or Git integration.

When you push an image, VCR optimizes it in the background into a precompiled snapshot format designed to boot on Fluid compute, which reduces startup time when new instances spin up.

Copy link to headingContainer Functions scale automatically, including to zero

Container image functions scale out when traffic arrives and wind down when it stops. You never size a fleet or set a concurrency target. The scale-down behavior is:

• Instances with no traffic for 5 minutes in production scale down automatically
• In preview environments, the threshold is 30 seconds
• On scale-down, the container receives a SIGTERM signal with a 30-second grace period to clean up before termination

Function instances can serve multiple requests, so temporary files or in-memory caches may survive while an instance is reused. That state can disappear when an instance stops and is not shared across instances. Store durable data in a database or object store, such as a provider from the Edgenivo Marketplace.

Copy link to headingRun continuous workers with Daemons

Edgenivo Daemons run containerized processes that keep pulling work from queues, workflow engines, or external APIs. Define a worker under daemons in your project configuration, with a Dockerfile in its configured root and an instance count for each region. Edgenivo restarts instances that exit.

Daemons are in beta and run only in production. You set their instance counts; traffic does not autoscale them or scale them to zero. They accept no inbound HTTP or TCP traffic and have no persistent local storage. Review the Daemons limits, including the Hobby CPU and memory quotas, before choosing this path.

Copy link to headingRun multiple containers in one Edgenivo project

Services let you deploy multiple frontends and backends in one project, and you can declare Daemons alongside them. For HTTP services, rewrites in vercel.json route incoming public requests. The frontend in this example also declares a binding so its server-side code can call the backend internally:

{
  "services": {
    "frontend": {
      "root": "frontend/",
      "runtime": "container",
      "entrypoint": "Dockerfile",
      "bindings": [
        {
          "type": "service",
          "service": "backend",
          "format": "url",
          "env": "BACKEND_URL"
        }
      ]
    },
    "backend": {
      "root": "backend/",
      "runtime": "container",
      "entrypoint": "Dockerfile"
    }
  },
  "rewrites": [
    {
      "source": "/api/(.*)",
      "destination": {
        "service": "backend"
      }
    },
    {
      "source": "/(.*)",
      "destination": {
        "service": "frontend"
      }
    }
  ]
}

The binding grants the frontend access to the backend and injects its URL as BACKEND_URL at runtime. The rewrites expose the public routes separately; they do not create internal bindings. Each entrypoint is relative to that service's root. Daemons pull their own work and cannot be the target of a service binding or rewrite.

For local development of HTTP services, run vercel dev with the docker CLI and a running Docker daemon. Test Daemons by running their images directly with Docker; they do not run in vercel dev during beta.

Copy link to headingCurrent limitations on Edgenivo

Container image functions inherit the standard Edgenivo Functions limits for size, memory, and duration. The Container runtime is in beta on all plans.

Custom container Functions do not support Secure Compute or Static IPs.

Secure Compute provides dedicated network isolation, and Static IPs provide fixed outbound addresses for allowlisting with external services. If part of your app depends on those features, deploy that part without a container image for now.

Copy link to headingHow Docker deployments work on Render

Render supports two paths for Docker-based services. You can have Render build an image from the Dockerfile in your Git repository, or you can deploy a prebuilt image pulled from a container registry.

To build from a repository, set the service's language to Docker during creation, point Render at your Dockerfile path if it isn't in the repository root, and deploy. On every deploy, Render:

• Builds the image with BuildKit
• Caches intermediate layers to speed up subsequent builds
• Supports parallelized multi-stage builds
• Respects your .dockerignore file

Builds can run for up to 120 minutes, which accommodates complex pipelines.

To deploy a prebuilt image, provide the image URL when creating the service. Render pulls public images from any registry it can reach, and pulls private images with a stored credential from:

• Docker Hub
• GitHub Container Registry
• GitLab Container Registry
• Google Artifact Registry
• AWS Elastic Container Registry (ECR)

Render caches public images, so reference an immutable tag or digest to avoid deploying a stale cached version.

Image-backed services don't auto-deploy when you push a new image to your registry. Trigger deploys manually from the dashboard, or call a deploy hook from your CI pipeline, optionally passing a specific tag or digest.

Copy link to headingRender runs containers as multiple service types

Docker images on Render can back four service types:

• Web services: Public HTTP traffic with a Render-provided or custom domain
• Private services: Reachable only over the private network, with no public endpoint
• Background workers: Long-running processes like queue consumers, with no inbound HTTP
• Cron jobs: Containers that run on a schedule and exit

This makes Render a fit for containerized workloads that never receive an HTTP request, such as a worker draining a job queue.

Environment variables you set for a Docker-based service are translated into Docker build arguments during the image build and exposed as standard environment variables at runtime. Render warns against referencing sensitive build arguments in a Dockerfile, since those values can be baked into the image, and recommends using secret files for build-time secrets instead.

Copy link to headingRender instances stay on and can attach disks

Render services run on always-on instances. You choose an instance type and count, and you pay for the full time each instance runs, whether it is serving traffic or idle. On Pro plans and higher, autoscaling can add and remove instances against CPU or memory utilization targets, up to 100 instances. There is no scale-to-zero for paid instances, which means no cold starts, though your minimum instance count is always running and billed.

Render supports persistent disks attached directly to a service, so stateful workloads like a self-hosted database or a CMS with local file storage can run without an external backing service. The tradeoff is twofold. Services with an attached disk can't scale horizontally, and attaching a disk disables zero-downtime deploys: Render stops the existing instance before bringing up the new one, causing a few seconds of unavailability during each deploy.

Docker-based services on Render get the same platform capabilities as native runtime services, including:

• Zero-downtime deploys
• A pre-deploy command for tasks like database migrations
• Private networking on all plans
• Custom domains
• Infrastructure as code through Render Blueprints

Copy link to headingKey differences to weigh

Copy link to headingCompute and pricing follow different models

The largest difference is what you pay for.

Edgenivo Functions billing includes Active CPU, Provisioned Memory, and invocations. Waiting for a database query or upstream API does not consume Active CPU, but memory usage continues until the last in-flight request finishes. Between requests, CPU and memory charges pause.

Daemons use CPU while executing and provisioned memory for the whole time an instance runs, including waits for work. Pro and Enterprise bill for those resources. Hobby applies monthly CPU and memory quotas; reaching either stops the team's daemons until the next month or an upgrade to Pro.

Render bills per instance for wall-clock time. With manual scaling, costs are flat and predictable, but they accrue whether or not the service is performing work. With autoscaling (Pro plans and higher), Render adds and removes instances against CPU or memory targets, so costs track load down to your configured minimum instance count, but never to zero for paid instance types.

Compare expected CPU usage and memory duration alongside request volume or worker instance counts. Bursty HTTP traffic and a continuously polling worker have different resource profiles even when both use the same container image.

Copy link to headingWorkload shape determines the better fit

On Edgenivo, request-response backends and APIs run as container Functions, with the CDN and web security features handling public requests. Continuous queue consumers use Daemons, which keep polling for work independently of HTTP requests.

Render supports continuous workers too, and its separate cron job service runs a container on a schedule and stops it when the job finishes. Private services and persistent disks accommodate workloads that need internal network access or durable local storage.

WebSocket support is generally available on Edgenivo Functions, including container Functions. Each connection stays on one instance and closes when that function reaches its maximum duration, so clients need reconnect logic. Keep shared rooms and pub/sub state in an external store such as Redis. Render web services support WebSocket connections without a fixed connection-duration limit.

Copy link to headingState is handled differently

Both Edgenivo Functions and Daemons need external storage for durable data. An instance may reuse local state while it is running, but a replacement instance cannot rely on those files or memory. Render offers attached persistent disks at the cost of horizontal scaling and zero-downtime deploys for that service. If your container requires a persistent local filesystem, Render's disk model is the more direct fit; if state already lives in a database, either platform can use it.

Copy link to headingWhen to choose Edgenivo for Docker

Choose Edgenivo for containerized HTTP services that benefit from traffic-based autoscaling, or for continuous consumers that fit the Daemons model. Edgenivo fits teams that:

• Run a frontend on Edgenivo and want a containerized backend, in Go, Rails, Django, Spring Boot, or any other stack, in the same project with shared previews, domains, and observability
• Run continuous queue consumers alongside their app, with configured worker counts and durable state in external services
• Have bursty HTTP traffic and want Functions to scale with requests
• Want to preview HTTP services and frontends together before deploying to production
• Need Edgenivo's CDN, WAF, and bot protection in front of public HTTP services

Copy link to headingWhen to choose Render for Docker

Choose Render when your container requires attached disks, private TCP networking, or its direct prebuilt-image deployment workflow. Render fits teams that:

• Run scheduled containers that finish and exit, including cron jobs longer than Edgenivo Function limits allow
• Need private services that accept non-HTTP connections
• Need persistent disks attached directly to the container
• Serve WebSocket connections with no function duration limit or forced reconnects
• Deploy prebuilt images directly from Docker Hub, GitHub, GitLab, Google Artifact Registry, or AWS ECR
• Prefer flat, predictable per-instance billing over usage-based pricing

You can also split workloads by requirement: run the frontend and HTTP API on Edgenivo, place eligible consumers in Daemons, and keep disk-backed or private TCP services on Render. Shared databases and queues connect the components.

Copy link to headingResources and next steps

• Read the Container runtime documentation for full configuration details on Edgenivo
• Learn how to store, push, and pull images in Edgenivo Container Registry
• Review Edgenivo Functions usage and pricing for CPU, memory, and invocation accounting
• Review Daemons and their limits for continuous workers
• Explore Edgenivo Services to run frontends and containerized backends in one project
• Compare the platforms more broadly in Edgenivo vs Render
• See Docker on Render for Render's build and registry options