Open Source DevOps Tools Every Small Team Should Know

TL;DR

#

Two things get conflated in every article with this title, and both of them cost money when you get them wrong.

“Open source” is not the same as “self-hosted.” Grafana Cloud runs AGPL Grafana. Amazon Managed Service for Prometheus runs Cortex, a CNCF project. Buying the hosted version of an open source tool is not a betrayal of anything — it is usually the correct answer for a 3–10 person team.

“Popular” is not the same as “open source.” Terraform and Vault have been under the Business Source License since August 2023. They are source-available, not OSI open source, and the licensor on both LICENSE files today reads “International Business Machines Corporation (IBM).” If your procurement paperwork, your investor diligence, or your own principles say “open source,” those two do not qualify. OpenTofu and OpenBao do.

Everything below was checked against upstream sources on 2026-08-07. Where I could not verify something, I say so instead of guessing.

Who this is for

#

Teams of roughly 3–10 engineers with no dedicated SRE, choosing a toolchain they will still be running in two years. You have enough scale that “just SSH in” has stopped working, and not enough people that anyone can own a tool full-time.

If you are looking for a shopping list, this is the wrong page. Every tool here is a commitment to an upgrade cadence, and the cadence is the part that bites.

What “open source” actually means in this stack right now

#

The DevOps toolchain has been through five years of licence churn, in both directions. You cannot reason about it from memory. Here is the current state, read off the LICENSE files.

Licences moved away from open source

#

On 10 August 2023, HashiCorp relicensed all its products — Terraform, Vault, Packer, Consul, Nomad, Waypoint, Boundary — from MPL 2.0 to the Business Source License 1.1. BUSL is not an OSI-approved licence. The Open Source Initiative does not recognise it, and neither do most “must be open source” policies.

The details matter more than the headline, and they are all in the LICENSE file:

Three practical consequences:

• The restriction is narrower than people assume. The Additional Use Grant permits production use; what it forbids is offering the work to third parties on a hosted or embedded basis in competition with IBM’s paid versions. If you are a 6-person team running terraform apply against your own AWS account, BUSL does not restrict you. If you are building a product that runs Terraform on your customers’ behalf, read the grant with a lawyer.
• Each release rots into MPL separately. Four years after publication, that specific version becomes MPL 2.0. Terraform 1.6.0 shipped in 2023, so it converts on its own schedule — but you will be many versions past it by then.
• The providers never left. hashicorp/terraform-provider-aws is still MPL 2.0. HashiCorp’s announcement said “APIs, SDKs, and almost all other libraries will remain MPL 2.0,” and that held. Only the CLI engines changed.

IBM closed its $6.4B acquisition of HashiCorp on 27 February 2025, which is why the licensor line now says IBM.

Licences moved toward open source

#

This is the half nobody writes about.

• Grafana, Loki and Tempo moved from Apache 2.0 to AGPLv3 on 20 April 2021. AGPLv3 is OSI-approved. Grafana did not stop being open source; it changed which open source licence it uses. grafana/grafana and grafana/loki both carry AGPL-3.0 today.
• Elasticsearch and Kibana added AGPLv3 as a licensing option in September 2024, after three years under SSPL and the Elastic License. They are open source again by the OSI definition.

The lesson is that “changed its licence” tells you nothing on its own. Apache → AGPL kept Grafana open source. MPL → BUSL did not keep Terraform open source. You have to read which licence, not just notice that one changed.

The forks that resulted

#

Neither is a stale mirror. OpenTofu shipped client-side state encryption in 1.7 (30 April 2024). Terraform has no equivalent in the CLI — with Terraform you rely on whatever at-rest encryption the backend provides (S3 SSE, for instance), which protects the bucket but not the state file as it passes through anything else. OpenTofu’s version is configured in the terraform block and covers both state and plan files:

terraform {
  encryption {
    key_provider "aws_kms" "primary" {
      kms_key_id = "alias/opentofu-state"
      region     = "eu-central-1"
      key_spec   = "AES_256"
    }

    method "aes_gcm" "default" {
      keys = key_provider.aws_kms.primary
    }

    state {
      method = method.aes_gcm.default
    }

    plan {
      method = method.aes_gcm.default
    }
  }
}

That is the difference between a fork and a mirror. If your state file contains database passwords — and it does, whether you meant it to or not — this is a real reason to switch that has nothing to do with licence politics.

The one operational difference worth knowing: OpenTofu runs its own registry at registry.opentofu.org, because HashiCorp closed the Terraform Registry to non-Terraform software. Coverage of the major providers (AWS, Azure, Google, Kubernetes) is there. A niche provider might not be — check before you migrate, not after.

The four questions that actually decide this

#

Skip “which tool is best.” Ask these instead.

1. What does an upgrade cost, and how often are you forced into one?

#

This is the single biggest hidden cost in an OSS stack, and it is knowable in advance because projects publish their support policies.

• Argo CD ships a minor release roughly every three months and patches only the three most recent minors. Everything older is EOL — no bug fixes, no security updates. With v3.5.0 out on 2026-08-04, that means 3.5, 3.4 and 3.3 are supported. In practice: you upgrade Argo CD about three times a year, forever, or you run something unpatched.
• Helm 4.0.0 landed 12 November 2025, the first major version in six years. Helm 3’s bug-fix window closed on 8 July 2026; security fixes run until 11 November 2026. If you are on Helm 3 as you read this, you have roughly three months of security patches left. That is not a future problem.
• OpenTelemetry Collector releases roughly every two weeks and is still on a 0.x version (v0.158.0 as of 2026-08-04). Under semver, 0.y.z explicitly promises nothing about stability. In practice the config surface is far more stable than that implies, but you are pinning versions and reading changelogs.
• kube-prometheus-stack, the Helm chart most small teams actually use for Prometheus, is on chart version 88.1.5 (app v0.93.0). Its README is blunt: “CRDs created by this chart are not updated by default and should be manually updated,” and “CRDs update lead to a major version bump.” Eighty-eight major versions means eighty-eight opportunities to have needed a manual kubectl apply of CRDs before helm upgrade.

Version numbers lie in both directions. Alertmanager has been in production at enormous scale for years and is on v0.33.1. The OTel Collector is on v0.158.0 and moves every fortnight. Prometheus took seven years to go 2.0 → 3.0. A leading zero tells you about the maintainers’ promises, not about whether the thing works.

2. What happens when it breaks at 3am?

#

The useful test is not “is it reliable” but “what is the blast radius and how do you get out.”

• Prometheus down — you lose visibility, not traffic. Recovery is restarting a process. Local TSDB data may be lost if the disk is gone; anything already shipped by remote_write survives. Acceptable failure.
• Argo CD down — running workloads keep running; you lose the ability to deploy and reconcile. Annoying, not an outage. You can kubectl apply manually to bridge.
• Vault or OpenBao down — this one can take production with it. Applications that fetch secrets at startup cannot start. Sealed instances need an unseal ceremony, at 3am, from people holding key shares. This is the single most consequential self-hosting decision in the list, and it is why most 3–10 person teams should not run it.
• Your log backend down — depends entirely on your collector’s buffering. Both the OTel Collector and Vector will buffer and retry; whether they buffer enough is a config question you should answer before the incident, not during it.

3. Who on your team fixes it — and who upstream fixes it?

#

Both halves matter, and the upstream half is checkable.

Projects lose their sponsors. Recent, verifiable examples:

• Flux: Weaveworks, which employed most of the maintainers, wound down commercial operations in early 2024. The project survived — ControlPlane hired maintainers, CNCF and other vendors stepped in, and Flux is a CNCF graduated project shipping regularly (v2.9.3, 2026-07-23). Good outcome, but it was genuinely uncertain for a few months.
• External Secrets Operator: maintainers announced in August 2025 that they were pausing all official releases — including security patches — until they could form a sustainable maintainer team. CNCF opened a project health review (cncf/toc#1819). The commercial company built around it wound down. Releases have since resumed: v2.8.0 shipped 2026-07-18 and the repo is active. It recovered, but a team that adopted it in July 2025 spent months without security patches.
• Grafana Agent: reached end of life on 1 November 2025. It was not abandoned — it was replaced by Grafana Alloy, Grafana’s Apache-2.0 distribution of the OpenTelemetry Collector. If you are still running Agent, you are running unsupported software and there is a documented migration path.
• Jaeger v1: end of life 31 December 2025. No new v1 binaries since 1 January 2026. Jaeger v2 (v2.20.0, 2026-07-20) is a different animal — it is built on the OpenTelemetry Collector framework rather than being a separate codebase.

None of these are reasons to avoid open source. They are reasons to check before adopting, and to check again yearly.

4. Does the hosted version of this exact project solve it better?

#

For most of the heavy components, yes. See below.

The shortlist, with what was verified

#

All checked 2026-08-07 via the GitHub API and upstream LICENSE files.

On Grafana’s AGPL: for the overwhelmingly common case — you run Grafana on your own infrastructure, your own engineers look at dashboards, you have not modified the source — AGPL imposes no practical obligation on you. It becomes a real question only if you embed Grafana into a product you offer to third parties, or you modify it and provide it over a network. That is a conversation with a lawyer, not with a blog post. Note that Grafana’s own hosted product and Amazon Managed Grafana exist precisely so you do not have to have that conversation.

Three tools you will see on other lists, and why they are not on this one

#

• BuildKit as a thing to adopt. BuildKit has been the default builder in Docker Engine since 23.0 (February 2023). docker build is an alias for docker buildx build. There is nothing to choose; you already have it. Recommending it in 2026 signals a list that has not been re-checked.
• Vector as a general recommendation. It is a good tool, MPL-licensed and actively maintained by Datadog. But for a team of 3–10 running Kubernetes, the OTel Collector or Alloy covers the same ground with one fewer config language to learn. Pick Vector when you have a specific transformation or throughput problem that VRL solves and OTel processors do not — not as a default.
• Jaeger as a standalone tracing recommendation. Jaeger v2 is an OpenTelemetry Collector distribution. Listing “OpenTelemetry” and “Jaeger” as two separate choices misrepresents what you are actually deciding, which is only “where do traces get stored and queried.”

Open source is not self-hosted: the config that proves it

#

This is the article’s central point and it collapses into six lines of YAML.

Here is a Prometheus scrape and remote-write config. The scrape half never changes. Only the destination does:

# prometheus.yml — the collection half is identical in all three cases
global:
  scrape_interval: 30s
  external_labels:
    cluster: prod-eu

scrape_configs:
  - job_name: kubernetes-pods
    kubernetes_sd_configs:
      - role: pod

remote_write:
  # Option A — self-hosted VictoriaMetrics (Apache 2.0, single binary)
  - url: http://victoriametrics.monitoring.svc:8428/api/v1/write

  # Option B — Amazon Managed Service for Prometheus (data plane is CNCF Cortex)
  - url: https://aps-workspaces.eu-central-1.amazonaws.com/workspaces/${WORKSPACE_ID}/api/v1/remote_write
    sigv4:
      region: eu-central-1
    queue_config:
      max_samples_per_send: 1000
      max_shards: 200
      capacity: 2500

  # Option C — Grafana Cloud (the backend is Mimir; Grafana itself is AGPL)
  - url: https://prometheus-prod-XX-prod-eu-west-0.grafana.net/api/prom/push
    basic_auth:
      username: ${GRAFANA_CLOUD_INSTANCE_ID}
      password: ${GRAFANA_CLOUD_ACCESS_TOKEN}

Every one of those three is open source software. Your instrumentation, your PromQL, your alert rules, your dashboards and your Grafana JSON are identical across all three. The only thing you are choosing is who runs the storage layer and who gets paged when it fills up.

That is why “we use open source, so we self-host” is a non-sequitur. And it is why the lock-in argument for self-hosting is weaker than it sounds — the portability lives in the protocol and the query language, both of which you keep either way.

The remote_write fields above (url, basic_auth.username, basic_auth.password, sigv4.region, queue_config.*) are from the Prometheus configuration reference; the AMP endpoint shape and sigv4 block are from AWS’s own onboarding docs.

Where hosted wins, with actual numbers

#

Prices checked 2026-08-07 on the vendors’ pricing pages. They change; re-check before you build a spreadsheet on them.

Grafana Cloud free tier: 10,000 active metric series, 50 GB logs, 50 GB traces, 14-day retention, 3 active users, community support only. Pro starts at a $19/month platform fee plus usage.

For a 3–10 person team with a handful of services, 10k active series and 50 GB of logs a month is genuinely a lot. Note the binding constraint is usually 3 users, not the data volume — a team of eight will outgrow the seat limit long before the series limit.

Amazon Managed Service for Prometheus: $0.90 per 10 million samples ingested (first 2 billion/month), $0.03 per GB-month storage, $0.10 per billion query samples processed. The data plane is Cortex, a CNCF project. There is an AWS Free Tier allowance, but AWS restructured its free tier in July 2025 around account age and credits — verify what applies to your account rather than assuming.

Amazon Managed Grafana: $9 per active editor/administrator per month, $5 per active viewer. For a team of eight with three editors, that is well under $50/month for something you would otherwise patch yourself.

Secrets, where the maths is most lopsided: AWS Systems Manager Parameter Store charges nothing for standard parameters, $0.05/parameter/month for advanced ones, and $0.05 per 10,000 API interactions only if you enable higher throughput. Secrets Manager is $0.40 per secret per month plus $0.05 per 10,000 API calls.

Run that against self-hosted Vault or OpenBao. Two hundred secrets in Secrets Manager is $80/month. Vault or OpenBao is free to download and then costs you: a highly-available deployment, a storage backend, TLS certificate rotation, an unseal procedure documented well enough that someone other than its author can execute it at 3am, an audit log destination, and an upgrade every few months. That is not $80/month of engineer time. It is not close.

Self-host secrets management only when you need something the managed service genuinely cannot do: dynamic database credentials with short TTLs, PKI issuance, transit encryption as a service, or a multi-cloud/on-prem footprint where no single provider’s service reaches everything. Those are real needs. “We should own our secrets” is not one, and neither is cost.

What I would actually run

#

For a 3–10 person team on managed Kubernetes:

• IaC: OpenTofu. It is OSI open source, it is a drop-in replacement, and state encryption is a real feature you do not otherwise get. If you are already deep in Terraform and BUSL genuinely does not restrict your use case, staying is defensible — just make the decision deliberately rather than by inertia.
• Packaging: Helm 4, or Kustomize if your charts are all first-party and you resent templating. Pick one. Running both is how you end up with two ways to change a replica count.
• GitOps: Argo CD if you want a UI your whole team will use; Flux if you want something smaller that lives entirely in git. Both are healthy. Budget for the Argo CD upgrade cadence.
• Metrics: Prometheus or Alloy for collection, and hosted storage unless you have a specific reason not to. If you do self-host storage, VictoriaMetrics is a single Apache-2.0 binary and is the least painful option in this category.
• Logs: one collector (OTel Collector or Alloy), one backend, and think hard before that backend is self-hosted. Full-text log search at scale is a job, not a deployment.
• Traces: skip until you have a latency mystery spanning three services. Then Jaeger v2 or your existing vendor’s OTLP endpoint — your instrumentation is already OTel either way.
• Secrets: cloud-native store (Parameter Store or Secrets Manager) plus External Secrets Operator to project them into Kubernetes. SOPS if you want encrypted secrets in git and nothing running. OpenBao only if you have a concrete need it uniquely fills.
• CI: whatever your git host provides. Self-hosting CI is the least rewarding infrastructure work available to a small team.

Check this yourself

#

Do not trust this page in six months. Verify in about ten seconds per tool:

# Licence, archive status, and last push
curl -s https://api.github.com/repos/opentofu/opentofu \
  | jq '{license: .license.spdx_id, archived, pushed_at}'

# Latest release and when it shipped
curl -s https://api.github.com/repos/opentofu/opentofu/releases/latest \
  | jq '{tag_name, published_at}'

# The licence text itself — the only authoritative answer
curl -s https://raw.githubusercontent.com/hashicorp/terraform/main/LICENSE | head -20

Two traps worth knowing. First, GitHub’s licence detector reports NOASSERTION for BUSL — that is exactly what hashicorp/terraform and hashicorp/vault return, so NOASSERTION should make you read the file rather than shrug. Second, /releases/latest returns whatever tag is newest, which is not always the product: vectordotdev/vector currently returns a vdev-* tag belonging to its internal build tool, not the v0.57.0 release you actually want.

What I could not verify

#

In the interest of not padding the confident parts:

• Argo CD v3.0.0’s exact release date. Secondary sources place it in the first half of 2025, but I could not confirm it against a primary source, so no date appears above. The support policy — three minors, quarterly — is documented, and it is the part that affects your upgrade planning anyway.
• Which kustomize version current kubectl bundles. The compatibility table in the kustomize README has not been updated past kubectl v1.27, so I cannot state the current mapping from a primary source. If it matters to you, run kubectl version and kustomize version and compare; assume they differ.
• Whether Amazon Managed Grafana runs stock AGPL Grafana or a modified build. AWS’s pricing and product pages do not say.
• The precise governance and funding arrangement behind External Secrets Operator after its commercial backer wound down. Releases are clearly flowing again; the durability of that is not something I can verify from the outside.

Questions people ask

#

Is Terraform still open source?

#

No, not by the OSI definition. HashiCorp relicensed Terraform from MPL 2.0 to the Business Source License 1.1 on 10 August 2023, and the LICENSE file on main today names IBM as licensor and covers “Terraform Version 1.6.0 or later.” BUSL is source-available: you can read, modify and use the code, including commercially, but you may not offer it to third parties on a hosted or embedded basis in competition with IBM’s paid products. Each version reverts to MPL 2.0 four years after publication. If you need OSI open source, OpenTofu is the MPL-2.0 fork and is a drop-in replacement.

Should we switch from Terraform to OpenTofu?

#

Switch if “open source” is a requirement rather than a preference, if your product runs IaC on customers’ behalf in a way the BUSL Additional Use Grant might touch, or if you want state encryption — which OpenTofu has shipped since 1.7 in April 2024 and Terraform still does not offer natively. Stay if you are deep in Terraform Cloud/HCP workflows, or if you depend on a provider that is not mirrored in registry.opentofu.org. Check the registry coverage for your specific providers before you migrate, not after. Either way, make it a decision rather than a default, because “we didn’t notice the licence changed” is not a position you want to defend in a diligence call.

Does Grafana’s AGPL licence mean we cannot use it?

#

Almost certainly not. Grafana, Loki and Tempo moved from Apache 2.0 to AGPLv3 in April 2021, and AGPLv3 is an OSI-approved open source licence — the move did not take Grafana out of open source, unlike HashiCorp’s move to BUSL. If you run Grafana on your own infrastructure, for your own engineers, without modifying the source, AGPL asks nothing of you in practice. It becomes a genuine legal question only if you modify Grafana and provide it to third parties over a network, or embed it in a product you sell, in which case you need a lawyer rather than a blog post.

Is self-hosting Prometheus cheaper than Amazon Managed Prometheus or Grafana Cloud?

#

Only if your engineers’ time is free. Grafana Cloud’s free tier covers 10,000 active series, 50 GB of logs and 14-day retention with three users, which is more than many teams of this size actually generate — and the binding limit is usually the three-user cap, not the data. Amazon Managed Service for Prometheus charges $0.90 per 10 million samples ingested and $0.03 per GB-month of storage, and its data plane is Cortex, a CNCF open source project. Self-hosting means you own TSDB disk sizing, retention, compaction, upgrades and the pager when the volume fills — and both hosted options are still open source, so choosing them costs you nothing in portability.

How do I check whether a tool on a list like this is still maintained?

#

Query the GitHub API rather than trusting star counts or blog posts: curl -s https://api.github.com/repos/OWNER/REPO | jq '{license: .license.spdx_id, archived, pushed_at}' gives you licence, archive status and last activity, and /releases/latest gives you the last shipped version and date. Watch for three specific signals: a repo that is pushed daily but has not tagged a release in six months, a NOASSERTION licence field which usually means a non-standard licence like BUSL that you need to read yourself, and a CNCF project health issue against the project. The recent history is full of cases that only this kind of check would catch — External Secrets Operator paused all releases including security patches for part of 2025, Grafana Agent reached end of life in November 2025 in favour of Alloy, and Jaeger v1 stopped shipping binaries in January 2026.

We already run Helm 3. Is that a problem?

#

Yes, on a clock. Helm 4.0.0 shipped on 12 November 2025, Helm 3’s bug-fix support ended on 8 July 2026, and its security-fix support ends on 11 November 2026 — after which Helm 3 receives nothing. The Helm project is still cutting parallel v3 and v4 patch releases on the same days, so you are not being rushed off a cliff, but you should be scheduling the migration now rather than discovering the deadline in November. Helm 4’s changes are mostly additive — server-side apply, a redesigned plugin system, content-based chart caching — so this is a less painful major upgrade than the 2 → 3 transition was.

Related reads

#

• Minimal DevOps Stack for a Small Startup — what to run before you need any of this
• Terraform for Small Teams: IaC Without the Overhead — the workflow side of the IaC decision
• Secrets Management for Small Teams — the Vault-vs-managed decision in depth
• SaaS vs Self-Hosted Monitoring — the cost model behind the hosted recommendation
• Observability on a Budget — what to instrument before you pay for storage
• GitOps with Argo CD for Small Teams — whether you need GitOps at all
• Kubernetes Monitoring Stack: Prometheus + Grafana + Loki — the self-hosted version, assembled
• Production Readiness Checklist — what has to be true before any of this goes live