GitOps pipeline sovereignty
Every SaaS CI/CD service is a dependency you can't control, a billing surface you can't predict, and a trust boundary you can't verify. After running a fully self-hosted pipeline in production, I'm convinced that pipeline sovereignty isn't just an ideological choice — it's an operational advantage.
The entire software delivery chain runs on owned infrastructure. Source control, CI/CD runners, container registry, artifact storage, deployment automation — none of it touches a third-party service. An outage at a hosted git provider doesn't affect deployments. A registry rate limit doesn't block builds. A pricing change at some other company doesn't force an architecture change here. This isn't about distrust of cloud providers; it's about eliminating variables. When a deployment fails, the entire stack is observable — logs, metrics, network traces, all in infrastructure I control. There's no "contact support and wait" step in the incident-response playbook.
The pipeline is two-stage by design. Stage one triggers on push to the main branch: lint, test, build the container image, push to the private registry with cache layers that keep a code-only change rebuilding in seconds rather than minutes. Stage two triggers on the daemon's own pull: fetch the exact built image, recreate containers with a health-gated rollout, prune old images. Production servers are stateless. They hold no source code, no build tools, no development dependencies. Replacing a server is a three-step process: provision, configure the container runtime, point it at the registry.
What I gave up is convenience. Hosted pipelines handle runner provisioning, secret-management UIs, and marketplace integrations. Self-hosted means maintaining runners, managing secrets through explicit configuration, and building integrations from scratch. But the trade-off sharpens focus: every integration is intentional, every secret has a known location, every runner has a known resource profile. There's no sprawl of marketplace actions with unknown security postures executing code in the build environment.
The infrastructure cost of running the pipeline is marginal — it shares compute with other workloads. The human cost is real but bounded: initial setup took a weekend, and maintenance runs to roughly an hour a month — runner updates, registry cleanup, certificate rotation. Compare that to a subscription that scales with usage and a vendor relationship that needs contract negotiation for the features that actually matter. For a small team or a solo engineer running multiple products, pipeline sovereignty pays for itself in the first quarter. The breakeven isn't only financial — it's operational. Running everything on infrastructure you control teaches you the system at a depth no managed service can hand you.
← all logs