Container Runtime

Edgenivo Functions can run any code and library using Open Container Initiative (OCI) container images, built from a Dockerfile or Containerfile in your project. Functions scale up and down automatically based on demand, and use Active CPU pricing. You are only billed for CPU when your code is actively running, not while waiting for I/O or sleeping.

To move an existing Docker app to Edgenivo, follow the migration guide for your current platform:

• Migrate from Railway to Edgenivo
• Migrate from Fly.io to Edgenivo
• Migrate from Render to Edgenivo
• Migrate from Google Cloud Run to Edgenivo
• Migrate self-hosted Next.js and containers from AWS to Edgenivo

A root Dockerfile or Containerfile is enough when Edgenivo detects no other framework. On a new project, Edgenivo selects the Container preset, builds that file, and routes all traffic to the image.

When the project already matches another framework, such as Next.js, Edgenivo keeps that framework. Set the project framework to Container to build the root file. --yes skips the confirmation prompt:

vercel project update --framework container --yes

A Dockerfile.vercel or Containerfile.vercel file selects the Container preset when that preset should win over another detected framework.

Create a Dockerfile at the project root:

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") })
  }
}

FROM nginx:alpine
 
COPY . /usr/share/nginx/html

<h1>Hello from Edgenivo Functions running a custom OCI image!</h1>

Deploy your application using the Edgenivo CLI or by pushing to a Git repository. During the build step, the image will be built and pushed to VCR.

You can also develop and test locally using vercel dev. This requires the docker CLI and Docker daemon to be available on your machine.

A single root Dockerfile deploys with the steps above. Use services to run multiple applications, backends, or frontends in the same Edgenivo project. Traffic is routed to the correct service with the rewrites configuration:

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

FROM nginx:alpine
...

FROM node:26-alpine
...

Set the entrypoint key to the path of your dockerfile, relative to the service's root, for each service that uses a custom container image. See services for more information on configuring services.

You can view runtime logs from the container's stdout and stderr streams. Because these logs are not tied to a specific request, they are broadcast to all inflight requests of the instance. Edgenivo Observability metrics are available like any regular Edgenivo Function.

Edgenivo Functions running container images are expected to open an HTTP server to receive traffic on. The default port is 80, and it can be overridden by setting the PORT environment variable in the project settings.

Functions not receiving any traffic for 5 minutes in production environments, and 30 seconds in preview environments, will automatically scale down.

When a function instance is scaled down, the container receives a SIGTERM signal with a 30 seconds grace period to clean up before being forcefully terminated. Learn more about the SIGTERM signal.

The same limits and Active CPU pricing model of Edgenivo Functions apply to custom container images.

Secure Compute and Static IPs are not yet supported with custom container images.

• Edgenivo Functions
• Edgenivo Container Registry
• Daemons for container images that run continuously without receiving traffic
• Container Images Demo template