Deploying an open-source application on an Ubuntu VPS is repeatable when you separate the work into clear layers: server security, Docker Compose, DNS, HTTPS, data protection, monitoring, and rollback. This guide provides a reusable workflow and a maintenance checklist you can revisit whenever the application, domain, or hosting environment changes.
Overview
A VPS gives you control over the operating system, container runtime, network rules, and application data. Docker makes the application easier to install and reproduce, while Docker Compose keeps related services—such as an application, database, and cache—described in one file.
The exact commands vary by application, but the operating model is broadly similar:
- Create an Ubuntu VPS with enough memory, storage, and network capacity for the application and its database.
- Secure SSH access and apply operating-system updates before deploying anything.
- Install Docker Engine and the Compose plugin from the provider or Docker documentation.
- Store the application configuration in a controlled directory and keep secrets outside public files.
- Point a domain or subdomain to the VPS, then place a reverse proxy in front of the application.
- Enable HTTPS, test backups, and document how to update or restore the deployment.
This approach works for many open-source projects, but always check the application’s own documentation for required environment variables, supported databases, storage paths, and upgrade instructions. A container can simplify installation; it does not remove the need to understand the data the application creates.
What to track
Server access and security
Record the VPS provider, server IP address, Ubuntu release, hostname, SSH port, administrator accounts, and the location of your deployment files. Use SSH keys rather than sharing a password, disable direct root login when your access method is confirmed, and create a separate administrative user with controlled sudo access.
Allow only the network ports you need. A typical web deployment requires SSH plus HTTP and HTTPS; the application’s internal port and database port should generally remain private to the Docker network. If you change the SSH port, update your connection notes and firewall rules together so you do not lock yourself out.
Docker Compose and application configuration
Keep a version-controlled copy of compose.yaml, the reverse-proxy configuration, and a documented example environment file. Do not commit passwords, API tokens, encryption keys, or private certificates. Store production values in a protected environment file or a suitable secrets system, and restrict its permissions.
A simplified Compose structure might look like this:
services:
app:
image: example/project:version
restart: unless-stopped
env_file: .env
volumes:
- app-data:/var/lib/app
networks:
- internal
db:
image: example/database:version
restart: unless-stopped
env_file: .env
volumes:
- db-data:/var/lib/database
networks:
- internal
volumes:
app-data:
db-data:
networks:
internal:Use the application’s documented image and data paths rather than copying this example literally. Pinning an image to a known version makes upgrades deliberate. A floating tag can make a routine container recreation behave like an unplanned upgrade.
DNS and HTTPS
Create an A or AAAA record for the chosen hostname and point it to the VPS address. If a DNS proxy is enabled, verify that it supports the traffic and certificate mode you intend to use. For a practical explanation of the server-side and DNS steps, see How to Point a Domain to a VPS and DNS Propagation Explained.
Use a reverse proxy such as Caddy or Nginx to terminate TLS and forward requests to the application’s private container port. Confirm that the application knows its public HTTPS URL; otherwise, login redirects, cookies, webhooks, or generated links may use the wrong scheme or hostname.
Data, logs, and recovery
Identify every persistent data location before launch. This may include a database volume, uploaded files, application configuration, and an encryption or signing key. Backing up only the Compose file is not enough.
Track backup frequency, destination, retention, encryption, and the last successful restore test. Keep at least one backup separate from the VPS. Also record disk usage, memory pressure, CPU load, container restart counts, HTTP errors, certificate expiry, and application logs. The VPS Monitoring Checklist provides a broader list of operational checks.
Cadence and checkpoints
Use a small maintenance calendar rather than waiting for an incident.
- After initial deployment: Test the public URL, HTTPS redirect, login flow, email or webhook integrations, file uploads, database writes, and container restart behavior. Reboot the VPS during a planned window to confirm the stack returns automatically.
- Weekly: Review disk space, memory, container health, error logs, backup status, and unusual authentication attempts. Confirm that scheduled jobs and outbound integrations still work.
- Monthly: Review available updates for Ubuntu, Docker, the reverse proxy, the application image, and the database. Read the project’s release notes before upgrading, then update one logical component at a time where practical.
- Quarterly: Perform a restore test in a temporary directory or separate VPS, review firewall and user access, verify DNS records, and check that the documented deployment procedure still matches the server.
- Before every upgrade: Capture a database backup, confirm storage capacity, note the current image versions, and write down the rollback command or previous image references.
For a small deployment, a spreadsheet or repository issue can be sufficient. Record the date, change, result, and follow-up action. The goal is not elaborate process; it is being able to answer what changed when a problem appears.
How to interpret changes
Not every warning requires an immediate redesign. A gradual increase in disk usage may indicate normal uploads, growing logs, or abandoned Docker images. Measure the cause before deleting data. If storage rises quickly, check database growth, log rotation, backup files, and container layers.
Repeated container restarts can indicate an invalid environment variable, failed database connection, insufficient memory, or an application-level crash. Review the service logs and health checks together. Increasing the VPS size may help with genuine resource pressure, but it will not fix a configuration error.
HTTP errors should be separated by layer. A DNS problem prevents the hostname from reaching the expected address. A reverse-proxy error may indicate a stopped container or incorrect upstream port. An application error may require reviewing migrations, permissions, or its own logs. This distinction prevents changing several components at once and losing the original evidence.
When an upgrade fails, stop and preserve the current state. Save logs, note the image versions, and avoid repeatedly restarting a service that may be performing a database migration. If the project documents a downgrade path, follow it. Otherwise, restore the database and persistent files to an isolated test deployment before deciding whether to roll back or complete the upgrade.
When to revisit
Revisit this deployment guide on a monthly or quarterly schedule, and immediately after any material change. Material changes include moving to a different VPS hosting provider, changing the domain, adding a database or worker service, exposing a new port, switching DNS proxy settings, or adopting a new application release process.
Start each review with four questions:
- Can a new administrator rebuild the stack from the repository and documented secrets without guessing?
- Have backups completed, and has a restore been tested recently?
- Are resource usage, certificates, DNS records, and container versions within expected limits?
- Is the rollback procedure still valid for the current application and database schema?
If any answer is no, make that the next maintenance task. Keep the deployment deliberately boring: minimize exposed services, pin versions, protect secrets, test recovery, and change one layer at a time. For decisions about the underlying server, compare capacity and operational features in a current VPS hosting comparison rather than choosing solely on advertised specifications.
