Observability and alerting
Centralized, queryable metrics and logs (Prometheus, Grafana, Loki), dashboards that answer the question “is everything fine?”, and actionable, deliberately few alerts. This is the first project.
Why. The June 1st incident: two days of private services down, discovered by a lucky usage check. Being notified, without having to go look.
Systematic CI/CD for the infrastructure
I use GitLab CI professionally. The project is to apply it systematically to my own platform: reproducible deployments triggered by Git, no manual steps left.
Why. Every manual step is a chance to forget something, and the platform serves real clients.
Infrastructure as Code
Service configuration is already declarative (Compose, versioned files). The next step also describes the provisioning itself (Terraform, Ansible): a server must be able to rebuild from scratch without human memory.
Why. The day the server disappears, the rebuild should depend on Git alone. This is the direct complement of the backups project.
Proven backups
Extend the 3-2-1 strategy to the whole server (per-service dumps, rotation, off-site copy), then test restores regularly, with tooling, and measure a real recovery time.
Why. The tradeoff is acknowledged on the backups page: as long as restores are not exercised, the recovery time remains an estimate. This project turns it into a measurement.
Secrets tooling
Automated scanning of repositories and their history (gitleaks or similar) and pre-commit hooks. Auditing is a manual practice today.
Why. A manual audit found a committed key: the practice works, tooling will make it systematic.
Beyond the single server
A second node, then a multi-server topology: first for DNS resolution and critical services, then as a learning ground for a larger infrastructure.
Why. The June 19th provider outage: the single-server risk is understood and accepted at this scale; this project prepares what comes after.
Kubernetes and managed cloud
Orchestration (k3s first) and the primitives of a public cloud (AWS): in experimentation environments first, then by migrating real services from the platform.
Why. Speaking the language of teams that operate at larger scale, and giving the previous projects a common target: IaC, observability and multi-node are its prerequisites.
The method
Every piece ships to production on my own infrastructure, with the same requirements as the rest: declarative, versioned, documented configuration. Once in place, the project joins the detail pages of this site, with its own decision record.