Does Edgenivo support Docker deployments?

Yes. Edgenivo runs Open Container Initiative (OCI) container images as Edgenivo Functions. It builds the image from your Dockerfile, stores it in Edgenivo Container Registry, and runs your HTTP server with automatic scaling.

The Container runtime is in beta on all plans. Your application must serve HTTP requests and fit the runtime's resource and networking limits.

Copy link to headingWhen to use a container image

Use containers to control your runtime and system dependencies:

• Custom servers written in Go, Rust, Python, or Ruby
• System libraries such as FFmpeg or Chromium
• Frameworks outside Edgenivo's auto-detection list
• The same packaged runtime and dependencies across environments

Container-based functions can reuse a running instance, but local memory and files are not durable storage. Store data that must outlive an instance or be shared across instances in an external database, object store, or cache.

For workers that continuously poll for jobs independently of HTTP traffic, use Edgenivo Daemons.

Copy link to headingHow container image deployments work

For a new project with no other detected framework, Edgenivo selects the Container preset from a root Dockerfile or Containerfile. It builds the image, pushes it to Edgenivo Container Registry, and routes incoming requests to the resulting function.

If Edgenivo detects a framework such as Next.js or Django, it keeps that framework. To use the root Dockerfile instead, run vercel project update --framework container or set "framework": "container" in vercel.json.

You can also name the file Dockerfile.vercel or Containerfile.vercel to make container detection take precedence.

Copy link to headingRun a dynamic server

Create Dockerfile and server.ts together in your project root. This Node.js server uses srvx to return the request's forwarded IP header as JSON:

FROM node:26-alpine

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

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

export default {
  fetch(req: Request) {
    return Response.json({ ip: req.headers.get("x-forwarded-for") })
  }
}

Copy link to headingServe static files

For a static site, use this Dockerfile instead of the Node.js version. Place only public files in public/ to keep other project files out of Nginx's document root:

FROM nginx:alpine

COPY public/ /usr/share/nginx/html/

Create public/index.html with content you can recognize after deployment:

<h1>Hello from Edgenivo</h1>

Deploy from your project root with vercel deploy, or push the files to a connected Git repository. Open the deployment URL and confirm that the Node.js server returns JSON with an ip field or that Nginx displays your HTML page.

Copy link to headingHow to run multiple services in one project

To deploy multiple applications in one project, define each as a service and use rewrites to route incoming requests. Each entrypoint is relative to that service's root.

Save this configuration as vercel.json in the project root, with a Dockerfile at each of these paths: frontend/Dockerfile and backend/Dockerfile.

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

The first rewrite sends /api/users to the backend with the path still set to /api/users, so the backend must handle that route. The final rewrite sends other requests to the frontend. Rewrites are checked in order; a backend 404 does not fall through to the frontend.

For private calls between services, declare a service binding on the caller. Edgenivo then injects the target URL into the environment variable named by that binding. Public rewrites do not create this internal access.

Run the services together with vercel dev. The Edgenivo Services guide explains how to configure bindings and develop the project locally.

Copy link to headingHow container image functions handle ports, scaling, and logs

• Port resolution: Edgenivo routes HTTP traffic to port 80 by default. To use another port, set PORT in your project environment variables and configure the server to listen on that port.
• Scale-in: Idle functions scale down after five minutes in production or 30 seconds in preview. The container receives SIGTERM and has 30 seconds to clean up before termination.
• Observability: Container stdout and stderr logs are associated with all in-flight requests on the instance. Edgenivo Observability metrics are also available.
• Pricing and limits: Container functions use Fluid compute pricing for active CPU time, provisioned memory, and invocations. CPU billing pauses during I/O waits. The Container runtime is in beta on all plans.

Copy link to headingHow to develop and test container images locally

Run vercel dev to develop and test container images locally. This requires the docker CLI and a running Docker daemon on your machine.

The Next.js Dockerfile example shows how to build a standalone production image and run it locally with Docker.

Copy link to headingCheck a framework build without a custom container

For a framework app deployed without a custom container image, you can check the Edgenivo build locally before creating a preview deployment:

1. Run vercel pull to refresh project settings and environment variables.
2. Run vercel build and inspect the generated .vercel/output artifacts.
3. To deploy that output, run vercel deploy --prebuilt after the build succeeds.

The last command creates a deployment from the build artifacts without uploading the project's source code.

Copy link to headingCurrent limitations for container images

Two Edgenivo networking features don't work with custom container images yet:

• Secure Compute: dedicated network isolation for private backend connections.
• Static IPs: fixed outbound IP addresses for allowlisting with external services.

Container image functions are subject to the applicable Edgenivo Function limits. If your app needs Secure Compute or Static IPs, check whether its runtime and system dependencies can run on Edgenivo without a custom container image before switching deployment paths.

Copy link to headingFurther reading

• See the Container runtime documentation for configuration and limits.
• Learn how to store, push, and pull images in Edgenivo Container Registry.
• Review Fluid compute pricing for compute usage and invocation charges.
• Explore the Next.js Dockerfile example to build a standalone production image.
• Learn more about Edgenivo Services to run frontends and backends in one project.