Cadder documentation

Cadder coordinates local Caddy projects that would otherwise fight for the same HTTP and HTTPS ports. Each project can still use a familiar caddy run workflow, but Cadder registers those projects with one per-user daemon and applies them through one real Caddy process.

That makes local reverse-proxy setups easier to run side by side. Cadder can compose active project Caddyfiles, report domain conflicts before reload, and show the current state in a terminal dashboard.

Features

• One local Caddy runtime can serve domains from many project Caddyfiles.
• The caddy shim keeps caddy run usable for project workflows.
• cadder.toml points Cadder at the real Caddy binary without replacing it.
• cadder-tui shows entrypoints, domains, logs, diagnostics, and toggles.
• Domains can be enabled or disabled without killing unrelated project sessions.
• Cadder avoids owning Caddy processes it did not start.

Binaries

• caddy is the Caddy-compatible shim. For caddy run, it starts or connects to cadderd, registers the current project, and unregisters on exit. Other Caddy commands are delegated to the real Caddy binary.
• cadderd is the daemon. It owns registrations, generated Caddy config, the real Caddy process it starts, diagnostics, and bounded logs.
• cadder-tui is the terminal UI for inspecting domains, entrypoints, diagnostics, logs, filters, toggles, and daemon shutdown.

Each binary supports --help and --version.

Download

Windows x64macOS Apple SiliconmacOS IntelLinux x64

1. Download the release for your operating system.
2. Create cadder.toml with the path to the real Caddy binary. See cadder.toml for the supported forms.
3. Run Cadder’s caddy shim instead of the real caddy command.

Open cadder-tui whenever you want to inspect active projects, domains, logs, or diagnostics.