Complete Open Source DevOps Stack 2026

You can build an enterprise-grade DevOps platform entirely with open source software. No vendor lock-in, full auditability, and in many cases better capabilities than the equivalent paid SaaS. Here's the definitive guide to every layer.

TL;DR

CI/CD: Gitea Actions or Woodpecker CI for self-hosted pipelines; Jenkins for legacy enterprise
Container orchestration: Kubernetes (k3s for smaller deployments, full k8s for scale)
Observability: Prometheus + Grafana + Loki + OpenTelemetry
Secrets: OpenBao (Vault fork) or Infisical
IaC: OpenTofu (Terraform fork) + Ansible or Pulumi
Registry: Harbor for container images, Gitea/Forgejo for packages
Platform: Coolify or Dokploy for PaaS-style deployment over Kubernetes/Docker
The full stack runs on 3-10 servers and costs $200-$1,000/month for infrastructure, versus $10,000+/month for equivalent SaaS.

Key Takeaways

Every layer of the DevOps toolchain has a high-quality open source alternative.
HashiCorp's 2023 BSL relicensing of Terraform, Vault, Consul, and Nomad triggered robust open source forks (OpenTofu, OpenBao) that have matured rapidly.
Kubernetes remains the right choice for serious container orchestration, but k3s dramatically reduces operational overhead.
OpenTelemetry is now the standard for instrumentation—use it to avoid vendor lock-in at the telemetry layer.
Self-hosted DevOps requires operational investment but eliminates per-seat costs that compound significantly at scale.

Source Control

The foundation of everything.

Gitea / Forgejo

Forgejo is the community fork of Gitea, created after concerns about Gitea's governance. Both are fully open source Git hosts with GitHub-like interfaces.

Key features:

Git hosting with web UI
Pull requests with code review
Issues and project management
Actions (GitHub Actions-compatible CI/CD)
Package registry (npm, Docker, PyPI, Maven, and more)
Webhooks, API
LDAP/SSO integration

When to use: You want a self-hosted GitHub. Forgejo is the choice if community governance matters; Gitea if you want the upstream with commercial support options.

GitLab CE

GitLab Community Edition is the most feature-complete self-hosted Git platform:

Full CI/CD (GitLab CI/CD)
Container registry
Issue tracking, wiki, project management
Merge request approvals
Security scanning (SAST, DAST in EE but some available in CE)

When to use: You want everything in one platform and are willing to accept the operational overhead of running GitLab (it's resource-intensive).

For a detailed comparison, see our Gitea vs GitHub self-hosted guide.

CI/CD

Gitea Actions / Forgejo Actions

If you're using Gitea or Forgejo for source control, Actions is the natural CI/CD choice. It's compatible with GitHub Actions syntax, which means your existing workflows often work without modification.

# .gitea/workflows/ci.yml
name: CI
on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm test

Runners can be self-hosted (Docker or bare metal) or use Forgejo's hosted runners.

Woodpecker CI

Woodpecker is a lightweight, container-native CI system forked from Drone. It's YAML-based and runs pipelines in Docker containers.

# .woodpecker.yml
steps:
  test:
    image: node:20
    commands:
      - npm ci
      - npm test
  build:
    image: node:20
    commands:
      - npm run build
    depends_on: [test]

When to use: You want simplicity and don't need the full GitHub Actions ecosystem compatibility. Woodpecker is lighter than GitLab CI and easier to operate than Jenkins.

Jenkins

Still the most widely deployed CI/CD system in enterprise environments. Highly extensible, with thousands of plugins.

Pros: Maximum flexibility, runs anything, enormous plugin ecosystem Cons: Operational overhead, security patching burden, Groovy DSL can become complex

Use Jenkins if you have existing Jenkins expertise and complex custom requirements. For greenfield setups, Forgejo Actions or Woodpecker is lower overhead.

Tekton

Cloud-native CI/CD on Kubernetes. Tekton defines pipelines as Kubernetes CRDs, making CI/CD native to your cluster.

When to use: You're heavily invested in Kubernetes and want CI/CD that's natively Kubernetes-aware.

Container Orchestration

Kubernetes

The standard for production container orchestration. Kubernetes provides:

Declarative workload management
Self-healing (restarts failed pods)
Horizontal auto-scaling
Rolling deployments and rollbacks
Service discovery and load balancing
Persistent storage management
RBAC

Distributions for self-hosting:

k3s: Lightweight Kubernetes from Rancher/SUSE. Single binary, minimal resource requirements. Ideal for edge, homelabs, and small production clusters. Includes Traefik ingress and ServiceLB by default.

k0s: Another minimal Kubernetes distribution. Binary-only, no dependencies, easier air-gap support.

Talos Linux: OS designed specifically for running Kubernetes. Immutable, API-driven, no SSH.

Full k8s with kubeadm: For clusters that need standard upstream Kubernetes without distribution-specific choices.

Choosing the right orchestration layer is one of the most consequential decisions in a self-hosted DevOps stack. Docker Compose is appropriate for a single server, Docker Swarm for a handful of nodes with simple requirements, and Kubernetes when you need full declarative orchestration with autoscaling and robust self-healing. For a detailed analysis of the trade-offs between these options at each scale, see our Docker Swarm vs Kubernetes orchestration guide for self-hosting.

Helm

The package manager for Kubernetes. Deploy complex applications with a single command:

helm install grafana grafana/grafana --namespace monitoring

Helm charts exist for virtually every major open source application. Running Grafana, Prometheus, and Loki on Kubernetes is a helm install away.

Platform Layers

For teams that want Kubernetes capabilities without managing raw Kubernetes:

Coolify: Modern open source PaaS. Deploys applications from Git repos, Docker images, or Docker Compose. Handles SSL, domains, and backups automatically. Runs on a single server or cluster.

Dokploy: Alternative PaaS with focus on simplicity. Similar capabilities to Coolify with slightly different UX trade-offs.

See our Coolify vs Caprover vs Dokploy comparison for detailed evaluation.

Infrastructure as Code

OpenTofu

OpenTofu is the Linux Foundation fork of Terraform, created after HashiCorp relicensed Terraform to BSL in 2023. It maintains full compatibility with existing Terraform configurations.

# main.tf
terraform {
  required_providers {
    hcloud = {
      source = "hetznercloud/hcloud"
    }
  }
}

resource "hcloud_server" "web" {
  name        = "web-01"
  image       = "ubuntu-22.04"
  server_type = "cx21"
  location    = "nbg1"
}

Drop-in replacement for Terraform in most cases. State files are compatible. Provider ecosystem is identical (the same providers work with both).

Ansible

Ansible manages configuration across servers using SSH and YAML playbooks. No agent required on managed hosts.

# playbook.yml
- hosts: webservers
  tasks:
    - name: Install nginx
      apt:
        name: nginx
        state: present
    - name: Copy config
      template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf
      notify: Restart nginx
  handlers:
    - name: Restart nginx
      service:
        name: nginx
        state: restarted

Ansible and OpenTofu complement each other: OpenTofu provisions infrastructure (VMs, networks, DNS), Ansible configures what runs on that infrastructure.

Pulumi

Pulumi takes the Infrastructure as Code approach but lets you write infrastructure in real programming languages (TypeScript, Python, Go, Java, C#).

import * as hcloud from "@pulumi/hcloud";

const server = new hcloud.Server("web-01", {
  image: "ubuntu-22.04",
  serverType: "cx21",
  location: "nbg1",
});

When to use: Your team is more comfortable with general-purpose programming languages than HCL, or you need complex conditional logic that HCL makes awkward.

Observability

Prometheus + Grafana + Loki

The standard open source observability stack:

Prometheus: Metrics collection and storage. Time-series database. Scrapes metrics from applications (via /metrics endpoint) and infrastructure. Alertmanager handles alerting.

Grafana: Visualization layer. Connects to Prometheus (metrics), Loki (logs), Tempo (traces), and dozens of other data sources. Build dashboards for anything.

Loki: Log aggregation. "Prometheus for logs"—uses the same label-based query model. Significantly cheaper to operate than Elasticsearch for log storage because it doesn't index log content.

OpenTelemetry (OTel): Standard instrumentation protocol for traces, metrics, and logs. Instrument your application once with OTel and export to any backend (Grafana, Jaeger, Datadog, etc.). This is the most important architectural decision for long-term observability flexibility.

Tempo: Distributed tracing backend from Grafana, designed to work with Loki and Prometheus. Stores traces cheaply and integrates natively with Grafana dashboards.

Alerting

Alertmanager (Prometheus): Routes alerts to email, Slack, PagerDuty, or any webhook.

Grafana Alerting: Build alerts directly in Grafana dashboards and route through Alertmanager or native notification channels.

Secrets Management

OpenBao

OpenBao is the Linux Foundation fork of HashiCorp Vault, created after Vault's BSL relicensing. It provides:

Dynamic secrets (generate credentials on demand, auto-expire)
Encryption as a service
PKI and certificate management
Kubernetes integration (inject secrets as environment variables or files)
Audit logging

# Store a secret
vault kv put secret/myapp/config db_password=supersecret

# Read a secret
vault kv get secret/myapp/config

Infisical

Modern secrets manager with self-hosted option. Developer-friendly UX, Kubernetes operator, environment sync, and audit log.

When to use: You want a modern secrets manager UI and developer workflow without the operational complexity of OpenBao. Infisical is easier to set up for smaller teams.

External Secrets Operator

Kubernetes-native secrets management. Connects to external secret stores (OpenBao, AWS Secrets Manager, etc.) and syncs secrets into Kubernetes Secrets automatically.

Container Registry

Harbor

Enterprise-grade container registry. Features:

OCI artifact storage
Vulnerability scanning (Trivy integration)
RBAC
Replication to/from other registries
Content trust and signing
Quota management

docker push harbor.yourcompany.com/project/image:tag

Gitea/Forgejo Package Registry

If you're already using Gitea/Forgejo, its built-in package registry supports Docker images alongside npm, PyPI, Maven, and other package formats. Lower operational overhead than running a separate Harbor instance.

Putting It Together

Starter Stack (1-5 engineers, single server)

Layer	Tool	Notes
Source control	Forgejo	Single server, Docker
CI/CD	Forgejo Actions	Built-in
Deployment	Coolify	Single-node PaaS
Observability	Beszel + Grafana	Lightweight server monitoring
Secrets	Infisical	Managed service or self-hosted

Production Stack (5-50 engineers, multi-server)

Layer	Tool	Notes
Source control	GitLab CE or Forgejo	Dedicated server
CI/CD	GitLab CI or Woodpecker	Self-hosted runners
Orchestration	k3s cluster	3-node HA
Observability	Prometheus + Grafana + Loki	Kubernetes deployment
Secrets	OpenBao	HA cluster
IaC	OpenTofu + Ansible	GitOps workflow
Registry	Harbor	Kubernetes deployment

Enterprise Stack (50+ engineers, multi-region)

The production stack above, plus:

Full Kubernetes (not k3s) with multi-zone HA
Cilium for CNI and network policy
Velero for backup/disaster recovery
Crossplane for infrastructure management via Kubernetes
Tekton for Kubernetes-native CI/CD
Policy enforcement: OPA/Kyverno

The automated backup tools built around Restic and Rclone should be part of any self-hosted DevOps stack for data protection across all layers. And for teams that want to automate repetitive operational tasks — deploying on a schedule, running database maintenance, triggering workflows from webhooks — see the best open source automation tools for 2026, which covers n8n, Windmill, Activepieces, and Temporal as alternatives to commercial workflow platforms.

Total Cost Comparison: OSS DevOps vs SaaS Equivalents

One of the strongest arguments for self-hosting your DevOps stack is the economics at scale. The SaaS DevOps market is structured to extract maximum value from growing teams — per-seat pricing compounds as you hire, usage-based pricing penalizes success, and enterprise tier gating puts the most useful features behind expensive contracts.

Here's a realistic comparison for a team of 25 engineers running a production application:

Layer	SaaS Option	SaaS Monthly Cost	OSS Alternative	Self-Hosted Cost
CI/CD	GitHub Actions (heavy usage)	~$400-600	Forgejo Actions (self-hosted runners)	$50 infra
Monitoring	Datadog (25 hosts, logs)	~$2,000-3,000	Prometheus + Grafana + Loki	$0 software
Secrets	AWS Secrets Manager + Vault Enterprise	~$300-500	OpenBao (self-hosted)	$0 software
Container Registry	Docker Hub Team	~$100	Harbor (self-hosted)	$0 software
IaC	Terraform Cloud Business	~$1,000	OpenTofu (self-hosted)	$0 software
Artifact Management	JFrog Artifactory Cloud	~$500	Gitea/Forgejo packages	$0 software

SaaS total: approximately $4,300-5,700/month for a 25-engineer team, not including compute costs.

The self-hosted alternative runs on roughly 5-8 dedicated servers or VMs costing $300-600/month total at Hetzner, OVH, or equivalent. The software cost is $0 for all the open source components. Total: $300-600/month — a 7-10x cost reduction.

The hidden cost is operational: you need an engineer who understands Kubernetes, Prometheus, and the rest of the stack. For most teams with a dedicated platform engineer or SRE, this is already a job requirement. The operational overhead of running a well-documented open source DevOps stack on Kubernetes is not substantially higher than managing SaaS billing, API keys, and integration configuration across a dozen vendors.

The break-even calculation changes depending on your team size and usage patterns. For small teams (under 10 engineers), SaaS may genuinely be more economical when you factor in the opportunity cost of platform engineering time. For teams above 15-20 engineers with sustained CI/CD usage, the open source stack almost always wins on total cost of ownership. Our detailed analysis of when self-hosting becomes cheaper than SaaS walks through this math more rigorously.

The other factor is vendor lock-in. When your CI/CD, observability, secrets, and registry are all on different SaaS vendors, you accumulate integration dependencies, data format dependencies, and contract renewal pressure across every layer. An open source stack built on standard protocols (OTel for telemetry, OCI for containers, S3 for artifacts) is portable. If a vendor raises prices, changes terms, or shuts down, you can migrate. With SaaS lock-in at every layer, you're negotiating from a much weaker position.

Methodology

Technology selections are based on community adoption metrics (GitHub stars, CNCF landscape data, Stack Overflow surveys), production deployment case studies, and analysis of licensing changes following the 2023 HashiCorp BSL transition. Stack recommendations reflect configurations seen in real-world enterprise and scale-up deployments across EU and US organizations as of early 2026. Cost comparisons use publicly available cloud provider and SaaS pricing.

The SaaS-to-Self-Hosted Migration Guide (Free PDF)