The container starts, runs for a second, and dies with no obvious error. Almost always one of three things: the app needs a foreground process, the command is wrong, or PID 1 is misbehaving.
nginx, sshd, and many daemons fork to background by default. PID 1 exits, the container dies. Docker containers need the process to stay in the foreground.
The image's default CMD does not match what you passed; the entrypoint exits 1 or 127 (command not found). Exit 127 = the binary path is wrong.
The app as PID 1 doesn't reap zombies or handle SIGTERM; behavior looks fine at first then degrades. Use an init process.
docker logs --tail 50 <container>
CMD ["nginx", "-g", "daemon off;"] # or sshd -D, httpd -D FOREGROUND
docker run --init myapp # compose: init: true
docker inspect <container> --format '{{.State.ExitCode}} {{.State.OOMKilled}}'
Exit 0 with instant death almost always means 'daemonized itself'. Exit 1 with a stack trace in the logs is an app-level crash — fix the app, not the container.
The main process finished — for service images it's usually a command override or entrypoint misconfiguration that runs a short-lived command instead of the daemon. docker logs shows what ran; the fix is the right CMD/entrypoint for a foreground process.
With restart=always it just crash-loops faster — the process exits for a reason (crash, config error, missing env). Read the logs of the exited container and fix the exit cause; restart policy is recovery, not repair.
A production-shaped compose stack: healthchecks, resource limits, log rotation. Never debug a boot race again.
Docker Production Starter — $19 →One-time. Yours to modify. Instant download from the NinjaOps template store.