The container community spends most of its words on orchestration, but most containers in the world run on one Docker host with a Compose file, and that is often correct. The question is not whether to orchestrate; it is whether this workload needs it. This post follows a developer running a company's internal tools on the Docker Engine CE package on MassiveGRID PaaS, which is built on Virtuozzo Application Platform, formerly Jelastic, and drawing the line clearly.
The developer looks after internal tooling at a design agency we will call Umber Studio: a wiki, a URL shortener, a Grafana dashboard, a small Go service and a Postgres for them, all described in one Compose file. The Docker Engine CE package installs Docker Engine Community Edition, containerd, the CLI and the Compose plugin on a dedicated Linux node with root SSH access.
Three ways the package can start
The installer offers three modes. A clean standalone engine, optionally with Portainer, the web UI for managing containers. Connect to an existing swarm, joining the node as a worker with a join token and manager address. Deploy from a compose.yml in a Git repository, which brings the stack up at install. Umber's developer picks standalone with Portainer, because the team includes designers who will restart a container from a web page but never from a shell, and adds the Compose file over SSH.
What is different from a VPS with Docker
Functionally it is a Docker host; you have root, you run docker compose up -d, everything works as on any Linux box. The differences are around it. The node is a platform container on its own physical host, so it scales vertically in cloudlets (128 MiB of RAM plus 400 MHz of CPU each) by the hour up to the limit you set, rather than being a fixed size. It has snapshots from the dashboard, which are the developer's rollback before any stack upgrade. It has a container firewall with inbound denied by default. And it needs no operating-system maintenance from the team, because the node's base image is the platform's.
Exposing services without a public IP
Internal tools should not be on the public internet. The developer uses two platform features instead of a public IP. For the web UIs, an NGINX load balancer node in the same environment proxies to the containers' published ports and is reached through the platform's shared load balancer on a subdomain, with the Let's Encrypt add-on for the agency's domain and the container firewall restricting access to the office VPN's addresses. For the Postgres and the Go service's gRPC port, which only the team's laptops need, endpoints map the container ports through the shared balancer to a random public port with no IP to pay for; each endpoint can be removed when not needed. The Docker daemon's own API port is never exposed.
| Service | Exposure | Mechanism | Access |
|---|---|---|---|
| Wiki, Grafana, shortener | HTTPS on agency domain | NGINX node, shared balancer, Let's Encrypt | Office VPN addresses only |
| Postgres 5432 | Occasional, from laptops | Endpoint, removed after use | Password plus firewall |
| Go service gRPC | Internal only | Internal network, no endpoint | Other environments in the group |
| Docker API | Never | Firewall default deny | SSH only |
Backups and upgrades on one node
One node means the data is on one node, and the developer treats that honestly. Named volumes hold the wiki's files and the Postgres data; a nightly job runs pg_dump and an archive of the volume directories to a Backup Storage node in the same environment group. Before a Compose stack upgrade, a platform snapshot of the node is the rollback; after docker compose pull and up -d, the snapshot is deleted a day later. Portainer shows the designers what is running and lets them restart a container that a plugin has wedged, which was the actual daily problem.
When one node stops being enough
The developer writes down the graduation criteria so the decision is not emotional. Move to the Docker Swarm Cluster when any of these is true: a service must survive the host failing without the minutes the platform takes to restore a container; a service needs more than one replica for throughput; or deploys must be rolling rather than a brief restart. The Compose file will move with a deploy section added, and the Docker Engine node itself can join the swarm as a worker through the package's second install mode. For a wiki, a shortener and a dashboard used by thirty people, none of the criteria is true, and paying for an orchestrator would be paying for nothing.
Cost
Updates to the host itself are a platform matter: the node's base image is maintained by the provider, and the Docker Engine version inside it is updated by the developer like any package on a Linux host, after a snapshot. Container images are updated by docker compose pull on a monthly schedule, with Portainer's image-update indicators as the reminder.
The node idles at 4 to 6 cloudlets and rises to 12 when the Go service builds thumbnails, averaging about 7 cloudlets an hour, roughly $17 a month before discounts at MassiveGRID's published $0.003372 per cloudlet-hour, plus a small disk and the backup storage node. The developer stops it on the agency's two-week summer closure with the Start/Stop Scheduler, during which it bills for disk only.
Frequently Asked Questions
Is this the same as deploying a Docker image directly as a platform container?
No. The platform can run a single image as a managed container with its own scaling and dashboard integration, which suits one application. The Docker Engine CE package gives you a full Docker host where you run many containers, Compose stacks and your own daemon configuration; you manage inside it, the platform manages the node.
Can I use Docker volumes on the platform's shared storage?
Yes. Mount a shared storage container into the Docker node over NFS through the platform's mount points and point bind mounts or a volume driver at it. That is also how several Docker hosts share files if you later join a swarm.
Which Docker Engine version is installed?
You choose the version at install from the available current releases. Upgrading later is a matter of updating the engine on the node as on any Linux host, with a snapshot taken first.
One Docker host, properly run
The Docker Engine CE package gives you a dedicated Docker host with Compose, optional Portainer and root SSH on MassiveGRID PaaS, scaling by the hour with snapshots and a firewall. Join a swarm later if you need to. Free 14-day trial.
Docker Engine CE on MassiveGRID PaaS