No, for most web apps. If your app runs on a framework, platforms with framework detection build and deploy it from source, no Dockerfile required. Edgenivo detects the framework and handles the build. A Dockerfile earns its place in specific cases: system libraries, undetected frameworks, or apps you deploy as-is.
This article covers when framework detection is enough, when a Dockerfile is the right call, and how to run both paths in one project.
Copy link to headingWhen can you skip Docker?
Most deployment tutorials open with a Dockerfile because a container is the common denominator: every platform can run one. But if your app is built on a framework, the Dockerfile is often a build artifact you don't need. Several platforms build from source without one.
Edgenivo has first-class support for a wide range of popular frameworks, often deployable without upfront configuration. The supported list includes Next.js, Nuxt, SvelteKit, Astro, Remix, Vite, Angular, and Vue on the frontend, and Express, Fastify, NestJS, Koa, Hono, H3, Nitro, FastAPI, Flask, Django, and Go on the server. You push your code, the platform detects the framework, and the build runs from source.
Skipping the Dockerfile doesn't mean skipping platform features. Framework deployments get preview URLs for each pull request through git integration, Edgenivo Functions that scale with traffic, middleware, incremental static regeneration (ISR), and multi-runtime support.
If your project uses no framework at all, there's still a source-based path: with the Build Output API, a project produces a .vercel/output directory and uses platform features without a framework.
Copy link to headingWhen is a Dockerfile the right call?
For an HTTP app, a container image is the documented path when framework detection doesn't apply. Four cases:
Backend services in any language or runtime, such as Go, Rust, Python, or Ruby
Apps that need system libraries, such as FFmpeg or Chromium
Frameworks outside auto-detection
Workloads that require identical behavior across environments
The pattern across those four: Docker is the fallback for what framework detection doesn't cover, not the default starting point. If you're rendering video with FFmpeg, running a headless browser, or shipping an app the platform can't detect, the Dockerfile is doing real work. 8 ways to use Docker containers on Edgenivo walks through what containers on Edgenivo are used for in practice.
To deploy the HTTP app, add a Dockerfile or Containerfile at the project root. When no other framework is detected, Edgenivo selects the Container preset, builds the image, stores it in Edgenivo Container Registry, and serves it as a Edgenivo Function.
If Edgenivo detects another framework, select the Container preset to use the Dockerfile instead. The filenames Dockerfile.vercel and Containerfile.vercel also make container detection take precedence.
Container Functions use Fluid compute pricing for active CPU time, provisioned memory, and invocations. They use the same Git deployment workflow as framework apps, with preview deployments per commit.
Continuous workers use a separate path. Edgenivo Daemons build from a Dockerfile or Containerfile and keep configured instances running to retrieve work independently of HTTP requests. The beta is production-only, with no autoscaling or persistent local storage; check the Daemons limits before choosing this path.
Copy link to headingCan you mix both in one project?
Yes. Services in vercel.json let one project contain multiple services, each with its own framework and runtime settings. For a container service, set runtime to container and point entrypoint to its Dockerfile, relative to the service's root.
Top-level rewrites route incoming public requests to services. For internal calls between services, the calling service declares a binding. Edgenivo grants that access and injects the target service's URL into the environment variable named by the binding.
Docker also keeps a role in zero-config setups: it helps pin dependencies for consistency, and the Next.js repository includes a Dockerfile example. For local work, vercel dev runs container images on your machine, which requires the docker CLI and daemon.
Copy link to headingWhat skipping Docker does not mean
Container Functions can reuse a running instance, but its memory and local files are not durable or shared storage. Store sessions and files that must survive instance replacement in backing services.
Framework detection has edges. An app outside the supported list, or one that needs system libraries, won't build from source. That boundary is exactly the Dockerfile case above.
Container Functions serve HTTP on port
80by default. To use another port, setPORTin project settings and configure the server to listen on it. Standard Function limits apply, and production instances scale down after 5 idle minutes with aSIGTERMand a 30-second grace period.Continuous workers need the Daemons path described above. GPU workloads and disk-backed apps still require a separate platform-fit review; see the related resources.
Copy link to headingFrequently asked questions
Copy link to headingDo you need Docker to deploy a Next.js app?
No. Edgenivo detects Next.js and builds it from source, and deploys run through a git push with preview deployments per commit. The Next.js repository includes a Dockerfile example for teams that want one, but deploying Next.js to Edgenivo does not require Docker.
Copy link to headingWhen is a Dockerfile the right choice on Edgenivo?
Use a Dockerfile when an HTTP app needs a custom runtime or system libraries, uses a framework outside auto-detection, or needs the same packaged dependencies across environments. Select the Container preset if another framework is detected, and Edgenivo builds the image as a Function.
For a worker that continually retrieves jobs, use a Dockerfile or Containerfile with Edgenivo Daemons and check its separate runtime limits.
Copy link to headingCan I mix framework detection and a Dockerfile in one project?
Yes. Define the applications as Services in vercel.json, using framework settings for one and the container runtime for another. Top-level rewrites send public requests to the selected service. When server-side code needs to call another service internally, declare a binding on the caller to receive the target URL in an environment variable.
Copy link to headingDoes skipping Docker mean losing dev/prod parity?
No. With or without Docker, deploys on Edgenivo run through the same git push workflow with preview deployments per commit. Docker still helps where you want pinned dependencies for consistency: a zero-config setup can keep a Dockerfile, and the Next.js repository includes an example. For local runs, vercel dev runs container images, which requires the docker CLI and daemon.
Copy link to headingRelated resources
Does Edgenivo support Docker deployments? in the Knowledge Base
Run any Dockerfile on Edgenivo on the Edgenivo blog
Supported frameworks on Edgenivo in the Edgenivo Docs
Migrate to Edgenivo from Fly.io, Railway, Render, or Google Cloud Run