Introduction

On CoreOS-style systems, keeping containers alive across reboots is usually a combination of Docker restart behavior and systemd service management. The simplest answer is often a Docker restart policy, but CoreOS environments also make systemd a natural place to define container lifecycle explicitly.

The best approach depends on how much control you need. If you just want a container to come back after reboot, Docker’s restart policy may be enough. If you need dependencies, ordering, logging integration, or environment management, a systemd unit is usually the better operational choice.

Option 1: Use Docker Restart Policy

Docker can restart a container automatically after daemon restart or machine reboot when the container was created with a restart policy.

1docker run -d \
2  --name web \
3  --restart=always \
4  nginx:latest

Common restart policies are:

• 'no for no automatic restart'
• 'on-failure to restart only on non-zero exit'
• 'always to keep restarting'
• 'unless-stopped in Docker environments that support it'

If your need is simple, --restart=always is usually the easiest answer.

Why CoreOS Often Pushes You Toward systemd

CoreOS has historically treated systemd as the central process manager. That makes it a strong fit for container startup because you can express:

• boot ordering
• network dependencies
• environment files
• restart behavior
• cleanup rules

A systemd unit also makes the container startup process visible through the same service-management tooling used for the rest of the host.

Example systemd Unit

A basic unit file might look like this:

1[Unit]
2Description=My Docker Container
3After=docker.service
4Requires=docker.service
5
6[Service]
7Restart=always
8ExecStartPre=-/usr/bin/docker rm -f web
9ExecStart=/usr/bin/docker run --name web -p 80:80 nginx:latest
10ExecStop=/usr/bin/docker stop web
11ExecStopPost=/usr/bin/docker rm -f web
12
13[Install]
14WantedBy=multi-user.target

Save it under a path such as /etc/systemd/system/web.service, then enable it:

sudo systemctl daemon-reload
sudo systemctl enable web.service
sudo systemctl start web.service

Now systemd will start the container service on boot.

Restart Policy Versus systemd Restart

It is important not to create confusing overlapping restart strategies unless you mean to. If systemd is managing the container as a service and also Docker is trying to restart it internally, debugging failures can become harder.

A practical guideline is:

• use Docker restart policy for a simple standalone container lifecycle
• use systemd when the container is part of host-level service orchestration

Either can work, but systemd is often more transparent on CoreOS-like hosts.

Handling Dependencies and Boot Order

One advantage of the systemd approach is explicit dependency control. For example, you may want the network and Docker daemon ready before the container starts.

1[Unit]
2After=network-online.target docker.service
3Wants=network-online.target
4Requires=docker.service

That is much cleaner than trying to embed boot-order assumptions inside ad hoc shell scripts.

Updating an Existing Container

Restart policies only apply to containers created with them. If you have an existing container without the right setting, update it or recreate it.

docker update --restart=always web

If the environment is managed through systemd instead, edit the unit file and reload the daemon.

Common Pitfalls

One common mistake is assuming a currently running container will magically restart after reboot without either a Docker restart policy or a systemd unit. It will not.

Another issue is mixing Docker’s restart logic with systemd restart logic without understanding which component actually owns the lifecycle. That can create confusing repeated restarts.

It is also easy to forget systemctl enable, which means the service starts manually now but not on the next boot.

Finally, if the container exits immediately because of a configuration or image problem, auto-restart settings only cause repeated failure loops. You still need to inspect logs and fix the underlying cause.

Summary

• The simplest way to restart a Docker container after reboot is usually --restart=always.
• On CoreOS-like hosts, systemd is often the more explicit and maintainable way to manage container startup.
• Use a systemd unit when you need dependencies, boot ordering, or host-level service control.
• Avoid overlapping restart strategies unless you intentionally want both layers involved.
• Auto-restart only helps after boot if the container or service was configured for it ahead of time.