Short answers to the operational questions that tend to come up before or right after the first deployment.
Official docs are the right source for feature details and supported installation paths. This site focuses on the smaller operational questions around layout, updates, backups and what usually matters first on a modest VPS.
No. These services can often run directly on the host. Docker Compose is used here because it makes small deployments easier to inspect, rebuild and move between machines.
For many small setups, nginx is enough as the public edge: serve static assets, terminate TLS, pass requests to internal containers and keep simple host-based routing in one place.
1 GB RAM is enough for several narrow services if you avoid stacking too much at once. Once you add a Git forge, a database and monitoring together, 2 GB becomes a more comfortable floor.
Separate subdomains are usually easier to reason about. Each service gets a clear hostname, nginx rules stay short and migrations are less disruptive later.
Back up persistent volumes first, then the Compose files and environment values that describe how the service was deployed. Without the service state, rebuilding containers alone does not help much.
A steady schedule beats long periods of neglect. Monthly updates are a practical baseline for small, low-risk services, with a quick read through release notes before each change.
Not always. For one or two internal tools, logs and a basic uptime check can be enough at first. Monitoring becomes more important once multiple services share the same host.
Start with SQLite when the application supports it and the expected load is small. A separate database is useful when you already operate one or when the service is becoming shared team infrastructure.
Keep the previous image tag, preserve the last known-good Compose file and take a quick backup before upgrade. For small services, that combination solves most rollback situations without extra machinery.
