Skip to main content

​
Choose an access path

API access and application access are separate. Enabling an application proxy does not authenticate your application users, and an Engine API token does not automatically protect an application’s URL.

​
Enable local HTTPS

Released installations already include Caddy. Source installations need a compatible Caddy executable on PATH or configured as [proxy].caddy_binary. Choose a hostname your clients can resolve to the Engine machine. This example uses nerdit.lan; replace it with your own name:
All proxy settings require an Engine restart. The default HTTPS port is 443. A Linux system installation grants the Caddy child permission to bind privileged ports. A Linux user installation must either use an unprivileged port such as 8443 or separately grant the bundled Caddy permission; file capabilities must be reapplied after upgrades. macOS does not use Linux setcap.
Use the resulting URL including its port. public_port only changes advertised URLs; it does not forward traffic or change the listener. Keep the Caddy admin endpoint on loopback. If another Caddy owns port 2019, select a different [proxy].admin_addr instead of overwriting that server.

​
Trust the internal certificate authority

The CLI shows the CA fingerprint and asks for confirmation. On each client machine, verify the fingerprint through a trusted channel before trusting a remote Engine. To save the verified root certificate without installing it:
Use nerdit untrust when removing trust. Do not make curl -k or disabled browser certificate validation part of normal operation. Internal certificates are not publicly trusted; sending someone a LAN URL does not install your CA on their device.

​
Path routing and subdomains

Path mode gives applications URLs such as https://nerdit.lan/my-app/. Applications must work under a path prefix: hard-coded /assets, root redirects, and absolute callback URLs may need changes. For applications that need a hostname root, configure subdomain mode:
Replace apps.example.com with a domain you control and point its application subdomains at the Engine. Nerdit does not provision DNS. Local mDNS can help with the machine’s .local hostname but does not provide wildcard subdomain DNS, and multicast may not cross WSL, guest Wi-Fi, VLAN, or VPN boundaries.

​
Use your own domain

Point a domain at the Engine machine, enable the proxy, and associate it with an application:
Without ACME, the domain uses the Engine’s internal CA. A stored domain can be withheld until the application is routed; check route readiness and certificate state separately. For a publicly trusted certificate, provide real public DNS and inbound ports 80 and 443, then apply a configuration file:
acme.toml
Replace the email with your operational contact. Apply it through the configuration workflow, restart the Engine, and request the certificate as an admin:
HTTP-01 validation must reach public port 80. A custom internal HTTP port only works if external port 80 is forwarded to it. Check the acme_http_port diagnostic, firewall, DNS, and proxy logs if issuance remains pending. A pending public certificate does not fall back to the internal CA; nerdit trust cannot fix it. Back up certificate and ACME account state before recovery.
Domain removal stops that route, not the underlying application.

​
Hosted sharing

Connect the Engine through the App before creating a hosted URL:
The default share is private. Public sharing requires the appropriate account entitlement and an explicit exposure acknowledgment or configured edge authentication:
A public share can be opened by anyone with its URL. Check the application’s own authentication and data before enabling it. A hosted share depends on the cloud connection; local applications and locally routed domains can continue independently.

​
Add basic authentication at the proxy

Store a password in the application’s secret scope, then reference it in nerdit.toml:
See secret handling before setting the value. An unresolved edge-auth secret withholds the protected proxy route rather than opening it. This protects proxy access; direct loopback access and your application’s authorization remain separate boundaries.