Local HTTPS for private IP addresses.

Get browser-trusted TLS certificates for apps on your LAN. No domain, local CA, or DNS setup required.

# get a certificate for your local app $ lancert 192.168.1.50 Certificate issued. Hostname: quiet-otter.lancert.dev Certificate: ~/.config/lancert/certs/quiet-otter.lancert.dev/fullchain.pem Private key: ~/.config/lancert/certs/quiet-otter.lancert.dev/privkey.pem
# DNS already resolves to your LAN $ dig quiet-otter.lancert.dev +short 192.168.1.50
# done — valid HTTPS on your private IP $ curl https://quiet-otter.lancert.dev Hello from your local app!

The CLI uses Let’s Encrypt by default. Let’s Encrypt policies and rate limits apply.

Prefer your own ACME client?

The Lancert CLI is the quickest option, but it is not required. Register your private IP, then use the returned credentials with Lego, Certbot, acme.sh, or another compatible client. See the setup guide.

# register a private IP $ curl --fail-with-body -X POST https://lancert.dev/register/192.168.1.50 { "hostname": "quiet-otter.lancert.dev", "username": "…", "password": "save-this-one-time-secret" }

Why use lancert for local HTTPS?

Browser-trusted certificates

Certificates from a trusted certificate authority. No custom CA, device setup, or certificate warnings.

Test on real devices

Use service workers, push notifications, WebRTC, and other HTTPS-only APIs from devices on your LAN.

No domain or DNS setup

Lancert provides the hostname and handles the DNS records required for validation.

Wildcard names included

Each certificate covers the assigned hostname and its wildcard, so one certificate works across your local subdomains.

How local HTTPS works

A hostname for your app

The CLI registers your private IPv4 address and receives a random hostname under lancert.dev.

Authoritative DNS

Lancert points the assigned hostname and its wildcard to your private IPv4 address.

Standard DNS-01 challenge

The CLI asks the certificate authority for a certificate and uses Lancert to publish the required DNS challenge record.

Local certificate and renewal

The CLI saves the certificate and private key on your machine. Run lancert renew regularly to renew certificates when needed.

Example: Caddy

Get a certificate with the Lancert CLI and use the printed paths with Caddy.

1. Get the certificate

$ lancert 192.168.1.50 Certificate issued.

2. Create a Caddyfile

# wildcard certificate covers local subdomains quiet-otter.lancert.dev, hi.quiet-otter.lancert.dev { tls /path/to/fullchain.pem /path/to/privkey.pem respond "Hello from lancert!" }

3. Run and test

$ caddy run
# from another terminal or any device on your network $ curl https://quiet-otter.lancert.dev Hello from lancert! $ curl https://hi.quiet-otter.lancert.dev Hello from lancert!

FAQ

Which IP ranges are supported?

Private IPv4 addresses in 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16.

Do I need my own domain?

No. Lancert assigns a hostname under lancert.dev. You can build the same standard DNS-01 flow with your own domain and DNS provider if you prefer.

Do I have to use the Lancert CLI?

No. You can use Lego, Certbot, acme.sh, or another client that supports an acme-dns-compatible API. This requires a few extra setup steps.

Which certificate authority does the CLI use?

The CLI uses Let’s Encrypt by default. Let’s Encrypt terms, policies, and rate limits apply. You can select another ACME-compatible certificate authority.

Where are certificates and private keys stored?

They stay on your machine in your platform’s user configuration directory. The CLI prints the exact paths after issuance, and the Lancert service never receives or stores them.

What do I trust Lancert with?

Lancert operates DNS for your assigned hostname and publishes its address and challenge records. As with any managed DNS service, you rely on Lancert to operate DNS for the hostname it provides.