Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.vers.sh/llms.txt

Use this file to discover all available pages before exploring further.

Here is a frame for thinking about infrastructure that, once you have it, is hard to put down: every durable primitive you can name was someone’s answer to a cost being paid over and over. The primitive didn’t make the work faster. It made some recurring cost go away, or made it payable once instead of many times, and the savings were large enough that nobody wanted to go back. This frame is useful for two reasons. It explains why certain primitives stuck and others didn’t. And it predicts, roughly, where the next ones are coming from — because it tells you what to look for.

​
The pattern

Pick any primitive that became part of the standard infrastructure toolkit. Ask: what cost was being paid before this primitive existed? The answer is always concrete, always something programmers were doing by hand, and always something the primitive made go away or made marginal. Indexes. Before indexes, every query against a table scanned the table. The cost was linear in the table size, paid per query. An index pays a bounded cost at write time to amortize scans at read time. The recurring cost — the scan — goes away. What’s left is a small, predictable lookup. Caches. Before caches, every derived value was recomputed each time it was needed. The cost was in the recomputation, paid per read. A cache pays a one-time cost to store the result and makes every subsequent read cheap. The primitive didn’t make the computation faster; it made the repeated computation go away. CDNs. Before CDNs, every request for a static asset made a round trip to the origin server. The cost was in the latency and bandwidth of that round trip, paid per request. A CDN pays a one-time replication cost and turns every subsequent request into a short local hop. The work didn’t get faster; the recurring cost of doing it far away got paid once, per edge location, forever. Virtual memory. Before virtual memory, programs had to manage physical RAM directly, paging things in and out with explicit system calls. The cost was in the programmer’s time to reason about memory locations and in the bugs that arose when they got it wrong. Virtual memory pays a modest per-access tax (a TLB lookup) and in exchange makes the entire class of “manage your own physical memory” work go away. Garbage collection. Before GC, every program had to track every allocation and free it by hand. The cost was in programmer attention and in the bugs that arose from forgetting. GC pays runtime overhead and sporadic pause time to make the tracking go away. Connection pools. Before connection pools, every database query opened a new TCP connection and negotiated a new TLS handshake. The cost was tens of milliseconds of handshake per query, paid per query. A pool pays a one-time handshake cost and reuses the connection. Queries went from “network round-trip plus handshake plus result” to “result,” and databases suddenly seemed dramatically faster. Package managers. Before package managers, every programmer installing a dependency had to find the source, download it, build it, resolve its transitive dependencies by reading its README. The cost was in each installation, paid per dependency per project. A package manager pays a one-time cost to index the world’s code and turns installation into a single command. DNS. Before DNS, every networked program had to know the IP addresses of the machines it talked to. The cost was in human memory and in the changes needed every time an address changed. DNS pays a small query tax per lookup to make the human-readable name work, and the cost of maintaining a mental map of IP addresses goes away. JIT compilation. Before JIT, interpreted languages paid the cost of interpretation on every instruction. JIT pays a compile-time cost (both in wall-time and in memory) to amortize the per-instruction cost of interpretation. The work the CPU does isn’t faster; the number of times you do that work per program execution drops by orders of magnitude. fork(). Before fork(), creating a new process meant specifying a program and getting a fresh process built around it. The cost was in re-establishing all the state the new process wanted — file descriptors, environment, memory. fork() makes the new process start with all the state the parent had, paying a (with copy-on-write, near-zero) duplication cost in exchange for the entire class of “set up the child’s context from scratch” work going away. git. Before git, collaboration meant mailing patches, dealing with merge tooling that lost history, working in lockstep with centralized servers. The cost was in coordination, paid per contribution. Git pays a per-object content-addressing cost and in exchange makes offline work, untrusted replication, and cheap branching all free. The actual code didn’t get better; the cost of working on it with other people collapsed. Container images. Before container images, dev/prod drift was endless and every new deployment re-derived the environment from a mix of scripts, configuration management, and apology emails. Container images pay a build-time cost and turn “recreate this environment” into “pull and run this hash.” The deployment isn’t faster; the reconstruction is amortized. Kubernetes. Before orchestration, running a service at scale meant hand-rolled scripts to schedule containers across nodes, detect failures, restart crashed workers, balance load. The cost was in operational labor, paid continuously. Orchestrators pay with configuration complexity and a control-plane overhead to make the per-deployment labor go away. Pick any of them. Ask what cost they eliminated. The story is always the same shape: a recurring cost you were paying turned into a one-time cost you pay at a different moment, and the difference is the savings compounded over every use of the primitive forever.

​
Why this frame is useful

The frame is useful in two directions. Looking backward, it explains why certain primitives stuck and others didn’t. Primitives that successfully eliminated recurring costs became indispensable; primitives that just made existing work slightly more convenient faded. The infrastructure graveyard is full of ideas that were clever but didn’t make a cost go away. The winners all have the same shape. Looking forward, it predicts where the next primitive is likely to come from. The recipe is:
  1. Identify a cost being paid over and over in the current era of infrastructure.
  2. Check whether someone has named it yet — if the cost is unnamed, it’s easier to not see.
  3. Ask what it would take to pay that cost once instead of every time.
  4. That answer, made cheap enough to be a hot-path primitive, is the next thing.
Most proposed infrastructure primitives fail this test. They add a tool without making a cost go away. They make the same work possible through a different syntax, or provide a marginally more ergonomic interface. Those tools exist for years, have a loyal user base, and never go mainstream, because mainstream adoption requires killing a cost most people didn’t realize they were paying. The primitives that do succeed often feel, in hindsight, obvious. Of course you should index a table you query repeatedly. Of course you should cache a computation you do many times. Of course you should reuse connections. Each of these was a research paper and then a decade of adoption. The obviousness is retrospective. What was really happening was that a cost had grown large enough that someone got fed up, built the workaround, and discovered the workaround was general.

​
The tell

One tell of an about-to-emerge primitive: you can find developers who have built custom, fragile, per-project workarounds for the same cost.
  • Before package managers: every project had a ./install.sh that downloaded the world.
  • Before CI/CD: every team had a developer who was the “build person.”
  • Before container images: every company had a runbook for re-provisioning servers.
  • Before version control: every programmer had a code-backup-2004-11-13/ directory.
The per-project workaround is the sign that a real primitive is needed. The workaround is always janky, always slightly different per-project, always costing more to maintain than anyone admits. At some point someone consolidates the workarounds into a general primitive, writes it cleanly, and the primitive spreads because it’s strictly better than the hand-rolled version every team was already paying to maintain. If you’re looking for the next primitives, look at what sophisticated teams are building for themselves and hating. The things they build ad hoc because nothing off the shelf does it. That’s where the next primitives are incubating.

​
The Vers-shaped cost

Here’s the cost this essay is, if you’re being honest, designed to make you notice: rebuilding state. Nobody logs the time they spent re-provisioning a test environment, reseeding a database, re-warming a cache, re-navigating an app to the page where a bug reproduces. It’s not on the calendar. It’s in the cracks between the scheduled work. For most engineers, it’s thirty to sixty percent of the week. For debugging-heavy work, it’s more. For teams building agent systems, where every worker accumulates filesystem state, running processes, loaded models, and session tokens, it’s the dominant cost and nobody has named it yet. The workaround, today, is ad hoc: custom scripts to spin up dev environments, seed scripts to populate databases, golden AMIs baked by hand, careful runbooks to recreate production state. Every sophisticated team has some version of this, built for themselves, maintained at a cost nobody wants to talk about. The pattern is identical to “before package managers, every project had its own install script.” A primitive that lets you branch state in microseconds, commit it as a content-addressable snapshot, and restore it anywhere is the thing that consolidates all those workarounds. It’s the “of course” that will be obvious in retrospect. The state isn’t something you rebuild; it’s a value you branch from, like a git commit. The recurring cost of reconstruction goes away. That’s what Vers is. Not because Vers is an especially clever VM hypervisor — there are many good VM hypervisors — but because the primitive it exposes eliminates a cost that infrastructure has been quietly accumulating for twenty years. Once you have it, the shape of the work changes. You stop budgeting for the setup tax. You stop choosing workflows around the fact that reproduction is expensive. You do the things you wouldn’t have done before, because the cost was too high to justify. That’s how primitives work. That’s the whole pattern. The interesting question isn’t whether branchable state is useful — it obviously is — it’s what else you’ll be able to do with it once it’s cheap enough to use without thinking.

​
What’s next

The frame gives you a way to evaluate new infrastructure proposals. When you see one, ask:
  1. What recurring cost does this eliminate?
  2. Is the cost being paid frequently enough that eliminating it matters?
  3. Is the primitive cheap enough that it can live in the hot path, not just in occasional batch jobs?
If the answer to (1) is vague, the primitive won’t stick. If the answer to (2) is “only in edge cases,” the primitive has a narrow user base forever. If the answer to (3) is “no,” the primitive is interesting but designed around rather than designed with. Every primitive in the standard toolkit answers yes to all three. The ones that became infrastructure rather than tools answered yes decisively. The ones that stayed niche usually answered no to (3) — they were conceptually right but too slow to use casually. This is the test we should be applying to the infrastructure we build and the infrastructure we adopt. The primitives that matter aren’t the ones that make things marginally more convenient. They’re the ones that kill costs we’d stopped noticing we were paying.

​
Further reading

A short history of fork()

The canonical example: a primitive that killed the “rebuild the process state from scratch” cost and became the shape of Unix.

The cost of rebuilding state

The other side of this essay: the concrete, per-engineer cost that branchable state kills.

Content-addressable everything

Git as the consolidation of per-project version-control hacks into a general primitive.

Core concepts

The user-facing model of the primitive discussed here.