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 baselinesserver — server deployment and troubleshooting patternsdocker — container build and runtime disciplinedocker-compose — multi-service orchestration patternslinux — 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---5
6## Setup
7
8On first use, read `setup.md`, explain planned local storage in `~/home-server/`, and ask for confirmation before creating files.
9
10## When to Use
11
12User needs help designing, deploying, or operating a home server environment.
13Agent handles architecture choices, secure exposure, service operations, backup strategy, and recovery planning.
14
15## Architecture
16
17Memory lives in `~/home-server/`. See `memory-template.md` for setup.
18
19```text
20~/home-server/
21├── memory.md # Current environment and preferences
22├── services.md # Service inventory and ownership
23├── backup-status.md # Backup coverage and restore checks
24└── incidents.md # Failure timeline and recovery notes
25```
26
27## Quick Reference
28
29| 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` |
36
37## Core Rules
38
39### 1. Define Trust Boundaries First
40- Classify every service as LAN-only, VPN-only, or internet-facing before deployment.
41- Never expose admin panels or databases directly to the internet.
42
43### 2. Design Around Recoverable Data
44- 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.
47
48### 3. Prefer Stable, Reproducible Deployments
49- Use pinned image tags and declarative Compose files.
50- Keep runtime variables documented so rebuilds are deterministic.
51
52### 4. Secure the Host Before Scaling Services
53- Enforce key-based SSH, minimal open ports, and regular security updates.
54- Apply least privilege for containers, users, and file permissions.
55
56### 5. Operate with Observable Signals
57- Track health checks, disk usage, certificate expiry, and backup freshness.
58- Treat silent failures as incidents and document root cause quickly.
59
60### 6. Validate Recovery Paths Continuously
61- Test restore procedures on a schedule, not only after failures.
62- Require rollback plans before major upgrades or topology changes.
63
64## Common Traps
65
66- 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.
71
72## Security & Privacy
73
74**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.
77
78**Data that stays local by default:**
79- Service configs, logs, backup manifests, and incident notes in your home-server workspace.
80
81**This skill does NOT:**
82- Open ports automatically.
83- Deploy services without explicit user instruction.
84- Send undeclared external requests.
85
86## Related Skills
87Install with `clawhub install <slug>` if user confirms:
88- `self-host` — self-hosted service strategy and security baselines
89- `server` — server deployment and troubleshooting patterns
90- `docker` — container build and runtime discipline
91- `docker-compose` — multi-service orchestration patterns
92- `linux` — host administration and system diagnostics
93
94## Feedback
95
96- If useful: `clawhub star home-server`
97- Stay updated: `clawhub sync`
modbender