Cloud Infrastructure & DevOps

We run our own infrastructure, and that's most of what qualifies us to run yours. Our production host carries dozens of containers: the backends and frontends for FanDesk, Mobile Master, Probe361, EnergyFile and this website, plus MongoDB, PostgreSQL, Redis, a Qdrant vector database and a full monitoring stack. We don't use Kubernetes for this, and for most companies our size or yours, we don't think you need it either. Docker Compose, a good reverse proxy and discipline around deploys and backups go a long way.

Who this is for

Companies that want their software on servers they control, whether that's a rented VM, a rack in their own building or a network with no internet access. Also teams whose current setup is "one server someone configured years ago": it works, nobody wants to touch it, and a restart means a few minutes of errors for users.

How we work

1. Review what runs today. Services, databases, where the secrets live, how deploys happen and what's backed up. Often the first finding is that the backups have never been restored.
2. Containerize. Each service gets a Dockerfile and a place in a Compose file, with health checks, memory limits and restart policies. Configuration moves into environment files that stay out of git.
3. Routing and TLS. Traefik sits in front, discovers containers through labels and handles certificates automatically. Behind Cloudflare where that makes sense.
4. Monitoring, logs and backups. Metrics and dashboards, container logs to one searchable place, uptime checks from outside, and nightly backups copied to a second machine.
5. Deploy scripts and handover. Scripted, repeatable deploys and a short runbook: how to deploy, how to roll back, how to restore.

The stack we actually use

Docker and Docker Compose for every service. Traefik as the reverse proxy, with Let's Encrypt certificates. Prometheus scrapes node-exporter and cAdvisor for host and per-container metrics, and Grafana shows them. Promtail ships container logs to Loki, which only works well if apps log to stdout, a lesson we wrote up after nginx logs went missing when we needed them. Uptime Kuma checks every public domain over HTTPS. CI runs on GitHub Actions, including a self-hosted runner that performs the weekly restore drill.

Examples from our own setup

Blue-green deploys. A plain docker compose up -d stops the old container before the new one is ready, and Traefik returns errors for those few seconds. Our deploy script starts the new container next to the old one, waits until its health check reports healthy (Traefik already sends it traffic by then), removes the old one and renames the new one into place. If the new container never gets healthy, it's removed and the old one keeps serving. Nothing breaks.

A server with no internet. One of our deployment targets has no internet or registry access, sitting behind a jump host. We build images on our side and stream them over SSH with docker save and docker load, then swap them with the same blue-green script. Probe361 and EnergyFile run there.

Backups that get restored. For Mobile Master, a nightly job dumps MongoDB, verifies the archive, copies it to another server and compares checksums on both ends. Once a week, CI restores the latest dump into a throwaway database and checks the collections and document counts. A backup nobody has restored is only a hope.

The same approach runs FanMail, a self-hosted email service built on Stalwart Mail Server.

Further reading

• Container logs belong on stdout, not in files
• The Docker setup behind our self-hosted CMS

Frequently asked questions

Do you use Kubernetes?

Not by default. For a handful of servers, Docker Compose with Traefik is simpler to run and easier to hand over. If you already run Kubernetes, or truly need multi-node scheduling, we'll talk about it, but we won't add it because it's fashionable.

Can you deploy to a server without internet access?

Yes, we already do. Images are built elsewhere and streamed over SSH, and base images are shipped the same way, so the target never needs a registry.

What does zero-downtime deployment mean in practice?

The new version starts alongside the old one, and the old one is only removed after the new one passes its health check. Users don't see errors during a normal deploy, and a failed deploy leaves the old version running.

Which cloud provider do you work with?

Any provider that gives you Linux VMs, or your own hardware. Our setup doesn't depend on managed services from a particular cloud, which makes moving between providers much easier.

How are backups tested?

By restoring them on a schedule into a throwaway database and checking what came back. If the drill fails, we find out that week, not on the day we need the backup.

Can you take over an existing server?

Yes. We usually start with a review and a backup we've verified, then containerize one service at a time so nothing has to go down all at once.