Named volumes
Keep runtime data outside the writable layer
Lesson 7 of 20 · 12 min · Module 3: Persistence and a first project
Container replacement should not determine whether important data survives.
Start this lesson →Free. No installation: you write and run the code in your browser, and it is checked automatically.
By the end, you’ll be able to…
- Identify the persistence boundary
- Describe the mount
The idea
Container operations change instances and their attached configuration. Inspect the resulting state as well as the command sequence.
01Identify the persistence boundary
The writable container layer belongs to one container. A named volume has a separate lifecycle and can be attached to a replacement instance.
02Describe the mount
-v notes-data:/data connects the named volume to the application path. The source name and destination path serve different purposes.
03Remove only what you intend
This lab models volume ownership and container lifecycle. It does not claim to run a database or prove a real backup exists. Backups remain a separate operational responsibility.
Your turn
What the checks look for
- Keeps the named volume
- Removes the stopped instance
- Used the requested data mount
Take this with you
Separate the lifecycle of application instances from durable data.
Go a little further
Create a replacement api using the same named volume.