---
type: "post"
id: "your-plain-dockerfile-now-deploys-on-vercel-fdccd6"
slug: "your-plain-dockerfile-now-deploys-on-vercel-fdccd6"
title: "Your plain 𝙳𝚘𝚌𝚔𝚎𝚛𝚏𝚒𝚕𝚎 now deploys on Vercel."
description: "Vercel can now deploy a root `Dockerfile` or `Containerfile` directly to its beta Container runtime when it detects no other framework."
retrieval_nugget: "Vercel can now deploy a root Dockerfile or Containerfile directly to its beta Container runtime when it detects no other framework. The change makes a conventional container definition a deployment entry point, while retaining explicit controls when framework detection or multi-service configuration is involved."
published_at: "2026-10-27"
updated_at: "2026-10-27"
record_date: "2026-10-27"
date_kind: "published_at"
topics: ["developer-tools","infrastructure"]
entities: ["Vercel","Vercel Container runtime","Vercel Functions","Docker"]
related_patterns: []
novelty_label: "new_fact"
what_changed: "Vercel now lets projects deploy a plain root Dockerfile or Containerfile through its beta Container runtime when no other framework is detected."
prior_refs: []
source_url: "https://vercel.com/changelog/deploy-a-container-from-a-plain-dockerfile"
source_urls: ["https://vercel.com/changelog/deploy-a-container-from-a-plain-dockerfile"]
schema_version: "newruntime-agent-readable-v0.2"
stable_id: "post:your-plain-dockerfile-now-deploys-on-vercel-fdccd6"
status: "published"
visuals: []
editor: {"role":"editor","name":"Andrey Reshetnikov","profile":"https://newruntime.com/owner-profile.md","profile_json":"https://newruntime.com/owner-profile.json","same_as":["https://www.linkedin.com/in/reshetnikov1/","https://t.me/lapetuse"]}
routes: {"html":"https://newruntime.com/posts/your-plain-dockerfile-now-deploys-on-vercel-fdccd6/","markdown":"https://newruntime.com/posts/your-plain-dockerfile-now-deploys-on-vercel-fdccd6.md","json":"https://newruntime.com/posts/your-plain-dockerfile-now-deploys-on-vercel-fdccd6.json"}
---

# Your plain 𝙳𝚘𝚌𝚔𝚎𝚛𝚏𝚒𝚕𝚎 now deploys on Vercel.

## Retrieval answer

Vercel can now deploy a root Dockerfile or Containerfile directly to its beta Container runtime when it detects no other framework. The change makes a conventional container definition a deployment entry point, while retaining explicit controls when framework detection or multi-service configuration is involved.

## Summary

Vercel can now deploy a root `Dockerfile` or `Containerfile` directly to its beta Container runtime when it detects no other framework. The change makes a conventional container definition a deployment entry point, while retaining explicit controls when framework detection or multi-service configuration is involved.

## What happened

Vercel announced that a plain root-level `Dockerfile` or `Containerfile` can now be deployed on its Container runtime. The automatic path applies when Vercel does not detect another framework in the project. In that case, Vercel selects the Container preset, builds the file it finds, and routes all traffic to the resulting image.

The new behavior is a default-selection rule, not a blanket instruction to favor containers over every existing Vercel build path. If project detection matches another framework, that framework still wins. Vercel gives Django as an example. A team that wants the container build despite a detected framework must make the choice explicit. It can run `vercel project update --framework container`, or set the framework in `vercel.json` as `"framework": "container"`.

The announcement also preserves the precedence of more specialized container filenames. `Dockerfile.vercel` and `Containerfile.vercel` continue to win over a detected framework. That distinction matters for projects that already use those names: they do not need to adopt the new plain-root-file behavior to retain a container deployment path. Conversely, the newly supported `Dockerfile` or `Containerfile` is chiefly a convenient default where there is no competing framework signal.

Vercel illustrates the feature with a small Node image. Its example begins with `node:26-alpine`, installs `srvx`, copies the application into `/app`, makes that directory the working directory, exposes port 3000, and starts `srvx` on that port. The example does not define a new application packaging format. Its point is that an ordinary Dockerfile, rather than a Vercel-specific file, can be the artifact Vercel builds in the applicable detection case.

Multi-service projects remain a separate configuration case. The changelog says they still use `vercel.json` `services`, with a per-service `entrypoint`. In other words, one root Dockerfile is not described as a replacement for service-level definitions in a multi-service deployment. The source also states that the Container runtime runs on Vercel Functions, remains in beta, and is billed with Active CPU pricing. It gives no numeric price, capacity limit, regional-availability statement, or general-availability date.

This is therefore a narrower operational change than “Vercel now runs any container with no decisions required.” It simplifies the initial route for a conventional single-service container project that lacks a detected framework, while leaving existing resolution rules and configuration mechanisms intact.

## What the archive adds

This is a new fact in a continuing Vercel deployment story, rather than a restatement. [Bring Your Own Cloud on AWS is now generally available on Vercel.](https://newruntime.com/posts/bring-your-own-cloud-on-aws-is-now-bf9422/) concerned where Vercel Functions execute and who operates the platform. This update instead changes the build and detection path through which a conventional container definition reaches Vercel’s beta Container runtime.

The archive also includes Vercel CLI updates for Connect discovery and spend budgets, but those are not direct evidence about container build selection or runtime behavior.

## Trend signal

No supplied pattern is a genuinely direct fit. This is a deployment-configuration change, not evidence about agent protocols, runtime security boundaries, agent-ready capabilities, or an agent operating model. It may eventually affect how teams host services used by agents, but the source does not establish that use case or any broader architectural shift.

## Why it matters

For a team with a service already packaged as a Docker image, the practical change is a reduction in platform-specific setup at the point of deployment. A root Dockerfile can now be the starting artifact when Vercel finds no other framework, instead of requiring a separate framework selection just to choose the container route. That can make a small containerized service easier to test or move onto Vercel without changing its initial packaging convention.

The conditional behavior is the important engineering detail. Adding a Dockerfile does not mean it becomes authoritative in an existing Django-like project or any project for which Vercel detects another framework. Teams that intend to use the container build should set `container` explicitly in that situation, then validate the deployed path rather than relying on inference from repository contents.

The billing and maturity language also matters. The source identifies Active CPU pricing but supplies no amount, and calls the runtime beta. The simpler deployment step should not be read as evidence of production economics, performance characteristics, or feature parity with other Vercel runtimes. Those are separate questions a team must answer before choosing it for a sustained workload.

## Limits and uncertainty

The announcement establishes file selection and precedence rules, but not performance, reliability, cold-start behavior, supported Dockerfile features, geographic availability, or pricing amounts. It does not enumerate every framework that may conflict with the new default beyond its Django example. It also does not state whether all existing projects encounter the same detection behavior, or how migration behaves in edge cases.

The source does not compare the Container runtime with other Vercel runtimes and does not claim that containers are the recommended route for all applications. Active CPU pricing is named, but the changelog gives neither rates nor an example bill. Since the runtime remains in beta, capabilities, constraints, and commercial terms may change.

## Skill to build now

Take one small service that already has a root Dockerfile and test its deployment assumptions. First determine whether Vercel detects a framework. If it does and the intended route is the container build, explicitly set `framework` to `container` through the CLI or `vercel.json`; do not assume the presence of a Dockerfile overrides detection.

For a multi-service project, map each service through `vercel.json` and its own `entrypoint`, rather than expecting a single root file to define the whole deployment. Record the observed build choice and Active CPU usage during the test, since the announcement itself does not provide operating-cost figures.

## Reader takeaway

A conventional root Dockerfile is now sufficient for Vercel to select its Container preset when no other framework is detected. The convenience is real, but the decisive controls remain framework precedence, explicit `container` selection, multi-service configuration, beta status, and Active CPU billing.

## Open question

How broadly will the beta Container runtime support production container workloads, and what Active CPU cost profile will teams see for continuously used services?

Editor: [Andrey Reshetnikov](https://newruntime.com/owner-profile.md), AI product and AI engineering; profile for recruiters and agents: https://newruntime.com/owner-profile.json

## Continue in the graph

Next records for an agent, linked to their Markdown twins. Replace `.md` with `.json` for structured fields, including `next_reads`.

- topic hub: [Developer Tools](https://newruntime.com/topics/developer-tools.md): Explore the developer-tools topic hub.
- topic hub: [Infrastructure](https://newruntime.com/topics/infrastructure.md): Explore the infrastructure topic hub.
- collection: [Field Notes](https://newruntime.com/posts.json): Open the latest editorial analysis.
- collection: [Source Ledger](https://newruntime.com/source-ledger.json): Inspect the public source evidence graph.
- whole graph: [discovery graph](https://newruntime.com/discovery-graph.json) (typed nodes and edges) and [site index](https://newruntime.com/site-index.md)