287 lines
17 KiB
TypeScript
287 lines
17 KiB
TypeScript
import Navbar from '@/components/Navbar';
|
||
import Footer from '@/components/Footer';
|
||
import DocsLayout from '@/components/docs/DocsLayout';
|
||
|
||
export default function DocsOverviewPage() {
|
||
return (
|
||
<div className="flex min-h-screen flex-col bg-surface-950 text-surface-50">
|
||
<Navbar />
|
||
<DocsLayout
|
||
title="Product Overview"
|
||
intro="DashCaddy is a self-hosted control plane for deploying, exposing, and managing Docker applications — with automatic DNS, reverse proxy, internal HTTPS, real-time monitoring, AI-driven operations, and centralized fleet visibility."
|
||
>
|
||
<h2>What you'll learn</h2>
|
||
<blockquote className="border-l-4 border-brand-500/50 bg-brand-500/5 p-4 rounded-r-lg">
|
||
<p className="text-surface-300">
|
||
<strong className="text-brand-400">What you'll learn:</strong> This page covers the full DashCaddy architecture, design philosophy, component breakdown, and how it compares to manual self-hosting. By the end, you'll understand why DashCaddy exists, what problems it solves, and how its layers work together as a unified platform.
|
||
</p>
|
||
</blockquote>
|
||
|
||
<h2>What DashCaddy is</h2>
|
||
<p>
|
||
DashCaddy brings together the layers that self-hosters usually wire by hand — Docker deployment,
|
||
Caddy reverse proxy, Technitium DNS automation, internal certificate distribution, service monitoring,
|
||
and operational tooling — and unifies them behind a single, cohesive control plane.
|
||
</p>
|
||
<p>
|
||
Instead of editing a dozen config files and praying the layers agree, you deploy a service once and
|
||
DashCaddy wires the runtime, the proxy route, the DNS record, the TLS certificate, and the health
|
||
checks for you. The goal is simple: make running self-hosted services feel like one product instead
|
||
of six fragile integrations.
|
||
</p>
|
||
|
||
<h2>Platform architecture</h2>
|
||
<p>
|
||
DashCaddy is a production-grade platform built on eight distinct layers, each responsible for a
|
||
specific concern. Together they form a complete self-hosting stack that replaces dozens of manual
|
||
configuration steps with a single declarative action.
|
||
</p>
|
||
|
||
<h3>1. Application Layer</h3>
|
||
<p>
|
||
The Application Layer is what operators interact with directly. It is a React-based dashboard that
|
||
provides real-time visibility into every service, container, and infrastructure component managed by
|
||
DashCaddy. Beyond the visual interface, this layer exposes a REST API under <code>/api/v1/</code> and
|
||
a WebSocket channel for live updates. Every action available in the UI — deploying a service, editing
|
||
a Caddy route, reviewing audit logs — is available through the API, making the dashboard a thin client
|
||
over a fully programmable control plane. The application layer also handles authentication, role-based
|
||
access control, TOTP two-factor enrollment, and multi-user admin invitations.
|
||
</p>
|
||
|
||
<h3>2. Orchestration Layer</h3>
|
||
<p>
|
||
The Orchestration Layer is the Node.js/Express engine at the heart of DashCaddy. It receives deployment
|
||
requests, coordinates Docker container lifecycle, drives Caddy reverse proxy configuration through the
|
||
Admin API, manages Technitium DNS records programmatically, and handles certificate issuance and renewal.
|
||
This layer is responsible for ensuring that every deployment is atomic — either all layers succeed or the
|
||
operation rolls back cleanly. It maintains the authoritative service state store, tracks health checks,
|
||
and publishes events over WebSocket for the dashboard. The orchestration engine also powers the Smart
|
||
Defaults Wizard, Service Discovery, and the Caddyfile-as-Code builder.
|
||
</p>
|
||
|
||
<h3>3. Runtime Layer</h3>
|
||
<p>
|
||
The Runtime Layer is Docker and Docker Compose — the container workloads that actually run your services.
|
||
DashCaddy manages container creation, network attachment, volume mounts, environment variable injection,
|
||
and lifecycle operations (start, stop, restart, remove). For advanced deployments, the platform supports
|
||
Docker Swarm for multi-host orchestration and Fleet Management for coordinating services across multiple
|
||
servers. Every container managed by DashCaddy is tracked in the service state store, enabling features
|
||
like Service Discovery (adopting existing containers) and Disaster Recovery (full-system backup and restore
|
||
with SHA-256 checksum verification).
|
||
</p>
|
||
|
||
<h3>4. Edge Layer</h3>
|
||
<p>
|
||
The Edge Layer is Caddy — the reverse proxy that terminates HTTPS connections and routes traffic to your
|
||
services. DashCaddy manages Caddy entirely through its Admin API, never requiring manual edits to a
|
||
Caddyfile. The Caddyfile-as-Code builder generates configuration declaratively, and the orchestration
|
||
layer applies changes atomically. Caddy handles automatic TLS certificate issuance and renewal using its
|
||
built-in ACME client for public domains or its internal CA for private networks. The Edge Layer also
|
||
provides load balancing, header manipulation, request logging, and rate limiting — all configurable
|
||
through the DashCaddy dashboard without touching Caddy's native configuration syntax.
|
||
</p>
|
||
|
||
<h3>5. Name Resolution Layer</h3>
|
||
<p>
|
||
The Name Resolution Layer is Technitium DNS — a self-hosted authoritative DNS server that DashCaddy
|
||
controls programmatically. When you deploy a service with hostname <code>plex.local</code>, the
|
||
orchestration layer creates an A record pointing to your host's IP address automatically. When you
|
||
remove the service, the record is cleaned up. This eliminates the manual DNS management that plagues
|
||
most self-hosting setups. Technitium DNS also supports zone transfers, forwarding, and custom record
|
||
types for advanced networking scenarios. The integration is optional — if you don't configure DNS,
|
||
DashCaddy skips this layer and your services still deploy with direct IP access.
|
||
</p>
|
||
|
||
<h3>6. Trust Layer</h3>
|
||
<p>
|
||
The Trust Layer handles certificate authority management and internal HTTPS distribution. Caddy's built-in
|
||
CA issues certificates automatically for every service, but those certificates are only trusted if the
|
||
client device trusts the issuing CA. DashCaddy solves this with DashCA — an internal certificate authority
|
||
distribution surface. The Smart Defaults Wizard initializes DashCA on first launch and offers the root
|
||
certificate for download. Once installed on client devices (browsers, phones, IoT devices), every service
|
||
managed by DashCaddy presents a trusted HTTPS connection without certificate warnings. This layer also
|
||
handles certificate renewal tracking and expiration alerts.
|
||
</p>
|
||
|
||
<h3>7. Observability Layer</h3>
|
||
<p>
|
||
The Observability Layer provides real-time health monitoring, structured audit logging, and metrics export.
|
||
Every service managed by DashCaddy has a health check that runs continuously, with status updates pushed
|
||
to the dashboard over WebSocket. The layer exports Prometheus-compatible metrics at <code>/metrics</code>,
|
||
enabling integration with Grafana, VictoriaMetrics, or any Prometheus-compatible monitoring stack. Audit
|
||
logs capture every administrative action — who deployed what, when, and from which IP — providing the
|
||
accountability required for multi-user environments. The Security Center aggregates logs from multiple
|
||
sources (Caddy access logs, container stdout, authentication events) into a unified event pipeline for
|
||
threat detection and forensic analysis.
|
||
</p>
|
||
|
||
<h3>8. Intelligence Layer</h3>
|
||
<p>
|
||
The Intelligence Layer makes DashCaddy AI-native. The AI Intent Router accepts natural-language commands
|
||
like "deploy Plex on port 32400" or "show me all unhealthy services" and translates them into API calls.
|
||
The MCP (Model Context Protocol) Server exposes DashCaddy operations to external AI assistants — Claude,
|
||
ChatGPT, or any MCP-compatible client can deploy services, check health, or modify configuration through
|
||
the protocol. This layer also powers the Plugin system, allowing third-party extensions to hook into
|
||
DashCaddy's event stream and extend functionality without modifying core code.
|
||
</p>
|
||
|
||
<h2>Design philosophy</h2>
|
||
<p>
|
||
DashCaddy is built on three principles that guide every architectural decision:
|
||
</p>
|
||
<ul>
|
||
<li>
|
||
<strong>Atomic operations:</strong> Deploying a service should succeed or fail as a single transaction.
|
||
You should never end up with a container running but no DNS record, or a Caddy route pointing to a
|
||
container that doesn't exist. The orchestration layer coordinates all layers and rolls back on failure.
|
||
</li>
|
||
<li>
|
||
<strong>Declarative configuration:</strong> You describe what you want (hostname, port, image), and
|
||
DashCaddy figures out the implementation details (Caddy route, DNS record, certificate). The
|
||
Caddyfile-as-Code builder generates configuration from your intent, not the other way around.
|
||
</li>
|
||
<li>
|
||
<strong>Progressive disclosure:</strong> The Smart Defaults Wizard gets you running in minutes with
|
||
sensible defaults. Advanced users can customize every layer — Caddy headers, DNS record types,
|
||
container resource limits — but complexity is optional, not mandatory.
|
||
</li>
|
||
</ul>
|
||
|
||
<h2>Comparison: Manual vs. DashCaddy Free vs. DashCaddy Premium</h2>
|
||
<div className="overflow-x-auto">
|
||
<table className="w-full text-left text-sm">
|
||
<thead>
|
||
<tr className="border-b border-surface-700">
|
||
<th className="py-3 pr-4 font-semibold text-surface-200">Capability</th>
|
||
<th className="py-3 pr-4 font-semibold text-surface-200">Manual Setup</th>
|
||
<th className="py-3 pr-4 font-semibold text-surface-200">DashCaddy Free</th>
|
||
<th className="py-3 font-semibold text-surface-200">DashCaddy Premium</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody className="text-surface-300">
|
||
<tr className="border-b border-surface-800">
|
||
<td className="py-3 pr-4">Docker deployment</td>
|
||
<td className="py-3 pr-4">Manual compose files</td>
|
||
<td className="py-3 pr-4">76+ one-click templates</td>
|
||
<td className="py-3">Templates + Recipes</td>
|
||
</tr>
|
||
<tr className="border-b border-surface-800">
|
||
<td className="py-3 pr-4">Reverse proxy</td>
|
||
<td className="py-3 pr-4">Hand-edit Caddyfile</td>
|
||
<td className="py-3 pr-4">Caddyfile-as-Code builder</td>
|
||
<td className="py-3">Same + fleet-wide routes</td>
|
||
</tr>
|
||
<tr className="border-b border-surface-800">
|
||
<td className="py-3 pr-4">DNS automation</td>
|
||
<td className="py-3 pr-4">Manual record creation</td>
|
||
<td className="py-3 pr-4">Technitium integration</td>
|
||
<td className="py-3">Same + multi-zone</td>
|
||
</tr>
|
||
<tr className="border-b border-surface-800">
|
||
<td className="py-3 pr-4">TLS certificates</td>
|
||
<td className="py-3 pr-4">Let's Encrypt / manual</td>
|
||
<td className="py-3 pr-4">Automatic via Caddy + DashCA</td>
|
||
<td className="py-3">Same</td>
|
||
</tr>
|
||
<tr className="border-b border-surface-800">
|
||
<td className="py-3 pr-4">Monitoring</td>
|
||
<td className="py-3 pr-4">Custom scripts</td>
|
||
<td className="py-3 pr-4">Real-time health + Prometheus</td>
|
||
<td className="py-3">Same + fleet dashboard</td>
|
||
</tr>
|
||
<tr className="border-b border-surface-800">
|
||
<td className="py-3 pr-4">Multi-user access</td>
|
||
<td className="py-3 pr-4">None</td>
|
||
<td className="py-3 pr-4">TOTP 2FA + RBAC</td>
|
||
<td className="py-3">SSO (OIDC/SAML)</td>
|
||
</tr>
|
||
<tr className="border-b border-surface-800">
|
||
<td className="py-3 pr-4">Backup & recovery</td>
|
||
<td className="py-3 pr-4">Manual snapshots</td>
|
||
<td className="py-3 pr-4">One-click backup/restore</td>
|
||
<td className="py-3">Same + scheduled</td>
|
||
</tr>
|
||
<tr className="border-b border-surface-800">
|
||
<td className="py-3 pr-4">AI operations</td>
|
||
<td className="py-3 pr-4">None</td>
|
||
<td className="py-3 pr-4">Intent Router + MCP Server</td>
|
||
<td className="py-3">Same</td>
|
||
</tr>
|
||
<tr className="border-b border-surface-800">
|
||
<td className="py-3 pr-4">Multi-host orchestration</td>
|
||
<td className="py-3 pr-4">Manual Swarm/K8s</td>
|
||
<td className="py-3 pr-4">Single host</td>
|
||
<td className="py-3">Swarm + Fleet Management</td>
|
||
</tr>
|
||
<tr>
|
||
<td className="py-3 pr-4">Pricing</td>
|
||
<td className="py-3 pr-4">Time + complexity</td>
|
||
<td className="py-3 pr-4">Free forever</td>
|
||
<td className="py-3">$20–$99 one-time</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
|
||
<h2>Real-world scenarios</h2>
|
||
|
||
<h3>Home lab operator</h3>
|
||
<p>
|
||
You run Plex, Nextcloud, Home Assistant, and a dozen other services on a single NUC. With DashCaddy,
|
||
you deploy each from a template, and every service gets a clean subdomain (<code>plex.local</code>,
|
||
<code>nextcloud.local</code>) with trusted HTTPS. Service Discovery adopts containers you already
|
||
had running, so you don't need to redeploy anything. The dashboard gives you one place to see health,
|
||
restart services, and review logs.
|
||
</p>
|
||
|
||
<h3>Small business internal tools</h3>
|
||
<p>
|
||
Your team needs Gitea, Grafana, and a wiki behind HTTPS with role-based access. DashCaddy Free handles
|
||
deployment, DNS, and certificates. TOTP 2FA and multi-user admin ensure only authorized team members
|
||
can modify infrastructure. Audit logs track who deployed what and when.
|
||
</p>
|
||
|
||
<h3>Multi-site fleet management</h3>
|
||
<p>
|
||
You manage DashCaddy instances across three offices. Premium's Fleet Management gives you a single
|
||
dashboard to monitor all hosts, deploy services to specific sites, and enforce configuration standards.
|
||
Swarm support lets you scale a service across multiple nodes within a site.
|
||
</p>
|
||
|
||
<h2>Premium licensing</h2>
|
||
<p>
|
||
DashCaddy Premium is a one-time purchase (not a subscription) that unlocks advanced orchestration
|
||
features. Pricing tiers:
|
||
</p>
|
||
<ul>
|
||
<li><strong>$20</strong> — 30-day license</li>
|
||
<li><strong>$50</strong> — 90-day license</li>
|
||
<li><strong>$70</strong> — 180-day license</li>
|
||
<li><strong>$99</strong> — 365-day license</li>
|
||
</ul>
|
||
<p>
|
||
Premium features include SSO (OIDC/SAML), Recipes (multi-service deployment blueprints), Docker Swarm
|
||
orchestration, and Fleet Management for multi-host coordination. The core platform is fully functional
|
||
without a license; Premium is for teams that need enterprise-grade access control and multi-site
|
||
visibility.
|
||
</p>
|
||
|
||
<h2>Next steps</h2>
|
||
<ul>
|
||
<li>
|
||
<a href="/docs/installation" className="text-brand-400 hover:text-brand-300 underline">
|
||
Installation Guide
|
||
</a> — get DashCaddy running on your host with the guided installer or manual setup.
|
||
</li>
|
||
<li>
|
||
<a href="/docs/first-service" className="text-brand-400 hover:text-brand-300 underline">
|
||
Deploy Your First Service
|
||
</a> — walk through deploying Plex (or any template) end-to-end.
|
||
</li>
|
||
</ul>
|
||
</DocsLayout>
|
||
<Footer />
|
||
</div>
|
||
);
|
||
}
|