Container

One of the oldest arguments among developers starts with "it works on my machine." Something that ran fine on the laptop it was written on refuses to start on the server. The code is identical; the result isn't.

The cause was almost always outside the code. The laptop has language version 3.11 and the server has 3.9. An image-processing library was installed on the laptop years ago and never installed on the server. With several servers the differences multiply: server 1 was set up two years ago, server 5 last month, their configurations drift apart in small ways, and nobody wrote the drift down. Deploy the same program to five machines, watch it fail on exactly one, and the day is gone finding out why that one machine is different.

The answer before containers was to document the installation steps. Documents go stale fast. Someone in a hurry changes one setting by hand and doesn't record it, the document and the server part ways from that moment, and the next person follows the instructions exactly and still gets nothing. Containers came from flipping the approach: instead of writing down how to install, package the finished result and move the package. Nobody explains what to install — the installed state itself becomes one unit and that unit travels.

Three things follow from the single property that the bundle's contents are fixed.

1. Environment drift — the program, the language runtime, the libraries, and the config files all sit inside one unit. The only thing borrowed from outside is the core of the operating system. A unit that started on a laptop starts the same way on a server. An environment is one of the separate spaces a team keeps for development, staging, and production, and putting the identical unit in all three cuts down the class of problem that begins "but it worked in staging."
2. Deploy time — shipping a new version stops being a matter of copying files and running a chain of install commands and becomes pulling a unit and swapping it in. What took minutes takes seconds, and reverting to the previous unit when something breaks takes the same few seconds. Part of why CI/CD — the setup that automatically checks a code change and carries it through to release — spread so widely is that this unit was easy to move.
3. Density on one machine — with no full operating system to boot, startup takes seconds and memory use stays close to what the program itself needs, so dozens of units fit on a single server. Microservices, the structure that splits a system into separately deployed pieces, became practical largely because each small piece no longer needed a machine of its own.

Not every program needs to run this way. Three other options stay in regular use.

1. Installing straight onto the server — put what's needed on one machine by hand and start the program. There's no layer in between, which makes it the simplest option, and for a team with one or two servers deploying once a month it's genuinely faster. The steps live in a setup document, which is where the drift described above comes from. Building a unit, pushing it to a registry, and pulling it back down is itself a process to maintain.
2. Virtual machine — an independent computer carved out of a physical server. Each one carries a full operating system, so the isolation is harder. If separation between customers has been promised contractually, or a program needs a different operating system entirely, this is the fit. The cost is a minute or two to start and a large block of memory claimed up front.
3. Serverless — running code as individual functions without managing servers at all. A function wakes on request, runs, and disappears, which suits jobs that fire a few times a day. It brings a cold start, the delay when an idle runtime has to wake up, and it caps how long one execution can run and how much memory it can use.

The deciding factors are deploy frequency and server count. Adding this layer to a two-server service that ships monthly leaves you managing more than you gained. Past weekly releases and ten machines, the balance reverses.

"It runs locally but not in staging. Let me rebuild the image and push it again."

Rebuilding the bundle so the difference between the two environments disappears.

"Let's run this in a container and keep the database outside it."

A decision to keep anything that has to retain state out of this format.

"We get eight per machine. Past that, memory runs out."

Reporting a measured limit for how many fit on one server.

This came up at Pagedeck the quarter Theo built document previews. The preview feature uses a library that turns documents into images, and that library reaches for whatever fonts the operating system happens to have. Documents rendered correctly on Theo's laptop and came back as rows of empty boxes from the production server, because the font it picked existed on one machine and not the other.

Bundling the font files into the unit made the difference disappear. Writing the font installation into a setup document would also have worked, but Theo chose the unit because whoever built a new server six months later clearly wasn't going to read that document.

The most common reading is that a container is a lightweight virtual machine. Both appear to run a program off on its own, so the comparison is natural. But this format shares the core of the operating system with everything else on the machine. It isn't a separate computer so much as a partitioned view inside one operating system. Miss that and you assume stronger isolation than you have, and you leave out of the design the possibility that trouble in one unit reaches another on the same host.

The other expectation is that adopting this alone solves operations. Starting one unit gets easy; several hundred units raise a new question of which machine holds how many and where a dead one should come back. Something else makes that call, and choosing and running it is a separate piece of work. Scaling up without knowing this means people start and stop units by hand, which lands the team back where it was when procedures lived in a document.