Docker for Solo Game Developers: Stop Being Tech Support for Your Own PC

The balancing act#

Making a game is never a one-program job. On any given day I’m in Unity, sculpting in Blender, fixing 2D assets in Adobe Animate, and writing branching dialogue in Yarn Spinner.

Every one of them wants its own versions, its own background files, its own updates.

Then you update one small thing, and Unity won’t compile. Or the test server you set up last month refuses to start. And your whole afternoon goes into being tech support for yourself instead of making your game.

I got tired of that. So I fixed it with Docker.

What a container actually is#

Forget the scary word. A container is a sealed box.

You put a program inside it along with everything it needs to run, the exact versions and the settings and all of it, and the box keeps that program from touching anything else on your machine. Nothing gets installed system-wide. Nothing leaks out.

The backend I use to test Shark’s Request lives in one of those boxes. Test server, database, all of it. When I’m done for the day I shut the box down, and my computer is exactly as clean as it was before I started.

Nothing installed. Nothing left over. Nothing to break.

What goes in the box, and what doesn’t#

This is the part most explanations skip, and it’s the part that saves you a wasted weekend.

Unity, Blender, Procreate and Adobe Animate stay on your computer, installed normally. They’re programs you look at and click in, and they want your graphics card and your tablet and your screen. They belong on the machine.

What goes in containers is everything running quietly in the background: databases, test servers, build tools, anything with a version number that fights with another version number. That’s the stuff that breaks silently and takes an afternoon to unbreak.

So the rule I use is simple. If I stare at it, it’s installed. If it just runs, it’s in a box.

Two projects, one laptop#

Right now I’m building Shark’s Request and a psychological thriller visual novel at the same time.

They need completely different setups. The visual novel keeps its own database and its own test server for the branching dialogue behind characters like Liam and Aurora, and none of that agrees with what Shark’s Request needs.

So each project keeps its environment in its own box, described by one small file that lives in the project folder:

1
# docker-compose.yml — the visual novel's dialogue database
2
services:
3
  db:
4
    image: postgres:17
5
    environment:
6
      POSTGRES_PASSWORD: dev
7
      POSTGRES_DB: dialogue
8
    ports:
9
      - "5432:5432"
10
    volumes:
11
      - dialogue-data:/var/lib/postgresql/data
12

13
volumes:
14
  dialogue-data:

Two commands run my whole day:

1
docker compose up -d
2
docker compose down

The first brings the project’s setup online. The second puts it away. Switching projects means running those in one folder and then the other, instead of reinstalling anything.

That volume line at the bottom matters more than it looks. It’s where the data lives between sessions, so shutting the box down doesn’t throw away everything I wrote.

Moving to the laptop#

Here’s the part I use most. When I want to leave my studio rig and write somewhere else, I don’t lose a day setting things up. I copy the project folder, run the same command, and the same setup comes up the same way. Same versions, same settings.

Being honest about the limit: this holds when both machines are the same kind of computer. Move between an Apple Silicon Mac and a Windows PC and some images need a different build. It’s not magic. It’s just that the setup stopped being something I think about, and that turned out to be the whole benefit.

Not faster. Quieter.

Why this is worth an afternoon#

Cleaning up your workspace is not the glamorous part of making games. Nobody claps for a tidy computer.

But every hour you don’t spend fixing your own machine is an hour you spend building your world instead. And the setup you write down once keeps working while you go do the part you actually care about, like designing the characters who live in it.

I’ll keep showing how the studio actually runs here, boring parts included.