Running Docker containers on a VPS gives developers control over application versions, networking, storage, and deployment workflows without requiring a full container platform. This guide explains how to choose a suitable VPS, prepare an Ubuntu server, deploy services with Docker Compose, add HTTPS through a reverse proxy, protect secrets, control resource use, back up persistent data, and create a maintenance routine you can revisit as the application changes.
Overview
A VPS is a practical middle ground between conventional shared hosting and a larger cloud orchestration platform. You receive an isolated virtual server with administrative access, while Docker packages an application and its dependencies into repeatable containers. The combination works well for open-source applications, internal tools, staging environments, small production services, and SaaS MVPs.
The tradeoff is operational responsibility. A Docker hosting provider may supply the virtual machine, network, storage, and snapshots, but you still need to secure the operating system, maintain the container images, configure DNS, protect application data, and test recovery procedures. Container isolation does not remove the need for server administration.
For a first deployment, assume an Ubuntu VPS with a static public IP, a domain name, SSH access, and enough memory for the operating system, Docker, the application, and temporary workload spikes. Exact requirements depend on the application. A database, search service, build process, or media workload generally needs more resources than a simple web service.
Before ordering a server, compare virtual CPU allocation, memory, disk type and capacity, backup options, IPv4 and IPv6 support, recovery tools, region availability, and billing controls. Our VPS comparison for developers provides a useful framework for evaluating these factors rather than choosing solely by advertised CPU count.
What to track
Server health and capacity
Track CPU usage, memory consumption, swap activity, disk usage, disk I/O, and network traffic. A short spike during a deployment is different from a sustained increase. Record normal ranges after launch so that later changes are easier to identify.
Leave operating-system headroom. If memory remains near capacity, the kernel may terminate processes or the application may become unreliable. If disk usage steadily rises, identify whether logs, uploaded files, database growth, unused images, or old backups are responsible. Do not solve a full disk by deleting files at random; first determine which data is disposable and which is required for recovery.
Container and application behavior
Track whether each expected container is running, restarting, or failing its health check. Review application logs for repeated connection errors, authentication failures, database timeouts, and migration warnings. A container can be marked as running while the application inside it is unavailable, so check the service from outside the server as well.
Use a Compose file as the deployment record. A simple service definition might include a restart policy, a health check, a persistent volume, and resource limits:
services:
app:
image: example/app:1.4.2
restart: unless-stopped
env_file:
- .env
ports:
- "127.0.0.1:8080:8080"
volumes:
- app_data:/var/lib/app
deploy:
resources:
limits:
cpus: "1.0"
memory: 512M
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
interval: 30s
timeout: 5s
retries: 3
volumes:
app_data:Adjust paths, ports, commands, and limits to the application. Binding the application port to localhost keeps it away from direct public access when a reverse proxy is running on the same VPS. Resource limits are guardrails, not a substitute for capacity planning.
Security signals
Keep a record of exposed ports and review it whenever the Compose configuration changes. In many deployments, only SSH, HTTP, and HTTPS need to be reachable publicly; database and internal service ports should remain on private Docker networks or localhost. Use SSH keys, disable password authentication where appropriate, apply security updates, and avoid giving routine users unnecessary administrative access.
Treat membership in the Docker group as privileged access because it can provide control over the host. Store secrets outside the image and avoid committing .env files containing credentials to a repository. Use a secrets manager when the application or team requires one, and rotate credentials after accidental exposure.
Backups and recovery
Track the last successful backup of every persistent volume and database, the retention period, and the location of the backup. A VPS snapshot may help restore a whole server, but it should not automatically be treated as an application-consistent database backup. Test restoring a representative backup to a separate location and document the commands needed to bring the service online.
Cadence and checkpoints
Use a small maintenance calendar rather than relying on memory. The following schedule is a practical starting point; shorten the intervals for systems with sensitive data, frequent deployments, or strict availability requirements.
- At every deployment: review the image tag, Compose changes, environment variables, migration steps, health checks, and rollback plan. Confirm that the new container starts before removing the previous working version when your deployment method permits it.
- Weekly: inspect container status, recent logs, failed health checks, disk usage, backup results, and unusual login activity. Confirm that monitoring and alert delivery still work.
- Monthly: apply tested operating-system and application updates, review exposed ports and administrator accounts, remove unused images carefully, and verify that backups can be read. Check whether the VPS still has adequate memory and storage headroom.
- Quarterly: perform a recovery exercise, review image sources and pinned versions, reassess the VPS plan, rotate credentials where required, and document changes to DNS, certificates, firewall rules, and deployment procedures.
For updates, prefer a controlled sequence: read the release notes, back up persistent data, pull the intended image, recreate the service, inspect health checks and logs, and keep a tested rollback path. Avoid using an unreviewed latest tag for production services because it makes the deployed version harder to identify and reproduce.
HTTPS normally requires a reverse proxy such as Caddy, Nginx, or Traefik. The proxy accepts public web traffic, obtains or uses a certificate, and forwards requests to containers on an internal network. Point the domain's DNS records to the VPS before testing certificate issuance. For a complete domain and server sequence, see how to point a domain to a VPS.
How to interpret changes
Look for patterns before changing infrastructure. Rising memory after every deployment may indicate a leak, an unbounded cache, or a growing workload. Rising disk usage may come from application uploads rather than containers. Frequent restarts may reflect a failed dependency, an invalid environment variable, an overly strict health check, or a process that is being killed for exceeding its memory limit.
Separate symptoms from causes. A slow response time can result from CPU saturation, database locks, network latency, an overloaded reverse proxy, or an application regression. Compare application logs with server metrics and deployment timestamps. If the problem began immediately after an image update, a rollback can confirm the relationship while you investigate; it does not replace a permanent fix.
When traffic grows, first identify the bottleneck. More CPU will not fix a full disk, and more memory will not correct a database query that scans an unnecessarily large data set. Consider database indexes, caching, log retention, image size, connection limits, and background jobs before resizing the VPS. If one host now runs unrelated services, separating them can improve fault isolation even when the combined resource use appears acceptable.
Downtime risk also comes from changes outside Docker. DNS records, firewall rules, certificate renewal, provider networking, and domain expiration can all interrupt an otherwise healthy container. Maintain a short inventory of these dependencies and test access using the public hostname, not only localhost.
When to revisit
Revisit this deployment guide on a monthly or quarterly cadence, and immediately after a material change. Material changes include moving to a new VPS, adding a database or queue, exposing a new public endpoint, changing the reverse proxy, switching image registries, modifying DNS, or introducing a second administrator.
Use each review to answer five concrete questions: What is running? What data must be recoverable? Which ports and credentials are exposed? How long would a restore take? What changed since the last review? Record the answers in the repository or operations documentation so another administrator can reproduce the deployment without guessing.
For a practical next step, create a private deployment checklist containing the server IP, DNS records, firewall rules, Compose file location, environment-variable names, backup destination, restore procedure, and rollback command. Then perform one clean deployment and one restore test. If the checklist exposes a gap, fix that gap before adding more services. When the application outgrows a single VPS, use the same inventory and measurements to decide whether to resize, split services across hosts, or move to a more managed platform. The goal is not maximum complexity; it is a deployment that remains understandable, recoverable, and secure as it changes.
For a full open-source application walkthrough, see how to deploy an open-source app on an Ubuntu VPS with Docker and HTTPS.
