cert-manager
GraduatedProvisioning & Securitycert-manager automates X.509 certificate management inside Kubernetes.
What it is
cert-manager automates X.509 certificate management inside Kubernetes. It watches Certificate, Issuer, and ClusterIssuer custom resources and handles the full lifecycle: requesting certs from a CA, renewing them before expiry, storing them as Kubernetes Secrets, and rotating them into your workloads. It supports ACME (Let's Encrypt and others), HashiCorp Vault, private PKI via CertificateAuthority issuers, and integrates with cloud KMS/HSM-backed CAs through extensible issuer plugins.
If you're manually running certbot cron jobs and copying PEM files into Secrets, this replaces that with a controller loop that treats certs as declarative, reconciled state — the same model as everything else in Kubernetes.
Who builds it and why
Originally built by Jetstack (acquired by Venafi, later part of CyberArk), cert-manager became a CNCF project and reached Graduated status — CNCF's highest maturity tier, reserved for projects with proven adoption, security processes, and governance maturity. It's now steered by a broad maintainer group, not a single vendor, though Venafi/CyberArk engineers remain heavily involved. 568 contributors and an active commit history (latest release v1.20.3) indicate this isn't a project coasting on past momentum — it's still absorbing new issuer integrations and Kubernetes API changes.
Production readiness signal
- CNCF Graduated: passed the bar for security audits, adoption evidence, and multi-vendor governance.
- 13.9k GitHub stars, 568 contributors: large enough contributor base that bus-factor risk is low.
- Active release cadence: v1.20.x line with recent commits shows it's tracking current Kubernetes APIs, not stuck on deprecated versions.
- Apache-2.0: no licensing surprises, safe for commercial use without legal review overhead.
- De facto standard: if you're running ingress-nginx, Istio, or any cloud-native TLS termination, you've likely already encountered cert-manager as a dependency in someone else's Helm chart.
This is infrastructure-critical software running in production across a huge share of the CNCF ecosystem. The risk profile here is closer to "well-understood dependency" than "bet on emerging tech."
Who should use this
- Teams running Kubernetes who need automated TLS for ingress, service mesh mTLS, or internal service-to-service certs.
- Anyone using Let's Encrypt in-cluster and tired of manual renewal scripts.
- Platform teams building internal PKI who want a private CA integrated with Vault or a KMS-backed root.
- Organizations already standardized on CRDs/controllers as the pattern for infra automation — cert-manager fits that model natively.
Who should NOT use this
- Non-Kubernetes environments. cert-manager is a Kubernetes controller. If you're managing certs for VMs, bare metal fleets, or non-k8s workloads, look at Vault PKI directly, or your cloud provider's certificate manager.
- Simple single-domain setups with no rotation complexity. If you have one cert renewed twice a year via a cloud load balancer's built-in TLS (ALB/ACM, GCP-managed certs), adding cert-manager is unnecessary operational surface area.
- Teams unwilling to own another controller. cert-manager has had real-world outage incidents tied to issuer misconfiguration, rate-limiting against Let's Encrypt, and webhook failures blocking cert renewal cluster-wide. It needs monitoring and on-call familiarity like any other critical controller — it is not "install and forget."
- Extremely resource-constrained clusters. Its webhook, CA injector, and controller pods add baseline overhead that may not be justified for tiny edge/IoT clusters with few certs.
Alternatives
- Vault PKI secrets engine — better fit if you need cert issuance outside Kubernetes too, or want a single PKI control plane across VMs and containers.
- Cloud-native managed certs (AWS ACM, GCP-managed certificates) — simpler if you're fully committed to a cloud load balancer and don't need custom/private CAs.
- smallstep/certificates (step-ca) — lighter-weight private CA option, often paired with cert-manager as the issuer backend rather than a replacement.
Pricing
Fully open source, Apache-2.0. No paid tier, no enterprise fork. Commercial support is available separately through Venafi/CyberArk if you want an SLA, but the software itself has no license gate.