Per CONTRIBUTING's discuss-first rule — opening this to hear whether the direction fits upstream before polishing the implementation to your conventions.
Proposal
Built-in ACME certificate management: the panel issues TLS certificates for node inbounds over DNS-01, renews them on schedule, and injects the PEM into tlsSettings.certificates at config render time — so private keys reach only the nodes a certificate is bound to, and a renewal restarts exactly the affected nodes.
The problem it addresses: today TLS on nodes means an external agent (acme.sh/certbot + glue) writing PEM into config profiles. A profile is shared, so every node holding it gets every private key; the panel does not see renewals, so nodes serve stale certificates until someone restarts them; and each installation runs one more container with zone-wide DNS credentials.
Scope highlights:
- 8 native DNS providers (Cloudflare, deSEC, DigitalOcean, Gandi, Hetzner, Porkbun, PowerDNS, Vultr) driven by a provider registry in the contract, plus
CUSTOM — any HTTP DNS broker over an open four-endpoint protocol, so an internet-facing panel can hold a narrowly scoped token instead of a zone-wide one.
- Any RFC 8555 CA, staging-first defaults, EAB supported; wildcards; ECDSA/RSA.
- Import for certificates issued elsewhere (bought / corporate CA) with the same node-binding delivery.
- Per-certificate event journal; failures surface in the UI.
- Deployment cost: one new env var (
ACME_SECRET_KEY, documented in .env.sample), additive acme_* migrations, no changes to existing flows when unused.
Working implementation
Draft PRs with the full write-up, configuration examples and screenshots:
Operator documentation lives in the branch as docs/acme.md. The feature has been running in production on a three-node installation since 2026-08-08 (14 certificates, including live renewals).
If the direction is acceptable, I will adapt whatever you want changed — splitting the PRs, dropping the fork-CI workflows they carry, Crowdin for the pages, naming, anything else.
Per CONTRIBUTING's discuss-first rule — opening this to hear whether the direction fits upstream before polishing the implementation to your conventions.
Proposal
Built-in ACME certificate management: the panel issues TLS certificates for node inbounds over DNS-01, renews them on schedule, and injects the PEM into
tlsSettings.certificatesat config render time — so private keys reach only the nodes a certificate is bound to, and a renewal restarts exactly the affected nodes.The problem it addresses: today TLS on nodes means an external agent (acme.sh/certbot + glue) writing PEM into config profiles. A profile is shared, so every node holding it gets every private key; the panel does not see renewals, so nodes serve stale certificates until someone restarts them; and each installation runs one more container with zone-wide DNS credentials.
Scope highlights:
CUSTOM— any HTTP DNS broker over an open four-endpoint protocol, so an internet-facing panel can hold a narrowly scoped token instead of a zone-wide one.ACME_SECRET_KEY, documented in.env.sample), additiveacme_*migrations, no changes to existing flows when unused.Working implementation
Draft PRs with the full write-up, configuration examples and screenshots:
Operator documentation lives in the branch as
docs/acme.md. The feature has been running in production on a three-node installation since 2026-08-08 (14 certificates, including live renewals).If the direction is acceptable, I will adapt whatever you want changed — splitting the PRs, dropping the fork-CI workflows they carry, Crowdin for the pages, naming, anything else.