caddy

What This Skill Does

The Caddy reverse proxy skill provides an automated workflow for routing local web services to secure, HTTPS-enabled subdomains within your private Tailscale network. By leveraging Caddy’s robust architecture and the DNS-01 ACME challenge via Vercel, this skill eliminates the hassle of managing manual SSL certificates for internal development environments. It effectively maps internal ports (e.g., localhost:3100) to clean URLs like myapp.YOUR_DOMAIN, ensuring that your local applications are accessible securely without exposing them to the public internet.

Installation

To begin, ensure you have Caddy installed and configured to run as a background service. Use the following command to integrate the skill into your OpenClaw ecosystem: clawhub install openclaw/skills/skills/brennerspear/caddy-reverse-proxy After installation, verify that your environment variables, specifically the Vercel API token required for DNS-01 challenges, are properly configured. You will also need to update your ~/.config/caddy/Caddyfile with the provided template to map your local services. Finally, reload the service using caddy reload --config ~/.config/caddy/Caddyfile --address localhost:2019 to apply your configurations.

Use Cases

This skill is ideal for developers running multiple microservices locally that require consistent, secure access. It is particularly useful for testing webhooks, managing dashboards for local databases, or previewing front-end applications that interact with backend APIs. By using wildcard subdomains, you can spawn new local environments on the fly without updating your hosts file on every device.

Example Prompts

1. "Caddy, add a new route for my local dashboard at port 3000 under the subdomain 'admin'."
2. "Caddy, check the status of my current proxy routes and list all active subdomains."
3. "Caddy, troubleshoot why my 'api.YOUR_DOMAIN' route is returning a TLS error."

Tips & Limitations

Note that this skill relies on the Vercel DNS provider for certificate issuance. If your domain is managed elsewhere, you must replace the plugin accordingly. Always allow 30–60 seconds for DNS propagation after adding a new service before expecting the HTTPS connection to resolve successfully. Keep your log files monitored—specifically /var/log/caddy-error.log—to quickly diagnose expired API tokens or configuration syntax errors.