Docker Containers Are Ephemeral — Persisting Data

Direct Answer

A container's writable layer is tied to that container. Stopping and starting the same container normally keeps it, but removing the container discards that layer. Persist important data in a named volume, bind mount, or external service. Volume lifetime and cleanup depend on whether it is named or anonymous and on the commands/options used.

Code Example

// Run Postgres with a named volume for database persistence
// docker run -d --name postgres-db -v pgdata:/var/lib/postgresql/data postgres:15

// Run Spring Boot app with volume for user file uploads
// docker run -d --name order-service -p 8080:8080 -v uploads:/app/uploads myapp:latest

@RestController
public class FileUploadController {
    private static final String UPLOAD_DIR = "/app/uploads";

    @PostMapping("/upload")
    public ResponseEntity<String> uploadFile(@RequestParam("file") MultipartFile file) {
        var targetPath = Path.of(UPLOAD_DIR, file.getOriginalFilename());
        // Write to /app/uploads inside container, actually goes to Docker volume
        Files.copy(file.getInputStream(), targetPath, StandardCopyOption.REPLACE_EXISTING);
        return ResponseEntity.ok("File saved: " + file.getOriginalFilename());
    }

    @GetMapping("/files")
    public List<String> listFiles() {
        // List persisted files from volume, survives container restart
        return Files.list(Path.of(UPLOAD_DIR))
                .map(path -> path.getFileName().toString())
                .toList();
    }
}

Common Mistakes & Pitfalls

• Writing critical data inside the container: Freshers deploy a Spring Boot app with an embedded H2 database writing to /data/app.db inside the container, then removes/recreates the container without retained storage and loses the data because /data wasn't mounted to a volume. The writable layer is ephemeral by default.
• Not understanding volume lifecycle: Creating a container with -v mydata:/app/data, then removing the container with docker rm — the volume mydata still exists on the host, but freshers think it's gone and create a new volume, leading to orphaned volumes consuming disk space. Use docker volume ls and docker volume prune to manage them.
• Confusing volumes and bind mounts: Trying to use a bind mount like -v /local/path:/container/path on a production server where /local/path doesn't exist or has different permissions, causing the app to crash. Volumes are more portable because Docker manages the host path.
• Permission mismatches: Mounting a host directory with root ownership into a container running as a non-root user — the app can't write to the mount point and fails with permission denied errors. The fix is setting correct ownership with chown in the Dockerfile or using named volumes where Docker handles permissions.