Setup
On first use, read setup.md, explain planned local storage in ~/home-server/, and ask for confirmation before creating files.
When to Use
User needs help designing, deploying, or operating a home server environment.
Agent handles architecture choices, secure exposure, service operations, backup strategy, and recovery planning.
Architecture
Memory lives in ~/home-server/. See memory-template.md for setup.
~/home-server/
├── memory.md # Current environment and preferences
├── services.md # Service inventory and ownership
├── backup-status.md # Backup coverage and restore checks
└── incidents.md # Failure timeline and recovery notes
Quick Reference
| Topic |
File |
| Setup behavior |
setup.md |
| Memory structure |
memory-template.md |
| Service inventory model |
service-catalog.md |
| Operational routines |
operations-checklists.md |
| Incident response flow |
incident-playbook.md |
Core Rules
1. Define Trust Boundaries First
- Classify every service as LAN-only, VPN-only, or internet-facing before deployment.
- Never expose admin panels or databases directly to the internet.
2. Design Around Recoverable Data
- Identify where each service stores state before changing configs or images.
- Back up data paths first, then update workloads.
- Never request or store raw secrets, full
.env dumps, or private keys in workspace memory.
3. Prefer Stable, Reproducible Deployments
- Use pinned image tags and declarative Compose files.
- Keep runtime variables documented so rebuilds are deterministic.
4. Secure the Host Before Scaling Services
- Enforce key-based SSH, minimal open ports, and regular security updates.
- Apply least privilege for containers, users, and file permissions.
5. Operate with Observable Signals
- Track health checks, disk usage, certificate expiry, and backup freshness.
- Treat silent failures as incidents and document root cause quickly.
6. Validate Recovery Paths Continuously
- Test restore procedures on a schedule, not only after failures.
- Require rollback plans before major upgrades or topology changes.
Common Traps
- Installing services before defining backup paths -> data loss during first migration.
- Publishing many ports directly on the router -> large attack surface and hard troubleshooting.
- Using
latest tags everywhere -> surprise upgrades and inconsistent behavior.
- Skipping restore drills -> backups exist but cannot be trusted in real incidents.
- Running all workloads on one Docker network -> accidental lateral access between services.
Security & Privacy
Data that may leave your machine (only when configured):
- DNS or dynamic DNS updates to your selected provider.
- Telemetry from optional monitoring stacks you install.
Data that stays local by default:
- Service configs, logs, backup manifests, and incident notes in your home-server workspace.
This skill does NOT:
- Open ports automatically.
- Deploy services without explicit user instruction.
- Send undeclared external requests.
Related Skills
Install with clawhub install <slug> if user confirms:
self-host — self-hosted service strategy and security baselines
server — server deployment and troubleshooting patterns
docker — container build and runtime discipline
docker-compose — multi-service orchestration patterns
linux — host administration and system diagnostics
Feedback
- If useful:
clawhub star home-server
- Stay updated:
clawhub sync
1---2name: home-server3description: Plan, secure, and maintain a home server with Docker services, remote access, backups, and incident recovery.4---56## Setup78On first use, read `setup.md`, explain planned local storage in `~/home-server/`, and ask for confirmation before creating files.910## When to Use1112User needs help designing, deploying, or operating a home server environment.13Agent handles architecture choices, secure exposure, service operations, backup strategy, and recovery planning.1415## Architecture1617Memory lives in `~/home-server/`. See `memory-template.md` for setup.1819```text20~/home-server/21├── memory.md # Current environment and preferences22├── services.md # Service inventory and ownership23├── backup-status.md # Backup coverage and restore checks24└── incidents.md # Failure timeline and recovery notes25```2627## Quick Reference2829| Topic | File |30|-------|------|31| Setup behavior | `setup.md` |32| Memory structure | `memory-template.md` |33| Service inventory model | `service-catalog.md` |34| Operational routines | `operations-checklists.md` |35| Incident response flow | `incident-playbook.md` |3637## Core Rules3839### 1. Define Trust Boundaries First40- Classify every service as LAN-only, VPN-only, or internet-facing before deployment.41- Never expose admin panels or databases directly to the internet.4243### 2. Design Around Recoverable Data44- Identify where each service stores state before changing configs or images.45- Back up data paths first, then update workloads.46- Never request or store raw secrets, full `.env` dumps, or private keys in workspace memory.4748### 3. Prefer Stable, Reproducible Deployments49- Use pinned image tags and declarative Compose files.50- Keep runtime variables documented so rebuilds are deterministic.5152### 4. Secure the Host Before Scaling Services53- Enforce key-based SSH, minimal open ports, and regular security updates.54- Apply least privilege for containers, users, and file permissions.5556### 5. Operate with Observable Signals57- Track health checks, disk usage, certificate expiry, and backup freshness.58- Treat silent failures as incidents and document root cause quickly.5960### 6. Validate Recovery Paths Continuously61- Test restore procedures on a schedule, not only after failures.62- Require rollback plans before major upgrades or topology changes.6364## Common Traps6566- Installing services before defining backup paths -> data loss during first migration.67- Publishing many ports directly on the router -> large attack surface and hard troubleshooting.68- Using `latest` tags everywhere -> surprise upgrades and inconsistent behavior.69- Skipping restore drills -> backups exist but cannot be trusted in real incidents.70- Running all workloads on one Docker network -> accidental lateral access between services.7172## Security & Privacy7374**Data that may leave your machine (only when configured):**75- DNS or dynamic DNS updates to your selected provider.76- Telemetry from optional monitoring stacks you install.7778**Data that stays local by default:**79- Service configs, logs, backup manifests, and incident notes in your home-server workspace.8081**This skill does NOT:**82- Open ports automatically.83- Deploy services without explicit user instruction.84- Send undeclared external requests.8586## Related Skills87Install with `clawhub install <slug>` if user confirms:88- `self-host` — self-hosted service strategy and security baselines89- `server` — server deployment and troubleshooting patterns90- `docker` — container build and runtime discipline91- `docker-compose` — multi-service orchestration patterns92- `linux` — host administration and system diagnostics9394## Feedback9596- If useful: `clawhub star home-server`97- Stay updated: `clawhub sync`