testd documentation

testd gives a project running in a container, VM, WSL distro, or remote box a stable HTTPS name on the machine with the browser. The host owns the naming authority, the local CA, and the reverse proxy; the dev environment only registers a name over one TCP connection.

Start with the quickstart if you have not run a name yet.

Start here

01QuickstartInstall, prepare the host, start the daemon, and open the first name.02Daily usageNames, targets, lifetimes, the dashboard, sharing, access requests, and troubleshooting.03Advanced usageRemote leaves, profiles, grants, quick launches, tunnels, external fronts, and PKI.04ReferenceCommands, options, configuration keys, files, endpoints, limits, and platform notes.05SecurityTrust boundaries, credentials, exposure, hardening, and the incident checklist.06Dependency policyThe advisory exceptions and MSRV constraints that the dependency gate accepts.

The model in one paragraph

The host is the authority. It runs DNS for .test, terminates TLS with a local CA, stores the operator secret and issued tokens, and proxies each live name to the dev environment. A leaf keeps one outbound TCP connection open and registers names on it; the connection is the lease, so a crash or lost network releases the name without a cleanup job. A token is durable permission, and its grants are the exact names it may publish.

Source and releases

The source, changelog, and release archives live at https://github.com/LapilliWorks/testd. The product site is at https://testd.dev. testd is ISC licensed and has no account, telemetry, public DNS, or ACME dependency.