name: self-host-packager
description: "Use when asked to make a project self-hostable, package an app for Docker, write a docker-compose setup, document self-hosting, or let users run my app on their own server. Produces a one-command self-host for a project: docker-compose.yml, a .env.example with a table explaining every variable, SELF_HOSTING.md covering HTTPS, backups and upgrades, and a back-up-this-folder section that tells users exactly what holds all their data."
version: 1.0.0
Self-Host Packager
Self-hosters will try a project if it starts with one command and they understand where their data lives. Most self-hosting guides fail at the second day: no HTTPS, no backup story, and an upgrade that breaks the database. This skill packages a project so it starts with docker compose up -d, keeps all state in one folder, and documents HTTPS, backups and upgrades.
Required Inputs
Ask for these if not provided:
- The project: language, how it builds and starts, the port it listens on
- State: database (and which), uploaded files, caches, anything written to disk
- Configuration: environment variables the app reads, and which are secrets
- External services: email, object storage, OAuth providers, and whether each is optional
- Target user: a home-lab enthusiast, a small team, or a company's IT
Output Structure
1. docker-compose.yml
A complete file with:
- the app service, built from the repo's Dockerfile or a published image with a pinned tag (never
latest)
- the database service, if any, with a pinned major version and a health check
depends_on with condition: service_healthy
- every piece of state mounted under one host folder,
./data/ (for example ./data/db, ./data/uploads)
restart: unless-stopped
- the app bound to
127.0.0.1 by default, with a comment on exposing it behind a reverse proxy
If the project has no Dockerfile, include a multi-stage Dockerfile that runs as a non-root user.
2. .env.example and the variables table
The file with safe placeholder values, then a table:
| Variable | Required? | Default | What it does | Example | Secret? |
Every variable the app reads is listed. Secrets have no default and the table says how to generate one (for example openssl rand -hex 32).
3. SELF_HOSTING.md
Sections, in order:
- Requirements: CPU, RAM and disk for a small install; Docker and Compose versions
- Start in one command: copy
.env.example to .env, fill the required values, docker compose up -d, and what to open in the browser
- HTTPS: a reverse-proxy example (Caddy, which obtains certificates automatically), with the full config
- Back up this folder and you have everything: states that
./data/ plus .env is the complete state; gives a backup command that stops writes or uses the database's dump tool, and a restore drill
- Upgrades: read the release notes, back up, change the image tag,
docker compose pull && docker compose up -d, and how to roll back
- Troubleshooting: the five most likely failures with the log command and fix
4. Smoke test
Commands that prove a fresh install works: start, wait for health, hit the health endpoint, create one record, restart, and confirm the record survived.
Quality Checks
Anti-Patterns
- State scattered across anonymous volumes. Users cannot back up what they cannot find.
latest tags. An upgrade happens by accident on the next pull.
- Exposing the database port. Only the app (behind the proxy) should be reachable.
- Backups that are never restored. An untested backup is a hope, not a backup.
Example Trigger Phrases
- "Make my app self-hostable with Docker Compose."
- "Write a SELF_HOSTING.md with HTTPS, backups and upgrades."
- "Package this Node and Postgres project for home-lab users."
- "Give me a one-command self-host setup and an env var table."