Home Infrastructure: Self-hosted on OVH VPS
Self-hosted infrastructure on OVH VPS: Traefik reverse proxy, Authelia authentication, Prometheus/Grafana/node_exporter monitoring, Dragonfly cache, Garage object storage, Redpanda/NATS messaging — Docker Compose deployment with external proxy network.
The Goal
Set up a personal infrastructure on an OVH VPS (Ubuntu), able to host multiple services with automatic TLS, centralized authentication, and full monitoring — all via Docker Compose. Beyond the network/auth/observability stack, the infra also includes data components inspired by managed cloud services (object storage, memory cache, message streaming), to experiment with these patterns outside of an AWS/GCP context.
Architecture
External proxy network
All services share an external Docker proxy network. Traefik is the only publicly exposed entry point. Internal services publish no ports directly — they communicate solely through this network.
networks:
proxy:
external: true
Traefik reverse proxy
Traefik handles TLS termination (Let’s Encrypt via DNS challenge) and routes traffic to services via Docker labels. Each container declares its own routing rule without touching the central config.
Authelia authentication
Authelia sits as an authentication middleware. Sensitive services (Grafana, Traefik dashboard) require a valid session with 2FA before passing the request.
Note: Authelia no longer fits my use case — it’s oriented toward web portals, and I need to be able to authenticate some services via API. Authentik would be a solid replacement.
Prometheus / Grafana monitoring
- node_exporter collects system metrics (CPU, RAM, disk, network)
- Prometheus scrapes targets every 15 seconds
- Grafana exposes real-time dashboards with alerting on critical thresholds
Dragonfly memory cache
Dragonfly replaces Redis as the application cache on the infra, serving as a cache layer for several services hosted on the VPS.
Garage object storage
Garage provides S3-compatible object storage, self-hosted. Setup and testing are done (buckets, access policies).
Redpanda & NATS messaging
Two message brokers coexist on the infra to explore different event streaming patterns:
- Redpanda (Kafka-compatible API) for durable event streaming and message replay
- NATS for lightweight pub/sub and low-latency request/reply messaging
Both are up and validated with demo messages. The goal is to make these services available for future projects and lab experiments :).
What I Learned
I ran into a range of real problems: secret management via out-of-repo .env files, inter-container network debugging, and alert tuning to cut the noise.
Dragonfly, Garage, Redpanda, and NATS were also a chance to understand by practice the patterns you find in managed cloud services (S3, ElastiCache, Kinesis/SQS): access policy configuration, protocol compatibility as a migration constraint. Having two brokers — one focused on durability/replay (Redpanda) and one focused on latency (NATS) — lets me compare the two philosophies hands-on.