← All posts
7 min readDashCaddy Team

Getting Started with DashCaddy: From Blank Server to a Running App

dashcaddy getting startedself-host appsdocker deploymentbeginner homelabself-hosting tutorial

Self-hosting means running software on hardware you control. The part that stops most people is everything around the app: the container, the reverse proxy, the DNS record, the certificate. A self-hosting platform handles that layer so installing a password manager becomes one decision instead of twenty. What a self-hosting platform is covers the bigger picture.

This walkthrough takes you from a bare Linux box to your first app running behind a real HTTPS URL, using Vaultwarden as the example because it is small, useful, and a good first pick.

What DashCaddy does for you

DashCaddy is a control plane for Docker applications. When you deploy a service, it creates the container, writes the Caddy reverse-proxy route, creates the DNS record, issues the HTTPS certificate, and starts health checks. Apps get a subdomain and a padlock without you touching a config file. See the overview for the layers; here we get one running.

What you need before you start

  • A Linux host that stays on. Ubuntu 22.04 LTS, Debian 12, or any recent distribution. A spare mini-PC, an old desktop, or a cheap VPS works. 2 GB of RAM and a few GB of disk is enough.
  • Root or sudo access. The installer writes to /etc/dashcaddy, /opt/dockerdata, and the Docker daemon.
  • Ports 80 and 443 reachable if you want public HTTPS.
  • A domain, if you want automatic DNS and SSL. A real domain gets a trusted certificate automatically; a custom TLD like dashcaddy.home works on your LAN instead.
  • Docker does not have to be installed already. If it is missing, the installer adds Docker Engine and the Compose plugin.

Install DashCaddy with one command

On the host you want to use, run:

curl -fsSL https://get.dashcaddy.net | bash

Answer the prompts (domain, install location, storage size); the defaults are sensible. The installer runs seven idempotent steps; re-running it reconciles an existing install rather than clobbering it:

  1. Detects your environment (OS, package manager, disk, memory, IP addresses)
  2. Installs Docker Engine and the Compose plugin if missing
  3. Writes configuration to /etc/dashcaddy and /opt/dockerdata
  4. Builds the DashCaddy container image
  5. Starts the API container, dashcaddy-api, on port 3001
  6. Waits for the API to answer its /healthz check
  7. Prints the dashboard URL

If a step fails, it stops and tells you what to re-run. The installation guide covers the details.

The scripted install variant

To install without prompts, pass your domain inline:

curl -fsSL https://get.dashcaddy.net | bash -s -- --domain dashcaddy.example.com

This is the non-interactive form; you can pass a custom TLD or a quick local address instead.

Open the dashboard for the first time

Open the URL the installer printed. The docs use https://dashcaddy.home as the default dashboard address, but the hostname is configurable, so yours may differ.

On first visit you land on the setup wizard, which runs once and saves your choices:

  1. Pick a configuration profile (Professional Home Lab, Simple, or Public for an internet-exposed VPS)
  2. Configure your network (your domain and the LAN IP used for routing)
  3. Set storage limits (a cap on Docker data and free-space headroom)
  4. Review your choices
  5. Confirm disk safety

Then create your first admin account and enroll a TOTP authenticator. Store the recovery codes somewhere safe.

Deploy your first app: Vaultwarden

Vaultwarden is a lightweight, Bitwarden-compatible password manager. It is a good first deployment: a single small container in the Security category, no media library or host paths required, and immediately useful. It follows the same path any template does, which one-click Docker deployment describes in general terms.

Deploy it from the dashboard

  1. Sign in, then click the App Selector button on the dashboard home page.
  2. Pick Vaultwarden from the Security category. The template uses the image vaultwarden/server:latest.
  3. Fill in the deployment form: subdomain (the suggested default is vault) and host port (the default is 8088).
  4. Click Deploy.

DashCaddy pulls the image, creates the persistent volume, writes the Caddy route, creates the DNS record, and waits up to 30 seconds for the container's health check on / to pass. It is atomic: if a step fails, the deployment rolls back rather than leaving a half-wired service. Other templates follow the same flow, documented in deploy your first service.

When the service card shows Running, the URL becomes clickable. It is built from your subdomain and configured TLD, so a host using the .home TLD gives you https://vault.home.

Deploy it from the API instead

Everything the dashboard does is also a REST call:

curl -X POST https://dashcaddy.home/api/v1/apps/deploy \
  -H "X-API-Key: $DASHCADDY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "appId": "vaultwarden",
    "config": { "subdomain": "vault", "port": 8088 }
  }'

The response is synchronous and includes success, containerId, url, message, and setupInstructions. There is no separate status-poll endpoint; the dashboard updates live. See the API docs for the full surface and the Vaultwarden entry for its volume path and environment variables.

There is also an AI path: POST /api/v1/ai/intent returns a structured intent from plain English but does not deploy; your client or the built-in MCP server then calls /api/v1/apps/deploy.

Verify it actually works

Open the URL and check the padlock. Browse to https://vault.<your-tld>. A real domain gets a trusted Let's Encrypt certificate automatically; a custom TLD is trusted once the DashCA root certificate is installed on the device. A browser warning means the app runs but trust is not set up yet.

Restart the container and confirm data persists. Vaultwarden stores its data in the host volume /opt/vaultwarden/data:/data. Restart the container from the dashboard (or docker restart <containerId>) and confirm your account is still there. Containers are disposable; volumes are not, and this proves your data is on disk.

DashCaddy keeps watching: a health check runs every 30 seconds, and three consecutive failures mark the service Unhealthy on the dashboard.

Five things to do next

  1. Deploy a second app. Try Jellyfin for media, Immich for photos, or Uptime Kuma to watch the first two. Each gets its own subdomain and certificate on the same host.
  2. Point a real domain at it. With DNS integration configured, DashCaddy creates records automatically and serves a trusted certificate. Behind CGNAT, a tunnel works instead; reaching self-hosted apps remotely covers the options.
  3. Browse the catalog. There are 78 one-click templates across 17 categories in the app catalog; the catalog guide explains how to choose.
  4. Set up backups. Your state lives in /opt/dockerdata and /etc/dashcaddy; snapshot both off the host. The dashboard's Backup button exports a single JSON file for a no-setup option.
  5. Learn the API. The platform exposes 400+ REST route handlers, so anything you can click, you can script. Start with the API docs.

When DashCaddy is not the right choice

  • You want exactly one app and enjoy hand-editing compose files. If you run a single container and like tuning your own Caddyfile, plain Docker Compose will do the job without a control plane.
  • You need Kubernetes-style orchestration. DashCaddy runs Docker and Compose on a Linux host. A scheduler with Kubernetes semantics across a large container fleet is a different tool.
  • You want deep per-container inspection in one narrow workflow. A focused container tool may fit better than a full platform.

FAQ

Do I need a domain to start?

No. A real domain gives you public DNS and a trusted Let's Encrypt certificate, but you can begin with a custom TLD on your LAN or a direct IP address and add a domain later. Nothing in the deployment flow changes.

How long does deploying an app take?

For a template like Vaultwarden, the deploy waits up to 30 seconds for the health check to pass. Most of that time is pulling the image and starting the container.

What happens to my data if a container is removed?

As long as your data lives in a mounted volume, it survives restarts and redeploys. Vaultwarden keeps everything in /opt/vaultwarden/data on the host, so removing the container alone does not delete it. That is also why backing up those volumes matters.

If a step above did not behave as described, the troubleshooting guide walks the stack layer by layer, and the product overview explains how the pieces fit together. When you are ready to compare plans, see pricing.