When a Docker container is continuously restarting, you can't use docker exec because the container never stays in a running state long enough.
docker exec -it myapp sh
You'll typically get:
Error response from daemon: Container <id> is restarting, wait until the container is running
The Solution
Start a temporary container using the same Docker Compose service, but override its entrypoint with a shell.
docker compose run --rm --entrypoint sh <service-name>
Example:
docker compose run --rm --entrypoint sh rusikapi
Why It Works
This command creates a new container using the same:
- Image
- Environment variables
- Volumes
- Networks
- Service configuration
Instead of starting your application, it opens an interactive shell, allowing you to investigate the environment before anything crashes.
Common Debugging Tasks
Once inside the container, you can:
# Verify environment variables
printenv
# Inspect application files
ls -la
# Run Prisma migrations manually
npx prisma migrate deploy
# Start the application
npm run start
This makes it much easier to identify startup failures, database connectivity issues, or configuration problems.
Takeaway
docker compose run --rm --entrypoint sh is a simple but effective debugging technique that every Docker Compose user should know.
docker compose run --rm --entrypoint sh <service-name>
Top comments (1)
This is a really practical tip-nice and straight to the point.
Containers stuck in a restart loop can be frustrating, especially when you can’t even get a shell to inspect what’s going wrong. Using docker compose run --entrypoint sh to spin up a clean instance with the same configuration is a smart workaround. It gives you just enough access to validate environment variables, check mounted volumes, and manually run commands without the app crashing immediately.
I also like that you highlighted real debugging steps like checking printenv or running migrations-those are often exactly where things break.
One small addition could be checking logs with docker compose logs alongside this approach, since logs + interactive inspection together usually pinpoint the issue faster.
Overall, super useful tip-simple but something many people overlook 👍