How I Host My Entire Blog with Docker Compose — A Practical Guide for Saudi-Based Developers on a Budget

Quick take: My entire blog stack — static content, monitoring, backups, and a CI/CD pipeline for automated deploys — runs on a single budget cloud server via Docker Compose. The real value came not from the tools but from understanding what breaks when everything gets more complex than a single docker-compose up.

Introduction

I have been hosting this blog's infrastructure with Docker Compose since 2019. Back then I thought it was just a convenient way to avoid installing Apache, PHP, and MySQL directly on my host server. By early 2020, it had become the only thing keeping my entire operation running when I accidentally nuked the Docker network while trying to debug why a container could not reach another. The containers restarted cleanly, but the networking did not — until I documented every custom bridge, volume mount, and restart policy so precisely that even the broken version was fixable within fifteen minutes. This article shares the exact compose configuration for my blog stack and the real lessons learned over several years of running it without a dedicated ops team.

My Actual Running Stack

Everyone shows you a docker-compose.yml with three services and calls it production-ready. Here is mine — the one that actually serves content, monitors multiple infrastructures including my homelab, and handles incremental backups across two cloud providers.

The stack:

• nginx (with Certbot integration for Let's Encrypt SSL)
• grafana + prometheus + node_exporter (monitoring)
• vaultwarden (password manager, shared with the homelab)
• rsync backup container (offsite backup to second cloud provider)

The server: DigitalOcean $10/mo droplet, 1 vCPU, 1GB RAM, 25GB SSD. Everything fits in that allocation. The host CPU has been at about 8% average load since the first month.

The Backup Strategy That Actually Saved Me

The most valuable part of this setup is not the containers themselves but how I back them up. Running everything in one compose file on one server means one point of failure. Early on I learned that lesson when a drive failure took out both my blog and my monitoring history.

Now everything gets backed up daily: configuration files (docker-compose.yml, nginx configs, prometheus data), and a separate cron job that snapshots container volumes to an S3-compatible bucket on a different provider. The total cost of offsite backups is about $5/month.

Why Bare Cloud Is Better Than Managed Platforms for This

The conversation about managed hosting versus bare VPS for self-hosted applications eventually comes down to control — and control has a direct dollar value when something breaks at 2 AM with clients depending on your infrastructure. Managed WordPress platforms like Kinsta, WP Engine, and Cloudways offer a compelling pitch: no server management, automatic updates, built-in CDN, staging environments with one click. For a non-technical user running a personal blog, that pitch is worth the premium. For an infrastructure engineer managing multiple sites, APIs, and custom applications on a tight budget, managed platforms are an expensive way to lose control of your stack.

The real cost comparison: a Hetzner CX22 instance (2 vCPU, 4GB RAM, 40GB SSD) costs €4.49 per month. A Hetzner CX32 (4 vCPU, 8GB RAM, 80GB SSD) costs €8.29 per month. For €8.29 per month, I run this blog, a Prometheus and Grafana monitoring stack, an Nginx reverse proxy with SSL termination for multiple domains, and a daily backup job. The equivalent setup on WP Engine's cheapest plan is $25 per month — and that covers exactly one WordPress site with no room for custom applications or monitoring infrastructure. For Saudi-based developers, Hetzner's Germany and Finland data centers are reachable with acceptable latency from the Gulf. Vultr operates a Bahrain presence, and DigitalOcean provides Asia Pacific regions that work reasonably for Saudi visitors. For US clients, DigitalOcean's New York and San Francisco regions or Vultr's Chicago and Los Angeles locations cover the $6–12 per month bare VPS range with solid reliability.

The argument for managed platforms — that you do not have to manage a server — collapses when the thing that breaks is something the managed platform does not expose. A client I supported in the United Kingdom was paying £80 per month for a managed WordPress hosting plan. When their site started throwing 502 errors, the hosting provider's support team could only report that server load was high and suggest upgrading the plan. The client had no access to PHP-FPM logs, no ability to tune MySQL buffer pool sizes, and no visibility into what was consuming resources. Moving them to an €8.29 per month Hetzner instance running their stack in Docker Compose gave full visibility and cost 90% less. The troubleshooting session that followed took forty minutes and revealed a plugin running an expensive database query on every page load — immediately visible in slow query logs once they had access to them.

European clients have an additional consideration: GDPR and data residency requirements that make EU-hosted infrastructure preferable or mandatory depending on the nature of the data being processed. Self-hosted infrastructure on a European VPS provider — Hetzner in Germany, OVHcloud in France, Scaleway in Paris — gives full data residency control that managed US-based platforms cannot offer cleanly. For Saudi organizations that prefer on-premises or Gulf-region hosting for compliance or latency reasons, the same principle applies: a bare VPS on a regional provider is a simpler compliance story than a managed platform with data processed in US data centers.

The overhead of managing a bare VPS is not zero. You handle OS updates, configure the firewall, and monitor disk space and memory. But with Docker Compose, that overhead is lower than it used to be: containers isolate applications from each other, docker-compose.yml documents your entire stack in version-controlled configuration, and restarting a misbehaving service is a single command. The operational complexity that justified managed hosting in 2015 has been substantially reduced by the container tooling available in 2026. For engineers offering managed Linux server support to clients in any market, the ability to explain this cost-control trade-off clearly and implement it reliably is a genuine billable capability.

Monitoring Your Compose Stack Without Paid Tools

Once your Docker Compose stack is running, the next operational gap is visibility. Without monitoring, you discover problems when someone tells you the site is down — which is always worse than discovering them before they affect visitors. The free monitoring stack I run on the same server as my Docker Compose applications is: Netdata for real-time system metrics, cAdvisor for per-container resource usage, and Prometheus with Grafana for historical dashboards and threshold-based alerting. All four tools run as additional services in the docker-compose.yml. Total additional RAM overhead is around 200MB on a server that already has 4–8GB available.

Netdata is particularly useful for budget VPS setups because it requires almost no configuration to start producing useful data. After adding it to your compose file and starting it, you have per-CPU metrics, memory usage, disk I/O, network throughput, and application-specific metrics available within minutes on port 19999. For clients I support in Saudi Arabia and the United States, Netdata is often the first monitoring tool I install because it provides immediate value without a configuration investment. The automatic detection of running services — MySQL, Nginx, Docker containers — means useful data appears without writing a single configuration line.

For alerting, the simplest approach that avoids a paid service is Prometheus Alertmanager combined with a messaging platform you already use. My setup sends alerts to a Telegram channel using a custom webhook integration. When Prometheus detects that a container has been restarted more than twice in the last ten minutes, or that disk usage exceeds 85%, or that memory is consistently above 90% for more than five minutes, a message arrives in the channel with the host name, metric name, and current value. Setup time from scratch is about two hours; after that, it runs without attention. For US and European clients who prefer email alerting, Alertmanager supports SMTP natively, which covers the use case without any third-party service dependency.

Uptime monitoring for external validation — verifying the site is reachable from outside your server — should not run on the same machine as your application. Uptime Kuma is a self-hosted alternative to UptimeRobot, deployable as a single Docker container on a second small VPS or a Raspberry Pi. For $4 per month, you can run Uptime Kuma on the smallest Hetzner instance and have independent monitoring for any number of sites with SSL certificate expiry alerts, response time tracking, and notification channels including Telegram, email, and Slack-compatible webhooks. The independence from the monitored server is the critical property: if your main server goes down, your monitoring continues to work and alert you.

For engineers providing managed server support to clients in Saudi Arabia, the United States, or Europe, introducing a simple Netdata and Prometheus dashboard is often the most tangible deliverable of an initial infrastructure engagement. It converts abstract notions of "server health" into visible metrics that business owners can read without technical background. That visibility builds client confidence and reduces emergency support calls because problems become visible before they become outages. Clients who can see their infrastructure state are also easier to work with proactively — they bring concerns based on metrics they observe rather than waiting for failures.

When Your Compose Stack Outgrows a Single Server

Docker Compose is a single-host tool. Everything in the compose file runs on one server, and the failure of that server takes down every service simultaneously. For a personal blog or a small client website, this trade-off is acceptable — a restart is a few seconds, and the cost of multi-server infrastructure is not justified by the traffic or revenue at stake. But there is a point where single-host Docker Compose stops being appropriate, and understanding that threshold before reaching it prevents the unpleasant experience of discovering it during an outage.

The practical threshold for considering multi-host orchestration is not traffic volume — it is criticality. When a client depends on your infrastructure for revenue, when downtime has contractual consequences, or when your own income depends on availability, the single point of failure that a single-server Compose stack represents becomes a business risk rather than just a technical limitation. The question is not whether to move to multi-server orchestration, but which path to take and when.

Docker Swarm is the natural next step from Docker Compose. The docker-compose.yml format is compatible with Swarm deployments with minor modifications, services run as replicated or global tasks across a cluster of nodes, and the operational model remains simple enough for a one-person operation to manage. For Saudi developers and for international clients who need a step up from single-server Compose without the operational complexity of Kubernetes, a three-node Docker Swarm cluster — one manager and two workers — provides basic high availability, rolling updates, and service scheduling across nodes. A Hetzner CX22 trio for €13.47 per month total covers a functional Swarm cluster that handles most small-to-mid web application loads.

Kubernetes is the answer when the application portfolio justifies the operational investment. It is not the answer when you are running a blog, a small API, and a monitoring stack. I routinely see organizations in Saudi Arabia and in the US that have deployed Kubernetes because it is the modern choice, not because their actual workload characteristics require it. The result is an operations overhead that consumes more engineering time than the platform saves. The right question is: does your deployment pattern, scaling behavior, or team structure actually require the capabilities Kubernetes provides over Swarm? If the honest answer is no, Swarm or a well-managed single-server Compose stack serves the workload better at a fraction of the operational cost.

For managed infrastructure clients in Saudi Arabia, the United States, and Europe who ask about scaling their self-hosted applications, my standard recommendation is to first optimize the single-server setup — right-size the VPS, tune Nginx, optimize database queries, add caching — before adding servers. Most applications that appear to need more infrastructure actually need better configuration of the infrastructure they already have. A client running a WooCommerce store on a 2GB VPS that added a Redis object cache and Nginx FastCGI caching reduced their load from 90% CPU to 30% CPU without any additional servers. The scaling conversation became unnecessary once the existing server was properly configured. Optimizing before scaling is not just a cost consideration — it builds a better understanding of what the application actually requires, which produces better architectural decisions when scaling does eventually become necessary.

The security posture of a Docker Compose stack on a public-facing VPS deserves explicit attention that managed platform users rarely need to apply themselves. When you run your own server, you are responsible for the firewall, the SSH configuration, container network isolation, and the operating system update cadence. The default Docker networking model — which adds iptables rules that can bypass UFW on Ubuntu — is a well-documented behavior that surprises engineers who configure UFW and assume it covers all incoming traffic. The fix is explicit: configure Docker to not manipulate iptables directly, and manage all firewall rules through a consistent interface. This is a two-line change in the Docker daemon configuration, but it requires knowing the issue exists before discovering it the hard way during a security review.

Container images are another security surface that self-hosted infrastructure owners manage directly. Using official images from verified publishers on Docker Hub, pinning image versions rather than using the latest tag, and running a weekly pull to apply upstream security updates covers the most common container security concerns without requiring a dedicated scanning pipeline. For clients in Saudi Arabia, the United States, and Europe who run Docker Compose stacks handling user data or payment information, I add one additional practice: a monthly review of running containers against the compose file to identify any containers that are running but no longer defined in the configuration. This can happen after manual interventions and leaves behind containers that are not maintained or monitored.

The practical experience of building, operating, and troubleshooting a Docker Compose stack for a real application — even a blog — translates directly into a billable capability for clients at every scale. Saudi startups and small businesses moving application workloads from shared hosting to VPS-based infrastructure need engineers who understand Docker Compose deployment, Nginx reverse proxy configuration, SSL certificate management, and database backup strategy. US and European clients building their first self-hosted applications need the same skills. The infrastructure knowledge required to run a personal blog on a VPS reliably is substantially the same knowledge required to run a small client application stack — the difference is in the consequences of getting it wrong, not in the technical components involved.

Final Thoughts

The Docker Compose approach to hosting a blog stack does not try to be fancy — it does exactly what any competent ops engineer could do with bare metal but removes the guesswork of service dependency management. The value in Saudi Arabia's infrastructure context comes from its simplicity: cheap enough that nobody gets nervous about spending money to learn it, powerful enough that every problem I encountered here shows up somewhere in real enterprise work. Several years of running this compose file means I know every edge case and the few that will quietly break at 3 AM. That practical knowledge is worth more than any managed platform subscription.

The Docker Compose approach described in this article is not a solution for large-scale infrastructure — it is a solution for engineers and organizations who need reliable, maintainable, cost-effective hosting for real applications without the overhead of enterprise tooling. That covers more use cases than the Kubernetes-first community sometimes acknowledges.

For Saudi developers building their first self-hosted applications, for US and European small businesses that want control over their hosting without paying managed platform prices, and for infrastructure engineers who want a practical environment to develop container operations skills, Docker Compose on a bare VPS is the right starting point. It is simple enough to understand completely, powerful enough to run production workloads, and cheap enough that experimenting and making mistakes does not cost money. Those three properties make it the right tool for this stage of the infrastructure journey. Build it, break it, fix it, and document what you learned. The next step — whatever it is — will be better for having started here.

If you are a developer or infrastructure engineer in Saudi Arabia, the United States, or Europe and you want help setting up or optimizing a Docker Compose hosting environment — or if you are evaluating whether this approach suits your specific workload — this is exactly the kind of engagement I take on for clients remotely. The setup described in this article is repeatable and I have deployed variations of it for clients with blogs, e-commerce stores, internal APIs, and documentation platforms. The fundamentals transfer across all of them. What changes between engagements is primarily the application-specific configuration and the precise thresholds, the backup destination, and the monitoring thresholds — the structural approach, the nginx reverse proxy pattern, the Docker network isolation, and the backup-to-offsite strategy remain consistent because they solve the same underlying problems regardless of what application is running in the containers. That consistency is what makes the approach teachable, repeatable, and directly transferable to client environments at any scale.