Cold start to 'Done!' in seconds

The berrybyte promise is three clicks and a vibe: pick a game, name it, hit go, and a few seconds later you’re pasting an IP into a group chat. Start it up, configure, play. Khalas.

The “few seconds” is the interesting part. Creating a game server can be slow — slow enough to sit and watch a spinner — and most of the speed comes not from doing the work faster, but from arranging never to do it at all.

The two things that make a new server slow

Spinning up a fresh server has two genuinely heavy steps:

1. Pulling the image. Every server runs in a container, and that container image — the runtime, the JVM, the tooling — can be hundreds of megabytes to a couple of gigabytes.
2. Installing the game. The first time a server boots it runs an install: fetch the actual server build (the Paper jar, the modpack, whatever), unpack it, lay out the files.

Do both naively, from scratch, over the public internet, and you’re looking at minutes. Our whole job is to make each one almost free.

Images already live next door

The slowest image pull is one that crosses the internet. So we don’t. Each datacenter runs a pull-through registry mirror: the first time anyone in that location needs an image, it’s fetched once and cached locally; everyone after that pulls it from a machine a cable’s length away, at LAN speed.

And images are content-addressed — every layer has a sha256 digest. Once a node has a layer, it never fetches it again. On a box that’s already run a few Minecraft servers, the Minecraft image is simply there.

Sharing layers so there’s almost nothing to pull

Even when something is missing, it’s usually tiny — because our game images are built as a stack of shared layers.

sha256:9f3b…  base os + utils        180 MB   ← shared by every image
sha256:1c77…  jre 21                 140 MB   ← shared by every JVM game
sha256:a012…  paper runtime           22 MB   ← shared by all Paper versions
sha256:e5d9…  paper 1.21 build         8 MB   ← the only new layer

OCI layers are deduplicated by digest, so creating a Paper 1.21 server on a node that’s already run any JVM game means the 320 MB of base + JRE is already present. The only thing that might need fetching is the 8 MB on top — and even that’s usually in the mirror. “Pulling the image” becomes “noticing we already have it.”

Installing a game we’ve already installed

The second slow step — the install — gets the same treatment from the other direction.

The first time we ever set up, say, Paper 1.21, the install downloads the build from upstream. We don’t make the next customer pay that cost. The artifacts are cached, and for popular games we keep a pre-installed snapshot of the finished data directory. A new server of that type isn’t a download-and-unpack from the internet; it’s a fast local copy of files we already laid out.

So the very first Paper 1.21 server in a location might do a real install. The hundredth is a copy.

Click to “Done!”

Put the pieces together and a typical create looks like this from the node agent’s point of view:

create srv_7Qm2p  paper:1.21
  image    cached on node            0.4s   (base+jre+paper already present)
  install  restored from snapshot    2.1s   (no upstream download)
  config   wrote server.properties   0.2s
  start    process up, port bound    1.8s
  → ready in 4.5s

Four and a half seconds, and almost none of it was the “hard” work — because the image was already on the box and the install was a copy, not a download. The first server of a brand-new game type in a fresh location is slower; it’s doing the work that makes everyone after it fast.

That’s the pattern under most things that feel instant: somebody already paid the cost, once, so you don’t have to. Pick a game, hit go, and start playing.