Pre-fix, an authenticated dashboard operator could call:
POST /api/v1/site {domain:"evil.example.com", upstream:"10.0.0.1:80"}
POST /api/v1/site/external {subdomain:"x", externalUrl:"http://192.168.1.5"}
and end up with a Caddy site block that proxies PUBLIC traffic at
evil.example.com to an INTERNAL host. Caddy runs on DNS2 (same
network as the targets), so the SSRF lands.
The pre-fix /site upstream regex /^[a-z0-9.-]+:\d{1,5}$/i only
checked charset — it happily accepted 192.168.1.1:80 and
169.254.169.254:80 (AWS metadata IP). /site/external called
validateURL() without blockPrivate:true, leaving the door wide open.
(1) New helper validateUpstream() in fleet-validation.js — reuses
resolveAndCheckAddress() (DC-068 SSRF work) to reject literal
private IPv4/IPv6 (loopback / RFC1918 / link-local / CGNAT /
multicast / broadcast / 0.0.0.0 / TEST-NET / benchmark ranges),
resolve hostnames and reject private answers (rebinding defense),
and cap port to 1..65535. Opt-in via SITES_ALLOW_PRIVATE_UPSTREAMS=true.
(2) /site calls validateUpstream() BEFORE caddy.modify() — gate
happens before any state mutation. Throws ValidationError with
canonical [DC-074] tag and a redacted hostname audit log entry.
(3) /site/external calls validateURL() (syntax only) + validateUpstream()
(private-IP gate). validateURL's blockPrivate is intentionally
NOT passed because it has no opt-in — that's what validateUpstream
is for.
(4) Tests (__tests__/routes/sites-dc074.routes.test.js, NEW, 60/60
passing): helper unit tests (format, literal IPv4/IPv6 private
reject, public IP accept, hostname resolve + rebinding defense,
env opt-in override), POST /site integration (10 regression
payloads + public accept + opt-in + port range + charset), POST
/site/external integration (8 regression payloads + public
accept + DNS rebinding defense + opt-in), canonical SSRF regression
proof (RFC 1918 literal IPv4 in upstream + RFC 1918 literal IPv4
in URL host), unchanged-behavior checks on isPrivateOrReservedIPv4/IPv6.
Full repo suite: 2402/2402 tests in 102 suites (zero regressions).
GLM-5.3 stand-in judge round 1 (deleg_384b9f53, 41.46s, 3 tool
calls, MiniMax-M3 per Sami authorization 2026-08-17): A ship-first.
Refs: codex-as-judge SKILL.md 'Stand-in fallback chain'. Verdict
record: /root/dashcaddy-polish/.ump-verdicts/2026-08-18T22-35-00Z-dc-074-round-1-A.json
DashCaddy
Self-hosted dashboard for managing Docker apps with automatic SSL, DNS, and reverse proxy configuration.
What is DashCaddy?
DashCaddy is an all-in-one solution for self-hosting Docker applications. It combines:
- 🎨 Beautiful Dashboard - Monitor all your services in one place
- 🐳 Docker Management - Deploy 50+ pre-configured apps with one click
- 🔒 Automatic SSL - Internal CA with automatic certificate generation
- 🌐 DNS Integration - Automatic DNS record creation (Technitium DNS)
- 🔄 Reverse Proxy - Caddy configuration managed automatically
- 🔐 Tailscale Support - Secure remote access built-in
Features
Authentication & Security
- Built-in TOTP two-factor authentication
- Fine-grained access control per service
- Secure session management
- Group-based permissions
Dashboard
- Real-time service health monitoring
- Response time tracking
- Status indicators with visual feedback
- Weather widget
- Multiple themes (dark/light/blue)
- Import/export configuration
App Deployment
- 50+ pre-configured app templates
- One-click deployment
- Automatic DNS + SSL + reverse proxy setup
- Container health checking
- Deployment status tracking
- SSL certificate generation monitoring
Service Management
- Add/edit/delete services
- Restart containers
- View logs
- Update configurations
- Silent deletions (no annoying popups)
Developer Tools
- Error log viewer
- API endpoints for automation
- Import/export for testing
- Comprehensive error logging
Quick Start
Prerequisites
- Docker & Docker Compose
- Caddy web server
- Technitium DNS (optional, for automatic DNS)
- Node.js 18+ (for API server)
Installation
- Clone the repository
git clone https://github.com/yourusername/dashcaddy.git
cd dashcaddy
- Install dependencies
cd caddy-api
npm install
- Configure environment
cp .env.example .env
# Edit .env with your settings
- Start the API server
npm start
- Configure Caddy Add to your Caddyfile:
status.yourdomain.com {
root * /path/to/dashcaddy/status
file_server
reverse_proxy /api/* localhost:3001
}
- Access the dashboard
Open
https://status.yourdomain.comin your browser
Health Probes
DashCaddy exposes Kubernetes/Docker-standard health endpoints for container orchestration. No auth required — these are designed for orchestration tooling to poll.
| Path | Purpose | Returns |
|---|---|---|
/healthz or /health/live |
Liveness — is the Node.js process alive? | 200 with {status: "alive", uptime: <seconds>} |
/readyz or /health/ready |
Readiness — are critical deps reachable? (config file, services file, Docker daemon, Caddy admin API) | 200 if all OK, 503 if any dep fails (with details in the checks object) |
/health |
Backwards-compat alias for /healthz |
Same as /healthz |
When to use which:
- Use
/healthz//health/livein alivenessProbe— should the container be restarted? - Use
/readyz//health/readyin areadinessProbe— should traffic be routed to this instance?
Docker Compose healthcheck
Copy-paste this into your DashCaddy docker-compose.yml:
services:
dashcaddy-api:
image: ghcr.io/samiahmed7777/dashcaddy-api:latest
# ... your existing config ...
healthcheck:
test: ["CMD", "node", "-e", "require('http').get('http://localhost:3001/readyz', r => process.exit(r.statusCode === 200 ? 0 : 1)).on('error', () => process.exit(1))"]
interval: 30s
timeout: 5s
retries: 3
start_period: 30s
Kubernetes probes
livenessProbe:
httpGet:
path: /healthz
port: 3001
initialDelaySeconds: 30
periodSeconds: 30
readinessProbe:
httpGet:
path: /readyz
port: 3001
initialDelaySeconds: 10
periodSeconds: 10
Both endpoints return JSON. Liveness is cheap (no I/O, no deps). Readiness touches the Docker daemon and Caddy admin API with a 3-second timeout each, so it's safe to poll every 10s without load concerns.
Configuration
Environment Variables
Create a .env file in the caddy-api directory:
# Caddy Configuration
CADDYFILE_PATH=/path/to/Caddyfile
CADDY_ADMIN_URL=http://localhost:2019
# DNS Configuration (optional)
DNS_SERVER=192.168.1.1
DNS_TOKEN=your-dns-token
# File Paths
SERVICES_FILE=/path/to/services.json
ERROR_LOG_FILE=/path/to/dashcaddy-errors.log
DNS Integration
DashCaddy works with Technitium DNS for automatic DNS record creation:
- Install Technitium DNS
- Create an API token with DNS management permissions
- Configure DNS credentials in dashboard (🔑 Tokens button)
Tailscale Integration
For secure remote access:
- Install Tailscale on your server
- Services can be restricted to Tailscale-only access
- Configure in deployment settings
Usage
Deploying an App
- Click "App Selector" button
- Choose an app from the template library
- Configure:
- Subdomain (e.g.,
jellyfin→jellyfin.yourdomain.com) - Port (auto-suggested)
- IP address (defaults to localhost)
- Tailscale-only access (optional)
- Subdomain (e.g.,
- Click "Deploy"
- Wait for SSL certificate generation (30-60 seconds)
- Access your app!
Managing Services
- View Status: Cards show real-time health and response times
- Open Service: Click "Open" button
- Restart: Click restart button (for Docker containers)
- Delete: Click delete button (removes everything: container, DNS, Caddy config)
- Edit: Click settings button to modify configuration
Viewing Error Logs
- Click "📋 Logs" button in toolbar
- View all errors with timestamps and context
- Refresh to see latest errors
- Clear logs when resolved
Backup & Restore
Export Configuration:
- Click "📤 Export" button
- JSON file downloads with all your services
- Save safely
Import Configuration:
- Click "📥 Import" button
- Select your backup JSON file
- Confirm import
- Dashboard reloads with restored configuration
Note: API tokens are not exported for security. Reconfigure after import.
App Templates
DashCaddy includes 50+ pre-configured templates:
Media & Entertainment
- Plex, Jellyfin, Emby
- Navidrome, Airsonic
- Tautulli, Overseerr
Downloads
- Sonarr, Radarr, Lidarr, Readarr
- Prowlarr, Bazarr
- qBittorrent, Transmission
- SABnzbd, NZBGet
Productivity
- Nextcloud
- Paperless-ngx
- BookStack, Outline
- Standard Notes
Management
- Portainer
- Homepage, Homarr
- Uptime Kuma
- Grafana
Security & Authentication
- Vaultwarden (Password Manager)
Development
- Gitea
- VS Code Server
- Jenkins, Drone CI
And many more!
API Endpoints
Services
GET /api/services- List all servicesPOST /api/services- Add servicePUT /api/services- Bulk import servicesDELETE /api/services/:id- Remove service
App Deployment
GET /api/apps/templates- List app templatesPOST /api/apps/deploy- Deploy new appDELETE /api/apps/:id- Remove deployed app
Error Logs
GET /api/error-logs- Get error logsDELETE /api/error-logs- Clear error logs
DNS Management
POST /api/dns/record- Create DNS recordDELETE /api/dns/record- Delete DNS record
Caddy Management
GET /api/caddy/config- Get Caddyfile contentPOST /api/caddy/reload- Reload Caddy configuration
Troubleshooting
SSL Certificate Errors
Problem: "Secure Connection Failed" when accessing new service
Solution:
- Wait 30-60 seconds for certificate generation
- Check dashboard notification for SSL status
- Manually reload Caddy:
caddy reload --config /path/to/Caddyfile - Check error logs in dashboard
DNS Not Resolving
Problem: Service URL doesn't resolve
Solution:
- Verify DNS server is running
- Check DNS credentials in 🔑 Tokens menu
- Manually add DNS record in Technitium DNS
- Flush DNS cache:
ipconfig /flushdns(Windows) orsudo systemd-resolve --flush-caches(Linux)
Container Won't Start
Problem: Deployment succeeds but service is offline
Solution:
- Check Docker logs:
docker logs [container-id] - Verify port isn't already in use
- Check container resource limits
- View error logs in dashboard
Import/Export Issues
Problem: Import fails or data is incomplete
Solution:
- Validate JSON format
- Check file has
versionandservicesfields - Reconfigure API tokens after import
- Check error logs for details
Development
Project Structure
dashcaddy/
├── status/ # Dashboard frontend
│ ├── index.html # Main dashboard
│ └── assets/ # Logos, icons, fonts
├── caddy-api/ # API backend
│ ├── server.js # Express server
│ ├── app-templates.js # App template definitions
│ └── package.json # Dependencies
├── dashcaddy-installer/ # Electron installer (WIP)
└── docs/ # Documentation
Adding Custom App Templates
Edit caddy-api/app-templates.js:
"myapp": {
name: "My App",
description: "Description of my app",
icon: "🚀",
logo: "https://cdn.example.com/logo.png",
category: "Productivity",
docker: {
image: "myapp/myapp:latest",
ports: ["{{PORT}}:8080"],
volumes: ["/opt/myapp:/data"],
environment: {
"APP_ENV": "production"
}
},
subdomain: "myapp",
defaultPort: 8080,
healthCheck: "/health"
}
Contributing
Contributions are welcome! Please:
- Fork the repository
- Create a feature branch
- Make your changes
- Test thoroughly
- Submit a pull request
Roadmap
- Service groups/categories
- Container log viewer
- DNS management UI
- Backup automation
- Multi-user support
- Mobile app
- Analytics dashboard
- Template marketplace
License
Proprietary software. All rights reserved. See LICENSE for the End-User License Agreement (EULA).
Credits
- Dashboard Icons: walkxcode/dashboard-icons (MIT License)
- Caddy: caddyserver.com
- Technitium DNS: technitium.com/dns
Support
- Issues: GitHub Issues
- Discussions: GitHub Discussions
- Documentation: Wiki
Acknowledgments
Built with ❤️ for the self-hosting community.
DashCaddy - Making self-hosting beautiful and effortless.