Where your data actually lives, and why it matters

By Raviteja KNTSUpdated July 9, 2026

This is the lesson that saves you from the worst beginner mistake: wiping data you can't get back. The rule is simple once it clicks. The container is disposable. Your data is not. The whole job is keeping those two apart.

Your first app, Excalidraw, was simple enough to keep everything in your browser, so there was nothing on the server to lose. But the moment you install something that has to remember things, notes, photos, accounts, its data lives inside the container, and you have to make sure it lands somewhere safe. That's the whole job of a volume.

Take that ./data:/app/data line you saw in the last lesson. Inside the container, the app writes to /app/data. That line maps it to a real data folder on your server's disk, outside the container. So when you delete and recreate the container, the app comes back and finds all its stuff exactly where it left it.

Two ways to keep data, and which to use

You'll see both in the wild. A bind mount is a real folder you can see and open, like the ./data in your app's folder. A named volume is storage Docker manages for you, written like app-data:/app/data with a matching volumes: block at the bottom of the file. Both persist your data.

As a beginner, I'd lean toward bind mounts, the ./data style, because you can actually see the files, copy them, and back them up without any Docker commands. Named volumes are tidier and a bit safer from accidental edits, but they're less obvious to find when you want to grab a backup. Either is fine; just know which one an app is using so you know where its data actually sits.

Config, media, and databases

Not all data is the same weight. An app's config is small but annoying to recreate, your settings, accounts, preferences. Media like photos or videos is big and often the whole reason you're hosting. A database is the app's memory, and it needs a little extra care: copying its files while it's running can give you a broken copy, so proper backups of a database use a dump instead of a plain file copy. More on that in the backups lesson, two stops from here.

Keep every app in its own folder under something like ~/apps, with its compose file and its data folder together. Then "back up my apps" just means "copy these folders", which is exactly where this course is headed. The path there runs through one more stop on purpose: practice the install pattern on a few low-stakes apps first, so by the time backups matter, you have real folders worth protecting.