Major site overhaul: reflect all current product features + logo + Stripe Payment Links
Homepage: AI-powered hero, 9 feature cards (AI Intent Router, MCP Server, Security Center, Fleet Management, Service Discovery, Plugin System), expanded comparison table (7→13 rows), Smart Wizard in How It Works Features page: Complete rewrite — 8 feature sections led by AI-Powered Self-Hosting, Free vs Premium comparison grid Pricing page: Fixed broken Stripe checkout (was 503 stub). Subscribe button now uses Stripe Payment Links. Core tier lists all 18 features. All 7 docs pages: Updated to reflect current architecture (AI, MCP, Security Center, SDK, Caddyfile-as-Code, Service Discovery, etc.) About page: AI-Native value prop, updated tech stack, by-the-numbers Navbar: Fixed broken #anchor links → proper routes, added DashCaddy logo AppShowcase: 50+ → 76+ templates Logo: Dark + light versions deployed, wired into navbar/footer/favicon
This commit is contained in:
Krystie
+90
-16
@@ -8,26 +8,100 @@ export default function DocsApiPage() {
|
||||
<Navbar />
|
||||
<DocsLayout
|
||||
title="API and Automation"
|
||||
intro="DashCaddy includes a real API surface for service management, deployment, DNS/proxy automation, certificates, and operational visibility."
|
||||
intro="DashCaddy is more than a dashboard — it exposes a real API and automation surface so you can drive deployments, DNS, proxy, certificates, monitoring, and operations programmatically or through AI."
|
||||
>
|
||||
<h2>What the API is for</h2>
|
||||
<ul>
|
||||
<li>service management</li>
|
||||
<li>app deployment</li>
|
||||
<li>DNS automation</li>
|
||||
<li>Caddy integration</li>
|
||||
<li>certificate-related workflows</li>
|
||||
<li>health and status reporting</li>
|
||||
</ul>
|
||||
<h2>REST API</h2>
|
||||
<p>
|
||||
All platform operations are available under <code>/api/v1/</code>. The API covers service management,
|
||||
app deployment, DNS automation, Caddy reverse-proxy integration, certificate workflows, health and status
|
||||
reporting, user/admin operations, and backup/restore. The repository ships with an OpenAPI definition so the
|
||||
public contract can mature into a full reference.
|
||||
</p>
|
||||
<pre className="mt-4 overflow-x-auto rounded-lg border border-surface-700/50 bg-surface-950/80 p-4 text-sm"><code>{`# List all services
|
||||
curl -H "Authorization: Bearer $TOKEN" \\
|
||||
https://dashcaddy-host/api/v1/services
|
||||
|
||||
# Deploy from a template
|
||||
curl -X POST -H "Authorization: Bearer $TOKEN" \\
|
||||
-H "Content-Type: application/json" \\
|
||||
-d '{"template":" jellyfin","name":"media","hostname":"media.lab"}' \\
|
||||
https://dashcaddy-host/api/v1/services`}</code></pre>
|
||||
|
||||
<h2>JavaScript SDK</h2>
|
||||
<p>
|
||||
For programmatic automation, DashCaddy ships a typed JavaScript SDK with <strong>39 methods</strong> and full
|
||||
<strong> TypeScript types</strong>. It mirrors the REST API and handles authentication, retries, and structured
|
||||
error handling for you.
|
||||
</p>
|
||||
<pre className="mt-4 overflow-x-auto rounded-lg border border-surface-700/50 bg-surface-950/80 p-4 text-sm"><code>{`import { DashCaddy } from '@dashcaddy/sdk';
|
||||
|
||||
const dc = new DashCaddy({ baseUrl: 'https://dashcaddy-host', token: process.env.DC_TOKEN });
|
||||
|
||||
// List services
|
||||
const services = await dc.services.list();
|
||||
|
||||
// Deploy a template
|
||||
const svc = await dc.services.deploy({
|
||||
template: 'jellyfin',
|
||||
name: 'media',
|
||||
hostname: 'media.lab',
|
||||
});
|
||||
|
||||
// Adopt a discovered container
|
||||
await dc.services.adopt({ containerId: 'abc123', hostname: 'wiki.lab' });`}</code></pre>
|
||||
|
||||
<h2>Structured error codes</h2>
|
||||
<p>
|
||||
The API and SDK return <strong>80 structured error codes</strong> rather than opaque messages, so your
|
||||
automation can branch on specific failure conditions (DNS token invalid, Caddy unreachable, license expired,
|
||||
etc.) instead of parsing strings.
|
||||
</p>
|
||||
|
||||
<h2>AI Intent Router</h2>
|
||||
<p>
|
||||
The <strong>AI Intent Router</strong> accepts natural-language commands and translates them into real
|
||||
infrastructure actions through the same API. This turns ad-hoc operator requests into reproducible, logged
|
||||
operations.
|
||||
</p>
|
||||
<pre className="mt-4 overflow-x-auto rounded-lg border border-surface-700/50 bg-surface-950/80 p-4 text-sm"><code>{`# Natural-language operation
|
||||
POST /api/v1/ai/intent
|
||||
{ "message": "Restart the media server and check its health" }`}</code></pre>
|
||||
|
||||
<h2>MCP Server</h2>
|
||||
<p>
|
||||
The built-in <strong>MCP (Model Context Protocol) Server</strong> exposes DashCaddy operations as tools that
|
||||
AI assistants and external automation can call directly. Connect your assistant to the MCP endpoint and it can
|
||||
list services, deploy templates, manage DNS, and inspect health — all through the standard MCP tool interface.
|
||||
</p>
|
||||
|
||||
<h2>WebSocket real-time updates</h2>
|
||||
<p>
|
||||
The dashboard subscribes to a <strong>WebSocket channel</strong> for live updates: service health changes,
|
||||
container starts/stops, deployment progress, and fleet events arrive in real time without polling. You can
|
||||
consume the same channel in your own dashboards or automation.
|
||||
</p>
|
||||
|
||||
<h2>Prometheus metrics endpoint</h2>
|
||||
<p>
|
||||
DashCaddy exposes a Prometheus-format metrics endpoint at <code>/metrics</code> for service health, container
|
||||
status, request counts, and system indicators. Scrape it with Prometheus and visualize in Grafana.
|
||||
</p>
|
||||
<pre className="mt-4 overflow-x-auto rounded-lg border border-surface-700/50 bg-surface-950/80 p-4 text-sm"><code>{`# Health and readiness probes
|
||||
GET /healthz # liveness — is the process up?
|
||||
GET /readyz # readiness — is it ready to serve (deps connected)?`}</code></pre>
|
||||
|
||||
<h2>Plugin & extension hooks</h2>
|
||||
<p>
|
||||
DashCaddy includes a <strong>plugin/extension system</strong> with hooks into the deployment, DNS, proxy, and
|
||||
monitoring pipelines. Write extensions to react to service lifecycle events, inject custom Caddy directives,
|
||||
emit additional metrics, or integrate third-party tools — without forking the core.
|
||||
</p>
|
||||
|
||||
<h2>Why automation matters</h2>
|
||||
<p>
|
||||
DashCaddy is more than a dashboard because it can execute the infrastructure chain around a service, not just show service state after the fact.
|
||||
</p>
|
||||
|
||||
<h2>Reference direction</h2>
|
||||
<p>
|
||||
The repo already includes an OpenAPI file, which means the public API docs can mature into a proper reference section as the external contract is stabilized.
|
||||
DashCaddy can execute the full infrastructure chain around a service, not just report its state after the
|
||||
fact. Between the REST API, the JS SDK, the AI Intent Router, MCP, WebSockets, Prometheus, and the plugin
|
||||
system, you have every surface you need to make DashCaddy a first-class citizen of your automation stack.
|
||||
</p>
|
||||
</DocsLayout>
|
||||
<Footer />
|
||||
|
||||
@@ -8,34 +8,89 @@ export default function DocsFirstServicePage() {
|
||||
<Navbar />
|
||||
<DocsLayout
|
||||
title="Deploy Your First Service"
|
||||
intro="This is where DashCaddy becomes real: you take a service from container or target port to DNS-backed, reverse-proxied, HTTPS-enabled application visible in one dashboard."
|
||||
intro="This is where DashCaddy becomes real: take an app from a template, an existing container, or a raw target port to a DNS-backed, reverse-proxied, HTTPS-enabled service visible in one dashboard — in a few clicks."
|
||||
>
|
||||
<h2>What DashCaddy handles for you</h2>
|
||||
<p>When you deploy a service, DashCaddy automates the full infrastructure chain:</p>
|
||||
<ul>
|
||||
<li>service records</li>
|
||||
<li>app template deployment or manual service definition</li>
|
||||
<li>DNS creation when configured</li>
|
||||
<li>Caddy reverse proxy updates</li>
|
||||
<li>service visibility and health tracking</li>
|
||||
<li>Container deployment (from template) or adoption of an existing container.</li>
|
||||
<li>Service record creation in the DashCaddy state store.</li>
|
||||
<li>DNS record creation through Technitium DNS (when configured).</li>
|
||||
<li>Caddy reverse-proxy route configuration via the Admin API.</li>
|
||||
<li>Automatic TLS certificate issuance through Caddy's internal CA / DashCA.</li>
|
||||
<li>Real-time health tracking and WebSocket status updates on the dashboard.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Typical first deployment flow</h2>
|
||||
<h2>Three ways to add a service</h2>
|
||||
|
||||
<h3>1. Pick from 76+ one-click templates</h3>
|
||||
<p>
|
||||
The template library covers the most popular self-hosted applications — media servers, dashboards,
|
||||
databases, note apps, automation tools, and more. Each template bundles sane defaults for ports,
|
||||
volumes, environment variables, and the recommended subdomain.
|
||||
</p>
|
||||
<ol>
|
||||
<li>Open the dashboard.</li>
|
||||
<li>Choose a template or define a service manually.</li>
|
||||
<li>Provide the service name, hostname/subdomain, and backend target.</li>
|
||||
<li>Let DashCaddy wire DNS and Caddy where configured.</li>
|
||||
<li>Wait for readiness, then verify the service URL.</li>
|
||||
<li>Open the dashboard and choose <strong>New Service → From Template</strong>.</li>
|
||||
<li>Browse or search the 76+ templates.</li>
|
||||
<li>Select an app and confirm the service name, hostname, and any required secrets.</li>
|
||||
<li>Click <strong>Deploy</strong>. DashCaddy pulls the image, starts the container, and wires DNS + Caddy + TLS automatically.</li>
|
||||
</ol>
|
||||
|
||||
<h3>2. Use Service Discovery to auto-detect existing containers</h3>
|
||||
<p>
|
||||
Already running Docker containers? DashCaddy's <strong>Service Discovery</strong> scans the host and lists
|
||||
every running container, marking any that are not yet managed.
|
||||
</p>
|
||||
<ol>
|
||||
<li>Open <strong>Service Discovery</strong> from the sidebar.</li>
|
||||
<li>Review the list of detected containers.</li>
|
||||
<li>For each one you want to manage, click <strong>Adopt</strong>.</li>
|
||||
<li>Provide a hostname/subdomain. DashCaddy generates the Caddy route, DNS record, and certificate.</li>
|
||||
</ol>
|
||||
|
||||
<h3>3. Define a service manually</h3>
|
||||
<p>
|
||||
For custom images or apps not in the template library, define the service by hand:
|
||||
</p>
|
||||
<ol>
|
||||
<li>Choose <strong>New Service → Custom</strong>.</li>
|
||||
<li>Provide the container image or the host:port backend target.</li>
|
||||
<li>Set the hostname/subdomain DashCaddy should publish.</li>
|
||||
<li>Optionally add environment variables, volumes, and port mappings.</li>
|
||||
<li>Deploy — the same DNS + Caddy + TLS wiring applies.</li>
|
||||
</ol>
|
||||
|
||||
<h2>How Docker + Caddy + DNS wire together</h2>
|
||||
<p>
|
||||
The magic is that the three layers are coordinated as a single transaction rather than three manual steps:
|
||||
</p>
|
||||
<ol>
|
||||
<li><strong>Docker</strong> starts (or adopts) the container and exposes the backend port.</li>
|
||||
<li><strong>DashCaddy</strong> writes a Caddy route mapping your chosen hostname to that backend, then applies it through the Caddyfile-as-Code builder and the Caddy Admin API.</li>
|
||||
<li><strong>Caddy</strong> automatically requests and renews a TLS certificate for the hostname via its internal CA (or DashCA).</li>
|
||||
<li><strong>Technitium DNS</strong> creates the A/CNAME record pointing the hostname at the host.</li>
|
||||
<li>The service appears <strong>Healthy</strong> on the dashboard once the health check passes.</li>
|
||||
</ol>
|
||||
<p>
|
||||
If any layer is not configured (for example, no DNS integration), DashCaddy simply skips that step and
|
||||
the service still deploys with whatever layers are available.
|
||||
</p>
|
||||
|
||||
<h2>If the service is internal-only</h2>
|
||||
<p>
|
||||
Verify the client trusts the DashCA root certificate, the internal domain resolves properly, and the route is reachable on the network you intend to use.
|
||||
For services that should stay on the local network, verify three things:
|
||||
</p>
|
||||
<ul>
|
||||
<li>The client device trusts the DashCA root certificate (download it from the DashCA page).</li>
|
||||
<li>The internal domain resolves properly via Technitium DNS or a local resolver.</li>
|
||||
<li>The route is reachable on the network you intend to use.</li>
|
||||
</ul>
|
||||
|
||||
<h2>If the service does not come up correctly</h2>
|
||||
<p>
|
||||
Debug in order: backend process, reverse proxy, DNS, TLS trust, and finally dashboard/API state.
|
||||
Debug in order, layer by layer: backend container, backend port reachability, reverse-proxy route, DNS
|
||||
resolution, TLS trust, then dashboard/API state. See the <a href="/docs/troubleshooting">Troubleshooting</a>
|
||||
guide for the full checklist.
|
||||
</p>
|
||||
</DocsLayout>
|
||||
<Footer />
|
||||
|
||||
@@ -8,44 +8,92 @@ export default function DocsInstallationPage() {
|
||||
<Navbar />
|
||||
<DocsLayout
|
||||
title="Installation Guide"
|
||||
intro="DashCaddy supports both guided installation and manual operator-controlled setup. This guide covers the dependencies and the two practical setup paths."
|
||||
intro="DashCaddy ships as a Docker-based deployment with a guided installer that handles dependency checks, configuration generation, and first launch. This guide covers prerequisites, the installer flow, and what to expect on first run."
|
||||
>
|
||||
<h2>Prerequisites</h2>
|
||||
<p>Before installing, make sure the host has the following:</p>
|
||||
<ul>
|
||||
<li>Docker and Docker Compose</li>
|
||||
<li>Caddy with Admin API access</li>
|
||||
<li>Node.js 18+ for the API server</li>
|
||||
<li>Technitium DNS if you want DNS automation</li>
|
||||
<li><strong>Docker</strong> and <strong>Docker Compose</strong> — the runtime foundation for all DashCaddy services.</li>
|
||||
<li><strong>Node.js 20+</strong> — required for the DashCaddy API server.</li>
|
||||
<li><strong>Caddy</strong> with Admin API access enabled — the reverse proxy and HTTPS layer.</li>
|
||||
<li><strong>Technitium DNS</strong> — optional, but recommended for automatic DNS record management.</li>
|
||||
<li>A static host or stable IP if you plan to expose services beyond the local network.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Installer-based setup</h2>
|
||||
<h2>Quick start with start.sh</h2>
|
||||
<p>
|
||||
DashCaddy includes a dedicated installer intended to walk users through dependency checks, file deployment,
|
||||
configuration generation, and first launch.
|
||||
The fastest path to a running DashCaddy is the bundled <code>start.sh</code> script. It performs environment
|
||||
checks, pulls the required containers, generates configuration, and brings the stack up.
|
||||
</p>
|
||||
<pre className="mt-4 overflow-x-auto rounded-lg border border-surface-700/50 bg-surface-950/80 p-4 text-sm"><code>{`# Clone the repository
|
||||
git clone https://github.com/samiahmed7777/dashcaddy.git
|
||||
cd dashcaddy
|
||||
|
||||
# Make the launcher executable and run it
|
||||
chmod +x start.sh
|
||||
./start.sh`}</code></pre>
|
||||
<p>
|
||||
The script is idempotent — re-running it will reconcile the stack rather than clobber an existing install.
|
||||
</p>
|
||||
|
||||
<h2>The guided installer</h2>
|
||||
<p>
|
||||
For users who prefer a walk-through, DashCaddy includes a dedicated installer that steps through:
|
||||
</p>
|
||||
<ol>
|
||||
<li><strong>Dependency checks</strong> — verifies Docker, Node.js, and Caddy are present and reachable.</li>
|
||||
<li><strong>Path selection</strong> — chooses where state, configs, and certificates are stored.</li>
|
||||
<li><strong>Configuration generation</strong> — writes environment files and Caddy/DNS integration settings.</li>
|
||||
<li><strong>Container deployment</strong> — pulls images and starts the API, dashboard, and supporting services.</li>
|
||||
<li><strong>First-launch validation</strong> — confirms the API responds and the dashboard loads.</li>
|
||||
</ol>
|
||||
|
||||
<h2>First launch & the Smart Defaults Wizard</h2>
|
||||
<p>
|
||||
On first launch the dashboard opens to the <strong>Smart Defaults Wizard</strong>. It surveys your host and
|
||||
pre-fills sensible choices so you can go from install to a working deployment in minutes:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Detects the Caddy Admin API endpoint and validates connectivity.</li>
|
||||
<li>Detects Technitium DNS (if installed) and configures the API token and zone.</li>
|
||||
<li>Proposes a base domain and naming convention for new services.</li>
|
||||
<li>Initializes the internal certificate authority (DashCA) and offers the root certificate for download.</li>
|
||||
<li>Creates the initial admin account and offers TOTP 2FA enrollment.</li>
|
||||
</ul>
|
||||
<p>
|
||||
Every default is editable — the wizard simply gives you a known-good starting point instead of a blank slate.
|
||||
</p>
|
||||
|
||||
<h2>Manual setup</h2>
|
||||
<p>
|
||||
Manual setup is best when you want direct control over paths, services, Caddy, DNS integration, and deployment layout.
|
||||
If you want direct control over paths, services, Caddy, and DNS integration, you can deploy manually:
|
||||
</p>
|
||||
<ol>
|
||||
<li>Clone the software repo.</li>
|
||||
<li>Install the API dependencies.</li>
|
||||
<li>Clone the repository.</li>
|
||||
<li>Install the API dependencies (<code>npm ci</code>).</li>
|
||||
<li>Prepare Caddy and confirm the Admin API is reachable.</li>
|
||||
<li>Prepare Technitium DNS if using automatic DNS changes.</li>
|
||||
<li>Configure environment and state paths.</li>
|
||||
<li>Start the DashCaddy API.</li>
|
||||
<li>Prepare Technitium DNS if you want automatic DNS changes.</li>
|
||||
<li>Configure environment variables and state paths.</li>
|
||||
<li>Start the DashCaddy API (<code>npm run start</code> or via your process manager).</li>
|
||||
<li>Serve the dashboard through Caddy.</li>
|
||||
</ol>
|
||||
|
||||
<h2>Post-install checks</h2>
|
||||
<p>After the stack is up, verify each layer:</p>
|
||||
<ul>
|
||||
<li>Dashboard loads in browser</li>
|
||||
<li>API responds correctly</li>
|
||||
<li>Caddy Admin API is reachable</li>
|
||||
<li>Service management UI loads</li>
|
||||
<li>DNS/certificate integration is healthy if configured</li>
|
||||
<li>The dashboard loads in your browser.</li>
|
||||
<li>The API responds — check <code>/healthz</code> and <code>/readyz</code>.</li>
|
||||
<li>The Caddy Admin API is reachable from the API server.</li>
|
||||
<li>The service management UI loads and lists the host's containers.</li>
|
||||
<li>DNS and certificate integration report healthy (if configured).</li>
|
||||
<li>Prometheus metrics are exposed at <code>/metrics</code> (if scraping is enabled).</li>
|
||||
</ul>
|
||||
|
||||
<h2>Next steps</h2>
|
||||
<p>
|
||||
Once install checks pass, head to the <a href="/docs/first-service">Deploy Your First Service</a> guide to
|
||||
bring your first application online.
|
||||
</p>
|
||||
</DocsLayout>
|
||||
<Footer />
|
||||
</div>
|
||||
|
||||
@@ -8,32 +8,83 @@ export default function DocsIntegrationsPage() {
|
||||
<Navbar />
|
||||
<DocsLayout
|
||||
title="Infrastructure Integrations"
|
||||
intro="DashCaddy is most valuable when its supporting integrations are healthy. This guide explains the layers it expects to work with and how they fit together."
|
||||
intro="DashCaddy is most valuable when its supporting integrations are healthy. This guide explains each layer it expects to work with, what it does, and how the pieces fit together into a single control plane."
|
||||
>
|
||||
<h2>Docker</h2>
|
||||
<p>
|
||||
Docker is the runtime foundation for deployment workflows, container lifecycle actions, and app-template based launches.
|
||||
Docker (and Docker Compose) is the runtime foundation for deployment workflows, container lifecycle actions,
|
||||
service discovery, and template-based launches. DashCaddy talks to the Docker daemon to start, stop, restart,
|
||||
inspect, and adopt containers, and to deploy the 76+ one-click application templates. Optional Docker Swarm
|
||||
support (Premium) extends the same model across multiple nodes.
|
||||
</p>
|
||||
|
||||
<h2>Caddy</h2>
|
||||
<h2>Caddy — reverse proxy & HTTPS</h2>
|
||||
<p>
|
||||
Caddy is the reverse proxy and HTTPS publication layer. DashCaddy relies on the Caddy Admin API to manage routes and exposure.
|
||||
Caddy is the reverse proxy and automatic HTTPS layer. DashCaddy communicates with the <strong>Caddy Admin API</strong>
|
||||
to create, update, and remove routes, and to trigger certificate issuance. Caddy's built-in internal CA
|
||||
auto-generates and renews certificates for every published service.
|
||||
</p>
|
||||
|
||||
<h3>Caddyfile-as-Code</h3>
|
||||
<p>
|
||||
Instead of hand-editing Caddyfiles, DashCaddy exposes a <strong>visual Caddyfile-as-Code builder</strong>. You
|
||||
describe the desired route — hostname, upstream, TLS options, headers, redirects — and DashCaddy generates the
|
||||
valid Caddy configuration and applies it atomically through the Admin API. Configuration is versioned and
|
||||
reviewable, so changes are auditable and reversible.
|
||||
</p>
|
||||
|
||||
<h2>Technitium DNS</h2>
|
||||
<p>
|
||||
Technitium DNS is the documented DNS automation target for record creation and removal.
|
||||
Technitium DNS is the DNS automation target for record creation and removal. When you deploy or adopt a service,
|
||||
DashCaddy creates the corresponding A/CNAME record through the Technitium API so the new hostname resolves
|
||||
immediately. Removing a service cleans up the record automatically.
|
||||
</p>
|
||||
|
||||
<h2>DashCA</h2>
|
||||
<h2>DashCA — internal certificate authority</h2>
|
||||
<p>
|
||||
DashCA is the certificate distribution system that makes internal HTTPS practical by letting users trust the local CA across devices.
|
||||
DashCA is the certificate distribution system that makes internal HTTPS practical. Caddy's internal CA
|
||||
issues certificates automatically; DashCA provides the distribution page where you download the root
|
||||
certificate and install it as a trusted CA across your devices. Once trusted, every internal service is served
|
||||
over valid HTTPS with no browser warnings.
|
||||
</p>
|
||||
|
||||
<h2>Private access layers</h2>
|
||||
<h2>Tailscale — private access</h2>
|
||||
<p>
|
||||
DashCaddy also fits well into private/internal access patterns where services should not be directly exposed to the public internet.
|
||||
DashCaddy fits naturally into private access patterns with <strong>Tailscale</strong>. Services can be published
|
||||
only on a Tailnet, keeping them off the public internet while still benefiting from DashCaddy's DNS, proxy,
|
||||
and TLS automation. This is ideal for home labs and internal team tools.
|
||||
</p>
|
||||
|
||||
<h2>Prometheus & Grafana — metrics</h2>
|
||||
<p>
|
||||
DashCaddy exports metrics in Prometheus format at <code>/metrics</code>, including service health, container
|
||||
status, request counts, and system indicators. Point your Prometheus scraper at the endpoint and build
|
||||
Grafana dashboards on top for long-term observability and alerting.
|
||||
</p>
|
||||
<pre className="mt-4 overflow-x-auto rounded-lg border border-surface-700/50 bg-surface-950/80 p-4 text-sm"><code>{`# prometheus.yml scrape config
|
||||
scrape_configs:
|
||||
- job_name: 'dashcaddy'
|
||||
metrics_path: /metrics
|
||||
static_configs:
|
||||
- targets: ['dashcaddy-host:3000']`}</code></pre>
|
||||
|
||||
<h2>MCP & AI assistants</h2>
|
||||
<p>
|
||||
The built-in <strong>MCP Server</strong> exposes DashCaddy operations to AI assistants and external automation.
|
||||
Combined with the <strong>AI Intent Router</strong>, you can issue natural-language commands
|
||||
(“restart the media server”, “deploy the postgres template”) and have DashCaddy execute
|
||||
the real infrastructure action. See the <a href="/docs/api">API and Automation</a> guide for details.
|
||||
</p>
|
||||
|
||||
<h2>How the layers fit together</h2>
|
||||
<ul>
|
||||
<li><strong>Deploy / Adopt</strong> → Docker runs the container.</li>
|
||||
<li><strong>Publish</strong> → Caddy creates the reverse-proxy route and TLS cert.</li>
|
||||
<li><strong>Resolve</strong> → Technitium DNS creates the hostname record.</li>
|
||||
<li><strong>Trust</strong> → DashCA distributes the root CA for internal HTTPS.</li>
|
||||
<li><strong>Observe</strong> → health checks + Prometheus + WebSocket live updates.</li>
|
||||
<li><strong>Secure</strong> → Security Center aggregates events; audit logging records every change.</li>
|
||||
</ul>
|
||||
</DocsLayout>
|
||||
<Footer />
|
||||
</div>
|
||||
|
||||
@@ -8,37 +8,75 @@ export default function DocsOverviewPage() {
|
||||
<Navbar />
|
||||
<DocsLayout
|
||||
title="Product Overview"
|
||||
intro="DashCaddy is a self-hosted control plane for deploying, exposing, and managing Docker applications with DNS automation, reverse proxy integration, internal HTTPS, and centralized service visibility."
|
||||
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 DashCaddy is</h2>
|
||||
<p>
|
||||
DashCaddy brings together the layers that self-hosters usually wire by hand: Docker deployment,
|
||||
reverse proxy management through Caddy, DNS automation through Technitium DNS, internal certificate
|
||||
distribution through DashCA, service monitoring, and operational controls.
|
||||
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>
|
||||
The goal is simple: make running self-hosted services feel cohesive instead of fragmented.
|
||||
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 a layered stack:
|
||||
</p>
|
||||
<ul>
|
||||
<li><strong>Application layer</strong> — a React dashboard for operators, plus a REST API and WebSocket channel for real-time updates.</li>
|
||||
<li><strong>Orchestration layer</strong> — a Node.js/Express engine that drives deployments, service lifecycle, DNS, reverse proxy, and certificates.</li>
|
||||
<li><strong>Runtime layer</strong> — Docker and Docker Compose for container workloads, with optional Docker Swarm and multi-host fleet support.</li>
|
||||
<li><strong>Edge layer</strong> — Caddy as the reverse proxy and automatic HTTPS termination, managed through its Admin API.</li>
|
||||
<li><strong>Name resolution layer</strong> — Technitium DNS for programmatic record creation and removal.</li>
|
||||
<li><strong>Trust layer</strong> — Caddy's internal CA and the optional DashCA certificate authority for trusted internal HTTPS.</li>
|
||||
<li><strong>Observability layer</strong> — real-time health checks, Prometheus metrics export, and structured audit logging.</li>
|
||||
<li><strong>Intelligence layer</strong> — an AI Intent Router for natural-language operations and an MCP Server for AI assistant integration.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Core product components</h2>
|
||||
<ul>
|
||||
<li><strong>Dashboard</strong>: the main operator interface for service visibility and management.</li>
|
||||
<li><strong>DashCaddy API</strong>: the orchestration engine for deployments, DNS, reverse proxy, certificates, and operational tooling.</li>
|
||||
<li><strong>Installer</strong>: a guided installation path for users who want faster setup.</li>
|
||||
<li><strong>DashCA</strong>: the internal certificate authority distribution surface for trusted internal HTTPS.</li>
|
||||
<li><strong>Licensing</strong>: Premium feature gating tied to external validation/deactivation flows.</li>
|
||||
<li><strong>Dashboard</strong> — the main operator interface for service visibility, deployment, fleet management, and operational controls.</li>
|
||||
<li><strong>DashCaddy API</strong> — the orchestration engine under <code>/api/v1/</code> for deployments, DNS, reverse proxy, certificates, monitoring, and operational tooling.</li>
|
||||
<li><strong>Template Library</strong> — 76+ one-click Docker application templates covering the most popular self-hosted apps.</li>
|
||||
<li><strong>Service Discovery</strong> — auto-detection of existing containers on the host with one-click adoption into a managed service.</li>
|
||||
<li><strong>Caddyfile-as-Code</strong> — a visual reverse-proxy builder that generates and applies Caddy configuration without manual edits.</li>
|
||||
<li><strong>DashCA</strong> — the internal certificate authority distribution surface for trusted internal HTTPS across devices.</li>
|
||||
<li><strong>Security Center</strong> — a multi-source event pipeline aggregating logs and signals for threat detection and audit.</li>
|
||||
<li><strong>AI Intent Router</strong> — turn natural-language commands into real infrastructure actions.</li>
|
||||
<li><strong>MCP Server</strong> — expose DashCaddy operations to AI assistants and external automation.</li>
|
||||
<li><strong>Licensing</strong> — Premium feature gating tied to external validation and deactivation flows.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Who DashCaddy is for</h2>
|
||||
<p>
|
||||
DashCaddy is built for self-hosters, home lab operators, small teams, and administrators who want one place to deploy apps,
|
||||
publish them cleanly, trust internal HTTPS, and keep service infrastructure under control.
|
||||
</p>
|
||||
<ul>
|
||||
<li><strong>Home lab operators</strong> who want one place to deploy apps, publish them cleanly, and trust internal HTTPS.</li>
|
||||
<li><strong>Self-hosters</strong> tired of hand-wiring Docker, Caddy, DNS, and certificates for every new service.</li>
|
||||
<li><strong>Small teams and businesses</strong> that need multi-user access, RBAC, SSO, and audit trails.</li>
|
||||
<li><strong>Platform administrators</strong> managing fleets of services across one host or many, with monitoring and backup at the core.</li>
|
||||
</ul>
|
||||
|
||||
<h2>What makes it production-grade</h2>
|
||||
<ul>
|
||||
<li><strong>76+ vetted templates</strong> for one-click deployment of popular self-hosted software.</li>
|
||||
<li><strong>Real-time monitoring</strong> with WebSocket live dashboard updates and Prometheus metrics export.</li>
|
||||
<li><strong>Multi-user security</strong> — TOTP 2FA, email magic-link login, admin invites, RBAC, encrypted credential vault, and audit logging.</li>
|
||||
<li><strong>Security Center</strong> — a multi-source event pipeline for centralized security visibility.</li>
|
||||
<li><strong>Backup & disaster recovery</strong> — one-click backup/restore with SHA-256 checksums for full-system recovery.</li>
|
||||
<li><strong>Internationalization</strong> — 5 supported languages out of the box.</li>
|
||||
<li><strong>Developer platform</strong> — a JavaScript SDK with 39 methods and full TypeScript types, structured error codes (80 codes), and a plugin/extension system.</li>
|
||||
<li><strong>AI-native</strong> — natural-language operations via the Intent Router and AI assistant integration via MCP.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Ownership and licensing</h2>
|
||||
<p>
|
||||
DashCaddy is proprietary software and intellectual property of <strong>samiahmed7777</strong>. Public-facing documentation and branding
|
||||
should reflect that commercial/proprietary positioning rather than an open-source default.
|
||||
DashCaddy is proprietary software and intellectual property of <strong>samiahmed7777</strong>. Public-facing
|
||||
documentation and branding reflect that commercial/proprietary positioning rather than an open-source default.
|
||||
The core platform is fully useful without a license; Premium unlocks a focused set of advanced orchestration features.
|
||||
</p>
|
||||
</DocsLayout>
|
||||
<Footer />
|
||||
|
||||
@@ -8,30 +8,73 @@ export default function DocsPremiumPage() {
|
||||
<Navbar />
|
||||
<DocsLayout
|
||||
title="Premium Features"
|
||||
intro="DashCaddy keeps its Premium model intentionally narrow. The core platform remains useful without a license, while Premium unlocks a small set of advanced orchestration features."
|
||||
intro="DashCaddy keeps its Premium model intentionally narrow. The core platform — deployment, DNS, reverse proxy, HTTPS, monitoring, templates, service discovery, and the API — is fully useful without a license. Premium unlocks a focused set of advanced orchestration features."
|
||||
>
|
||||
<h2>Free vs Premium at a glance</h2>
|
||||
<ul>
|
||||
<li><strong>Free</strong>: full dashboard, 76+ templates, service discovery, Caddy + DNS + TLS automation, real-time monitoring, Prometheus metrics, multi-user with 2FA & RBAC, Security Center, AI Intent Router, MCP Server, JS SDK, backup/restore, and single-host operation.</li>
|
||||
<li><strong>Premium</strong>: everything in Free, plus Auto-Login SSO, Recipes, Docker Swarm, and Multi-Host Fleet Management — plus priority support.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Premium-gated features</h2>
|
||||
<ul>
|
||||
<li><strong>SSO</strong>: Auto-Login SSO</li>
|
||||
<li><strong>Recipes</strong>: multi-container stack deployment</li>
|
||||
<li><strong>Swarm</strong>: Docker Swarm multi-node orchestration</li>
|
||||
<li>
|
||||
<strong>Auto-Login SSO</strong> — single sign-on across services so authenticated users reach their apps
|
||||
without repeated logins. Ideal for teams that want a seamless internal portal experience.
|
||||
</li>
|
||||
<li>
|
||||
<strong>Recipes</strong> — deploy multi-container application stacks (e.g. an app + database + cache) as a
|
||||
single coordinated unit. Recipes bundle several templates together with pre-wired networking so complex
|
||||
stacks come up in one click.
|
||||
</li>
|
||||
<li>
|
||||
<strong>Docker Swarm</strong> — multi-node orchestration. Run services across a Swarm cluster instead of a
|
||||
single host, with DashCaddy managing placement, routing, and TLS across the cluster.
|
||||
</li>
|
||||
<li>
|
||||
<strong>Multi-Host Fleet Management</strong> — manage DashCaddy deployments across multiple hosts from one
|
||||
control plane. Deploy, monitor, and operate services across an entire fleet with unified visibility.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h2>Current plan model</h2>
|
||||
<h2>Pricing</h2>
|
||||
<p>One Premium tier, subscription billing, no hidden upsells:</p>
|
||||
<ul>
|
||||
<li>1 month — $25</li>
|
||||
<li>3 months — $50</li>
|
||||
<li>6 months — $65</li>
|
||||
<li>12 months — $99</li>
|
||||
<li><strong>1 month</strong> — $25</li>
|
||||
<li><strong>3 months</strong> — $50</li>
|
||||
<li><strong>6 months</strong> — $65</li>
|
||||
<li><strong>12 months</strong> — $99</li>
|
||||
</ul>
|
||||
<p>
|
||||
Subscriptions only, one Premium tier, one active machine at a time, 7-day grace period, cancel at period end, and no free trial.
|
||||
Longer commitments are rewarded: the 12-month plan works out to roughly $8.25/month versus $25/month for a
|
||||
single month.
|
||||
</p>
|
||||
|
||||
<h2>License behavior</h2>
|
||||
<h2>Plan terms</h2>
|
||||
<ul>
|
||||
<li>Subscriptions only — no perpetual licenses.</li>
|
||||
<li>One Premium tier (no tier ladder to navigate).</li>
|
||||
<li>One active machine at a time per license.</li>
|
||||
<li><strong>7-day grace period</strong> after expiry so services keep running while you renew.</li>
|
||||
<li>Cancel at period end — no mid-cycle lock-in.</li>
|
||||
<li>No free trial.</li>
|
||||
</ul>
|
||||
|
||||
<h2>License validation</h2>
|
||||
<p>
|
||||
DashCaddy’s app-side licensing is already built around an external validation and deactivation service, rather than unlimited static license reuse.
|
||||
DashCaddy's licensing is built around an <strong>external validation and deactivation service</strong>,
|
||||
not unlimited static license reuse. On launch and periodically thereafter, the platform validates the license
|
||||
against the licensing server. This keeps licenses tied to a single active machine and supports clean
|
||||
deactivation when you move hosts.
|
||||
</p>
|
||||
|
||||
<h2>How to subscribe</h2>
|
||||
<ol>
|
||||
<li>Open the dashboard and go to <strong>Settings → Licensing</strong>.</li>
|
||||
<li>Choose a plan duration and complete checkout.</li>
|
||||
<li>Your license key is validated automatically — Premium features unlock immediately.</li>
|
||||
<li>Manage renewal, cancellation, and machine deactivation from the same panel.</li>
|
||||
</ol>
|
||||
</DocsLayout>
|
||||
<Footer />
|
||||
</div>
|
||||
|
||||
@@ -8,30 +8,88 @@ export default function DocsTroubleshootingPage() {
|
||||
<Navbar />
|
||||
<DocsLayout
|
||||
title="Troubleshooting"
|
||||
intro="Because DashCaddy sits across runtime, DNS, reverse proxy, certificates, and dashboard state, the fastest way to debug it is layer by layer instead of guessing."
|
||||
intro="Because DashCaddy sits across runtime, DNS, reverse proxy, certificates, and dashboard state, the fastest way to debug it is layer by layer instead of guessing. This guide walks each layer with the common failures and fixes."
|
||||
>
|
||||
<h2>Debug order</h2>
|
||||
<h2>Health check endpoints</h2>
|
||||
<p>
|
||||
Start every investigation with the built-in probes — they tell you whether the platform itself is healthy and
|
||||
whether its dependencies are wired up:
|
||||
</p>
|
||||
<ul>
|
||||
<li><code>/healthz</code> — <strong>liveness</strong>. Returns 200 if the DashCaddy process is up.</li>
|
||||
<li><code>/readyz</code> — <strong>readiness</strong>. Returns 200 only when DashCaddy can serve traffic, including connectivity to Docker, Caddy, and DNS where configured.</li>
|
||||
</ul>
|
||||
<pre className="mt-4 overflow-x-auto rounded-lg border border-surface-700/50 bg-surface-950/80 p-4 text-sm"><code>{`curl -s -o /dev/null -w "%{http_code}" https://dashcaddy-host/healthz
|
||||
curl -s -o /dev/null -w "%{http_code}" https://dashcaddy-host/readyz`}</code></pre>
|
||||
<p>
|
||||
If <code>/healthz</code> fails, the DashCaddy process itself is down. If <code>/healthz</code> passes but
|
||||
<code>/readyz</code> fails, a dependency (Docker socket, Caddy Admin API, or Technitium DNS) is unreachable.
|
||||
</p>
|
||||
|
||||
<h2>The debug order</h2>
|
||||
<p>Work bottom-up through the stack so you isolate the failing layer:</p>
|
||||
<ol>
|
||||
<li>backend process or container</li>
|
||||
<li>service port reachability</li>
|
||||
<li>reverse proxy route</li>
|
||||
<li>DNS</li>
|
||||
<li>certificate trust</li>
|
||||
<li>dashboard/API visibility</li>
|
||||
<li><strong>Backend container</strong> — is it running and healthy?</li>
|
||||
<li><strong>Backend port</strong> — is the service listening and reachable on the host?</li>
|
||||
<li><strong>Reverse proxy route</strong> — did Caddy apply the route correctly?</li>
|
||||
<li><strong>DNS</strong> — does the hostname resolve to the right host?</li>
|
||||
<li><strong>Certificate trust</strong> — does the client trust the CA?</li>
|
||||
<li><strong>Dashboard / API state</strong> — does DashCaddy reflect reality?</li>
|
||||
</ol>
|
||||
|
||||
<h2>Common failures</h2>
|
||||
<h2>DNS issues</h2>
|
||||
<ul>
|
||||
<li>service is down even though the dashboard is reachable</li>
|
||||
<li>internal HTTPS shows warnings because DashCA trust is missing</li>
|
||||
<li>DNS automation fails due to API token or zone issues</li>
|
||||
<li>Caddy changes are not applying because Admin API is unavailable</li>
|
||||
<li>Premium features do not unlock because license validation is failing</li>
|
||||
<li><strong>Symptom</strong>: hostname does not resolve, or resolves to the wrong address.</li>
|
||||
<li><strong>Check</strong>: is Technitium DNS running and is the DashCaddy API token valid?</li>
|
||||
<li><strong>Check</strong>: is the record present in the correct zone? DNS automation fails silently when the zone name is wrong.</li>
|
||||
<li><strong>Check</strong>: is the client using Technitium as its resolver? Public resolvers will not know about internal zones.</li>
|
||||
<li><strong>Fix</strong>: re-run the DNS step from the service's action menu, or recreate the record manually and let DashCaddy reconcile.</li>
|
||||
</ul>
|
||||
<pre className="mt-4 overflow-x-auto rounded-lg border border-surface-700/50 bg-surface-950/80 p-4 text-sm"><code>{`# Verify resolution against the Technitium resolver directly
|
||||
dig @technitium-host media.lab
|
||||
nslookup media.lab technitium-host`}</code></pre>
|
||||
|
||||
<h2>TLS / certificate problems</h2>
|
||||
<ul>
|
||||
<li><strong>Symptom</strong>: browser shows a certificate warning or <code>NET::ERR_CERT_AUTHORITY_INVALID</code>.</li>
|
||||
<li><strong>Cause</strong>: the client does not trust Caddy's internal CA / DashCA root certificate.</li>
|
||||
<li><strong>Fix</strong>: download the root certificate from the <strong>DashCA</strong> page and install it as a trusted root CA on the client device. Every modern OS and browser has a slightly different import flow — the DashCA page includes per-platform instructions.</li>
|
||||
<li><strong>Cause</strong>: certificate issuance failed because the Caddy Admin API was unreachable at deploy time.</li>
|
||||
<li><strong>Fix</strong>: confirm the Caddy Admin API is reachable, then redeploy or re-trigger TLS for the service.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Reverse proxy debugging (Caddy)</h2>
|
||||
<ul>
|
||||
<li><strong>Symptom</strong>: service is up and DNS resolves, but the URL returns 502/504 or does not route.</li>
|
||||
<li><strong>Check</strong>: is the Caddy Admin API reachable from the DashCaddy API server?</li>
|
||||
<li><strong>Check</strong>: does the Caddy route point at the correct upstream host:port? Use the Caddyfile-as-Code view to inspect the generated config.</li>
|
||||
<li><strong>Check</strong>: Caddy logs — <code>docker logs caddy</code> or your Caddy service logs — for upstream connection errors.</li>
|
||||
<li><strong>Fix</strong>: re-apply the route from the service's action menu; DashCaddy will reconcile the Caddy configuration atomically.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Container health</h2>
|
||||
<ul>
|
||||
<li><strong>Symptom</strong>: service shows <em>Unhealthy</em> or <em>Down</em> on the dashboard.</li>
|
||||
<li><strong>Check</strong>: <code>docker ps -a</code> and <code>docker logs <container></code> for crash loops or misconfiguration.</li>
|
||||
<li><strong>Check</strong>: does the container's healthcheck (if defined) pass? DashCaddy surfaces container healthchecks in the UI.</li>
|
||||
<li><strong>Check</strong>: are volumes and environment variables correct? Bad secrets are the most common cause of immediate exits.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Common gotchas</h2>
|
||||
<ul>
|
||||
<li><strong>Service is down even though the dashboard is reachable</strong> — the dashboard and the service are different containers; always check the backend container directly.</li>
|
||||
<li><strong>DNS automation fails silently</strong> — usually an expired or wrong-scope Technitium API token, or a mismatched zone name.</li>
|
||||
<li><strong>Caddy changes are not applying</strong> — the Admin API is unavailable or the generated config is invalid; check the Caddyfile-as-Code view for errors.</li>
|
||||
<li><strong>Premium features do not unlock</strong> — license validation is failing; verify the license key and that the host can reach the licensing server, and remember the one-active-machine limit.</li>
|
||||
<li><strong>Internal HTTPS still warns after install</strong> — the root CA must be trusted on <em>each</em> client device, not just the server.</li>
|
||||
<li><strong>WebSocket live updates stall</strong> — a reverse proxy or firewall in front of DashCaddy may be dropping the upgrade; allow WebSocket upgrades on the DashCaddy route.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Mindset</h2>
|
||||
<p>
|
||||
Most DashCaddy problems are really one dependency layer failing while the others are healthy. Debugging that dependency chain is the right way to recover quickly.
|
||||
Most DashCaddy problems are really one dependency layer failing while the others are healthy. Use the health
|
||||
endpoints to localize, then walk the debug order. Fixing the right layer first is always faster than
|
||||
reloading the whole stack.
|
||||
</p>
|
||||
</DocsLayout>
|
||||
<Footer />
|
||||
|
||||
Reference in New Issue
Block a user