TLS certificates are required when the governance server binds to a non-loopback address (anything outsideDocumentation Index
Fetch the complete documentation index at: https://docs.nanny.run/llms.txt
Use this file to discover all available pages before exploring further.
127.x.x.x). For local multi-process development on loopback, no certs are needed.
Commands
generate
Generate a complete certificate bundle for the governance server.Files generated
nanny server start reads server.crt, server.key, and ca.crt automatically. Agents on other machines need client.crt, client.key, and ca.crt.
Flags
| Flag | Type | Default | Description |
|---|---|---|---|
--out-dir | path | ~/.nanny/certs/ | Directory to write cert files. The default is outside any project directory so files are never accidentally committed. |
--days | integer | 365 | Certificate validity period in days. |
--force | flag | — | Overwrite existing cert files. Without this flag, generate refuses if any cert files already exist. |
Example output
If cert files already exist
import
Import externally-issued certificates. Use this when your organization has its own PKI (HashiCorp Vault, AWS ACM, cert-manager, an internal CA).key=value pairs. Values are either a PEM string or a @file reference (path prefixed with @). Three keys are accepted: ca, cert, key.
Partial imports are supported. Omit any key to leave the existing file unchanged. This is useful for rotating only the server cert and key while keeping the existing CA:
Examples
From files:rotate
Regenerate the server and client certificates, preserving the existing CA.rotate signs new server and client certs using the CA that nanny certs generate created. The CA itself is not changed — existing agents that trust this CA continue to work without re-importing ca.crt.
When to use rotate:
- Cert expiry is approaching (check with
nanny certs show) - You want to invalidate the existing client cert (rotation generates a new
client.crt+client.key)
rotate does not apply:
- Your certs were issued by an external PKI (Vault, AWS ACM, etc.) — those systems hold the CA private key, not Nanny. Use
nanny certs importinstead.
rotate requires ca.key to be present in ~/.nanny/certs/. This file only exists when nanny certs generate created the CA. If ca.key is missing, rotate exits with an error and suggests nanny certs import.
Example output
show
Show expiry dates, file inventory, and SAN list for the current cert bundle.Example output
remove
Delete all cert files from~/.nanny/certs/.
nanny server start with a non-loopback address will refuse to start until new certs are generated or imported.
If no certs exist:
Certificate hot-reload
The governance server watches~/.nanny/certs/ for file changes. When cert files are updated — by nanny certs import, nanny certs rotate, or an external PKI agent writing to the directory — the server reloads the new certs without restarting. New connections use the new cert immediately; existing connections complete on the old cert.
This is designed for short-lived PKI certs (for example, Vault PKI secrets engine issuing 8-hour certs renewed automatically by Vault Agent). The server stays up; certs rotate underneath it.
Keeping ca.key secure
The CA private key (ca.key) is the trust anchor for your entire certificate bundle. Anyone with access to ca.key can generate new certificates that your server will accept.
- Keep
ca.keyon the server machine only. Never copy it to agent machines. - The client machines need only
ca.crt(to verify the server) andclient.crt+client.key(to present to the server). - Back up
ca.keysecurely. If you lose it, runnanny certs generate --forceto start fresh — but you will need to redistributeca.crtto all agent machines.