13.2.2.1 Single Server Target
A focused guide to Single Server Target, connecting core concepts with practical Docker and container operations.
A single server target deploys an application's container directly to one specific machine, the simplest possible delivery target, reasonably appropriate for a smaller application without significant redundancy or scaling requirements.
Deploying Directly to a Single Server
A deployment script connects to the target server and runs the container directly.
ssh deploy@server.example.com "docker pull registry.example.com/myapp:1.0 && docker run -d --name myapp -p 80:8080 registry.example.com/myapp:1.0"
This pulls the specified image and runs it directly on that one server, with no additional orchestration layer involved.
Handling an Existing, Previously Running Container
A redeployment needs to stop and remove any previous container instance before starting the new one.
ssh deploy@server.example.com "docker stop myapp || true && docker rm myapp || true && docker pull registry.example.com/myapp:2.0 && docker run -d --name myapp -p 80:8080 registry.example.com/myapp:2.0"
This sequence stops and removes the prior container before starting the updated one, avoiding a naming conflict.
Why a Single Server Target Has No Built-In Redundancy
Since everything runs on one machine, that machine becoming unavailable takes the entire application down with it — a limitation worth being explicitly aware of when choosing this delivery target for anything beyond non-critical or low-traffic use cases.
ssh deploy@server.example.com "docker ps"
When This Target Remains a Reasonable Choice
For a small internal tool, a low-traffic application, or an early-stage project not yet needing redundancy, the simplicity of a single server target can reasonably outweigh the lack of built-in resilience that a more complex orchestration target would otherwise provide.
Why Single Server Target Matters
Understanding both the simplicity and the inherent limitation of deploying directly to a single server helps in making a deliberate, appropriate choice about when this delivery target genuinely fits an application's actual requirements, and when a more resilient target becomes necessary instead.