The Anti-Container Manifesto
Containers solve environmental inconsistency. A self-contained application removes much of the environment they were built to package.
An environment around an application
In a container workflow, deployment begins by describing an environment as well as an application.
The image selects a base system, installs packages, copies artifacts, and defines startup behavior. Runtime and native-library choices become part of what the product has to stay compatible with. Exact inputs must be pinned if the result is to be repeatable.
The image then moves through a registry, a scanner, a runtime, and often an orchestrator. Each component provides useful control. Each introduces credentials, configuration, and failure modes.
All of this to deploy an application.
Why they exist
Software that works on a developer machine should also work in testing and production. Packaging user-space dependencies and configuration into an image removes many “works on my machine” failures. That is a genuine problem, and containers are a sound answer to it.
They earn their keep when the runtime, the libraries, and the directory layout are part of the application. Those inputs have to ship with it. A container packages them consistently.
A self-contained native artifact changes the problem. It still depends on a compatible operating system, plus explicit inputs such as data, credentials, and network access. There is just less environment to describe.
The costs of the extra layer are real: image construction copies an environment around the application; the base image carries packages with their own advisories; fleets add scheduling, networking, and cluster upgrades; a failure may come from application code, image contents, the runtime, resource limits, or a health check.
We copy a file
Compilation produces the deployment artifact directly. A file goes to a compatible host and runs under a small process manager.
That path does not need an image definition, a base image, a registry, a scanner, or an orchestration platform. The operating system and explicit runtime inputs remain the contract.
Reproducibility still takes work. Source inputs and the toolchain still need to be controlled. The advantage is a smaller set of inputs and a shorter path from build to process.
Use a container when workloads share a host, when teams need distinct security boundaries, or when the application truly requires a packaged user environment. Existing platforms may also make a container the best-supported deployment unit. Do not add a packaging layer after the application has already removed the problem it solves.
We copy a file. It runs.