step-ca Alternatives: When the Free CA Stops Being Cheap to Run

step-ca earns its adoption honestly: it is the fastest route from zero to a working ACME CA, and for a platform team issuing short-lived certificates to Kubernetes workloads it is frequently the correct choice — full stop. The licence costs nothing; the deployment is paid for in engineer time, and at the design centre that bill is genuinely small. The alternatives question arrives when the bill grows, and almost always at one of four specific walls: high availability, active revocation, CA key custody, or multi-team governance. Each wall is a place where operating cost appears — a database and failover story, a revocation plane, an audit finding, a queue of teams — and "best step-ca alternative" has a different answer depending on which cost you are actually paying. One of the honest answers is "keep step-ca and fix the root above it," which is also the cheapest.

AxelSpire's position: step-ca's philosophy — short-lived certificates, passive revocation, a single lightweight server — is coherent and correct for its design centre, and at that design centre it is close to the cheapest possible CA to operate. The cost curve breaks when the deployment quietly leaves that centre: certificates get longer-lived, relying parties start asking for real-time revocation status, three more teams want in, and an auditor asks where the CA key lives. Each of those converts "free software" into engineer hours. The wrong response is resenting the tool; the right one is recognising the estate changed class — and re-costing accordingly.

Inclusion criteria: private CA options a platform or security team can realistically move to from step-ca, with ACME as a first-class enrolment path. Names that appear on aggregator "alternatives" lists but belong to different categories are covered separately below. AxelSpire's 3AM Mint is included and gets the same treatment as everything else, including its disqualifiers.

The four walls, precisely — and what each one costs

Smallstep's own documentation is admirably candid about the design boundary: a single configured issuing intermediate (multiple issuing CAs are not supported), an always-offline root (no single-tier option), and passive revocation as the model — with an explicit pointer to the commercial platform when a use case demands more. The four walls below are what that boundary looks like from inside a growing deployment.

1. HA and state. step-ca is a single long-running server; production HA means an active/standby or load-balanced pair over a shared MySQL or PostgreSQL backend — workable, but now you operate a database, backups and a failover story for a component whose outage stops issuance. That is a standing operational cost bolted onto free software. With ACME TTLs measured in hours, "CA briefly down" and "estate-wide expiry event" are separated by exactly your renewal-window margin.
2. Revocation posture. step-ca's model is passive revocation: keep TTLs short, let compromise age out; database-backed revocation is enforced at renewal, and CRL support exists but is not the design centre. Perfectly sound — until a relying party (a partner, an auditor, a device-fleet verifier) requires standards-based real-time status, at which point the choice is building and operating an OCSP plane yourself or moving the requirement to a CA that ships one. OCSP demand is the single most common step-ca exit trigger AxelSpire sees in device-identity contexts.
3. Key custody. step-ca supports KMS/HSM-held keys (PKCS#11, cloud KMS) — credit where due, this is better than most lightweight CAs. The custody question at exit is usually about the root above step-ca and the operational surface around a self-run signing server — and its cost is denominated in audit findings and the remediation projects that follow them, not in downtime. The general problem set is the same one covered for Vault: root of trust custody.
4. Multi-team governance. One binary, one config, one blast radius. Provisioners give you issuance policy per team; they do not give you per-team operational isolation, delegated administration, estate-wide inventory or policy reporting. At roughly the third team, the CA stops being a platform component and starts being an organisational service — a different job, with a service owner's cost structure: request queues, change control, and one team's engineer time subsidising everyone else's certificates.

What "free" costs to run

The running-cost comparison, since it decides more of these exits than any feature matrix: step-ca is paid for in engineer time — small at the design centre, then step-changed by the HA database, the revocation plane and the governance queue. EJBCA is also free at the Community tier and is the opposite cost profile: a Java application-server cluster with a database, resource-heavy from day one, plus a support subscription in practice at enterprise. Vault PKI is free only if you ignore the cluster it rides on and the Enterprise licence that gates HSM-held keys and namespaces. AWS Private CA is the only list-priced option — $400/CA/month (or $50 in short-lived mode) plus per-certificate tiers — which makes it the useful arithmetic anchor: if your honest engineer-time bill for running step-ca properly exceeds that, "free" has stopped being free. 3AM Mint's model is serverless in your own account — no server care at all; the footprint is AWS usage plus licence with the AWS cost at around $400-500 / months without AWS discounts. The estate-wide version of this comparison, including compliance-evidence costs, lives on the private CA platform comparison.

The five alternatives

1. 3AM Mint — the serverless answer to the server problem

The architectural contrast is direct, because Mint was designed against exactly the bring-your-own-server CA model step-ca represents. 3AM Mint deploys a complete CA estate in your own AWS account, as code: the CA logic is Lambda — there is no long-running CA server to operate, patch or fail over — every signature is an AWS KMS operation, so no signing key ever exists on disk or in process memory, and state is S3. That deletes walls 1 and 3 as cost lines rather than transferring them: no HA database, no failover runbook, and custody that answers the auditor's question by construction instead of by remediation project. Revocation is first-class, not philosophical: CRL publication plus a dedicated OCSP responder plane, which directly answers the wall-2 exit trigger. Enrolment is ACME plus a CSR-in/cert-out API, so cert-manager and existing ACME clients carry over with an endpoint change. Generation rollover and cross-signing are built in, and the platform ships with a TLS-discovery agent (at3am) feeding an estate inventory — the governance layer step-ca deliberately does not attempt, and the raw material for audit evidence that otherwise gets assembled by hand every year. Because the whole footprint is code-provisioned inside your account, the data-sovereignty property is the same one that made you choose self-hosted step-ca over a SaaS CA in the first place — without the server.

There is also the non-exit path: Mint issues subordinate CA certificates, so a team happy with step-ca's issuance ergonomics can anchor it to Mint's KMS-held root — custody and DR fixed, day-to-day tooling untouched, no migration project on anyone's roadmap. For deployments that hit wall 3 only, this is usually the cheaper correct answer, and we would rather say so here than in a post-mortem.

The honest row: AWS-only by design — on-prem, air-gapped or multi-cloud CA placement disqualifies it. If your entire need is one team's Kubernetes certificates with short TTLs and no revocation requirement, Mint is more platform than you need and step-ca remains the right tool. Regimes demanding single-tenant dedicated HSMs (eIDAS QSCD, PCI PIN) sit outside KMS custody.

2. Smallstep commercial — Certificate Manager and Step CA Pro

The vendor's own answer now comes in two shapes, and they price differently against the walls. Smallstep Certificate Manager is the hosted service: step-ca's model with someone else's pager — smallest migration delta on this list, at the cost of issuance metadata transiting vendor infrastructure (the sovereignty property is gone) and per-endpoint pricing. Step CA Pro is positioned as a drop-in replacement for the open-source binary: CA and root signing keys stay under your control, with a cloud-based management interface and compliance features layered on. Pro changes the sovereignty calculus this page previously stated flatly: keys local, management plane vendor-cloud — a hybrid worth evaluating precisely if wall 1 is your only wall and you want to keep the ergonomics. Across both shapes, walls 2 and 4 are only partially addressed, and the cost model converts engineer time into subscription — run that arithmetic at your endpoint count, because per-endpoint pricing compounds exactly as the estate grows.

3. HashiCorp Vault PKI — consolidation play, not an upgrade

If Vault already runs your secrets, folding PKI into it consolidates operations and policy language — one cluster, one policy grammar, one on-call rota, which is a real operating-cost argument. Understand what you are trading into: active-node write ceilings, Enterprise gating on HSM-held keys and namespaces (a licence line where step-ca had none), and root custody defaults that reproduce wall 3 in new clothing. Moving from step-ca to Vault solely for the CA is trading one self-operated server for a heavier one — the full assessment is blunt about when that is irrational.

4. AWS Private CA — managed, list-priced, narrow

Deletes walls 1 and 3 outright: managed HA, HSM-backed keys, $400/CA/month (or $50 short-lived mode) plus per-certificate tiers. The fit test is volume economics and protocol needs — per-cert pricing punishes exactly the high-churn short-TTL pattern step-ca shops tend to have, so run the arithmetic at your actual issuance rate before assuming "managed" means "cheaper": AWS PCA analysis. (GCP estates: Google CA Service is the same trade with the same fit test, and the reason it is not a row here is only that this page's exits are AWS-weighted — the arithmetic transfers.)

5. EJBCA — the enterprise-governance destination

The answer to wall 4 at organisational scale: delegated administration, protocol breadth (EST, CMP, SCEP alongside ACME), audit lineage. It is also the largest step-change in operational weight on this list — a Java application-server cluster with a database, resource-heavy from the first node, is the opposite cost profile to what a step-ca shop signed up for, and enterprise practice adds a support subscription to the "free" Community tier — which is why the EJBCA-and-its-alternatives analysis exists as this page's mirror image.

Decision table

Names on alternatives lists that solve a different problem

Aggregator "step-ca alternatives" lists mix in tools from adjacent categories; each removes a different cost, none is a like-for-like exit. xca and raw OpenSSL are offline, manual issuance tooling — the thing step-ca was adopted to stop paying engineers to do; they remain right for offline roots and one-off ceremonies. Dogtag and OpenXPKI are older enterprise OSS CAs — credible, but they are the EJBCA weight class with smaller ecosystems, so if that operational bill is acceptable, evaluate EJBCA first. cert-manager's built-in CA issuer is an in-cluster convenience, not a managed CA — no custody story, no revocation plane, no estate view; fine for a lab, a liability as a trust anchor. Let's Encrypt and other public ACME CAs solve public trust — using them for internal identity means publishing your internal hostnames to CT logs and renting your naming policy from a third party. If a shortlist mixes these categories with the five above, the requirement — and its cost model — was never written down precisely.

Migration mechanics from step-ca

One constraint before the list: if step-ca is also your SSH certificate authority — a genuinely distinctive step-ca feature — the exit story forks, because most destination CAs on this page are X.509-only. Vault covers SSH certificates via its SSH secrets engine; the common pattern otherwise is keeping a minimal step-ca for SSH issuance while the X.509 estate moves, which costs almost nothing precisely because the SSH CA workload is small. Budget this before cutover, not after.

The X.509 exit itself is a shorter list than most CA migrations, because short TTLs are a gift here: (1) trust anchor — cross-sign the successor or, if keeping step-ca, re-anchor it as a subordinate under the new root; with hours-to-days TTLs the estate re-roots itself within one renewal cycle rather than a multi-year tail; (2) ACME endpoint cutover — cert-manager Issuer/ClusterIssuer swap, staged namespace by namespace; (3) provisioner-policy translation — map step-ca provisioners to the destination's policy objects and diff the effective policy, which is where silent permission-widening sneaks in; (4) the leftovers — anything step-ca issued with long TTLs (there are always a few) needs the inventory pass so the old chain isn't turned off under them. The corresponding cost profile: near-zero double-running, one engineer-week order of magnitude for a single-team estate, dominated by item (3) if provisioner sprawl was allowed to accumulate.

FAQ

What is the best alternative to step-ca?
Depends on the wall you hit. Operations/HA only: Smallstep's commercial tier or AWS Private CA. Active revocation (CRL/OCSP) demands: 3AM Mint or EJBCA. Key custody concerns: anchor step-ca under a KMS-held root rather than replacing it. Multi-team enterprise governance: EJBCA, or a control-plane layer over multiple lightweight CAs.

How much does it cost to run step-ca?
The software is free; the cost is operational. A single-server deployment is paid for in engineer time — patching, upgrades, backups, and being the pager owner for a component whose outage stops issuance. Production HA adds a MySQL/PostgreSQL backend and a failover story. The comparison anchors: AWS Private CA at $400/CA/month plus per-certificate fees, Smallstep's commercial tiers at per-endpoint pricing, or a serverless in-account model where the CA carries no server care at all.

Is there a managed or commercial version of step-ca?
Yes, two shapes from the vendor: Smallstep Certificate Manager, a hosted service, and Step CA Pro, positioned as a drop-in replacement for open-source step-ca that keeps CA and root signing keys under your control while adding a cloud-based management interface and compliance features. The trade differs by shape: hosted moves issuance metadata to vendor infrastructure; Pro keeps keys local but adds a vendor management plane and per-endpoint commercial pricing.

Does step-ca support high availability?
Yes, with effort: multiple instances over a shared MySQL or PostgreSQL backend behind a load balancer. The point is not that HA is impossible — it is that at that stage you are operating a database-backed CA service, which erases much of the simplicity (and the cost profile) that motivated step-ca, and invites the comparison with managed or serverless models.

Does step-ca support OCSP?
step-ca's design centre is passive revocation via short-lived certificates, with database-backed revocation enforced at renewal and CRL support outside that core philosophy. Deployments facing relying parties that require standards-based real-time status typically move that requirement to a CA with a first-class OCSP plane.

Can I keep step-ca and still fix key custody?
Yes — this is often the right answer, and the cheapest one. A KMS-anchored root (for example via 3AM Mint's subordinate CA issuance) signs step-ca's intermediate: the trust anchor gains non-exportable FIPS-validated custody and survives loss of the step-ca host, while issuance tooling and ACME clients are untouched. No migration project, no re-integration cost.

Is step-ca production-ready?
For its design centre — single-team, short-TTL, ACME-native issuance — unambiguously yes, and AxelSpire recommends it in that bracket. "Production-ready" stops being the right question when the deployment accumulates enterprise properties (revocation SLAs, multi-team tenancy, audited custody); the question becomes whether the estate still matches the tool's philosophy — and whether the operating cost still matches the estate.

Dan Cvrcek, AxelSpire. Field observations from platform-team and device-identity PKI work, 2024–2026. step-ca and Smallstep commercial-product specifics should be re-checked against current Smallstep documentation before relying on them — the project and the product line both move quickly. AxelSpire sells 3AM Mint — bias disclosed, disqualifiers listed above. Updated July 2026.