Now: foundation
Operate one lego workspace safely
Qualified runtime adoption, typed native configuration, constrained manual and daily operations, current certificate health, and bounded redacted results on one Debian host.
Product direction
The MVP is one workspace. The destination is complete certificate lifecycle.
AcmeMux began again with the smallest boundary that could be made trustworthy: one administrator operating one upstream lego runtime and one native workspace. The long-term goal is a self-hosted platform that discovers, issues, renews, deploys, and accounts for public and private certificates across an operator's environment.
North star
One place to understand certificate risk and act on it.
The end state is not merely a nicer form for lego. An operator should be able to answer which certificates exist, where they are served, who owns them, how they were issued, when they will renew, whether deployment succeeded, and what evidence remains after the operation.
AcmeMux should cover lifecycle depth without becoming an opaque hosted dependency: public and private trust, inventory and discovery, policy and approval, renewal and deployment, alerts and reports, identity and audit, backup and recovery. It remains self-hosted, inspectable, and designed for the person responsible during an outage.
The path
Grow outward from a boundary that already works.
These horizons describe direction, not release promises. Security, evidence, and operator recovery remain gates at every stage.
Next: dependable operation
Make unattended renewal trustworthy
Signed packaging, short-lived profiles, renewal alerts, durable operation history, backup and restore, more qualified platforms, and clearer recovery evidence.
Then: connected lifecycle
Find and move certificates
Multiple workspaces, broader inventory, network and cloud discovery, constrained deployment adapters, service APIs, webhooks, templates, and lifecycle policy.
Destination
Self-hosted certificate lifecycle management
Public and private issuance, unified inventory, access control and approvals, auditable automation, compliance evidence, resilient recovery, and integrations across real infrastructure.
Near-term work
What moves the foundation forward now
In progress
First public release
Complete qualification, publish source and signed release artifacts, and make the supported installation path reproducible.
Proposed
Short-lived ACME profiles
Add reviewed support for Let's Encrypt's shortlived profile and prove the higher-frequency renewal and recovery behavior it requires.
Proposed
Signed Debian package
Replace source compilation with an auditable package, signed repository, explicit upgrade path, and rollback guidance.
Discuss this proposalProposed
Renewal notifications
Report failure and recovery without leaking secrets or confusing certificate evaluation with successful deployment.
Discuss this proposalProduct principles
What the destination must preserve
Self-hosted authority
Operators retain control of infrastructure, credentials, certificate material, and deployment choices.
Evidence over optimism
Show the certificate actually served and the operation actually completed, including partial and ambiguous outcomes.
Constrained execution
Integrations use typed, reviewed operations rather than turning the browser into a remote shell.
Recoverable at 2 a.m.
Every moving part must justify its effect on diagnosis, backup, restore, and mean time to recovery.
Honest support claims
A compiled provider or a passing experiment is not called supported until it has qualification and documentation.
No hidden telemetry
The product and website do not need analytics or usage reporting to perform certificate operations.
Priority policy
How near-term work enters the queue
- 0
Security and release integrity
Actively exploited vulnerabilities, critical defects, and work required for a trustworthy release can preempt every feature queue.
- 1
Accepted sponsor-funded commitments
Work with agreed feasibility, scope, funding, acceptance criteria, and delivery terms is scheduled ahead of ordinary feature requests.
- 2
Community-ranked proposals
Accepted proposals are ranked by positive reactions in their GitHub Discussion. Votes are a priority signal, not an automatic promise.
- 3
Maintainer-selected direction
Architecture, usability, qualification, and connective work required to reach the product vision fill the remaining capacity.
One roadmap, two surfaces
The website explains the destination. GitHub records the work.
This page is the canonical public product roadmap. The organization .github repository exists because GitHub uses that special name for the AcmeMux organization profile and shared community files. Its ROADMAP.md mirrors the horizons and tracks proposal status close to discussions and contributions.
Payment buys agreed priority, not unsafe code. Every contribution still requires architectural fit, security review, tests, documentation, license compatibility, and maintainer approval.