This wiki is the technical operating manual for smithflix. Organize content so an administrator can inspect, change, validate, and recover the platform without reverse-engineering compose files or container state from scratch.
home
- Entry point, coverage map, high-level topology.
infrastructure/host
- Host OS, hardware, Docker runtime, networking baseline, safety notes.
docker/stacks/<stack>
- One page per Dockge-managed stack with compose path, services, networks, ports, data roots, and validation flow.
services/<service>
- One page per operationally important service with exact paths, ports, auth model, dependencies, and maintenance actions.
networking/reverse-proxy
- Nginx Proxy Manager, public hostnames, TLS behavior, websocket expectations.
networking/dns-firewall
- Pi-hole, LAN DNS topology, router and firewall assumptions, exposure risks.
storage/layout
- Filesystems, media roots, config roots, RAM disk usage, persistence boundaries.
storage/backups
- Duplicati scope, restore expectations, dump jobs, secret handling.
operations/runbooks/<topic>
- Procedural incident and change runbooks with diagnosis, execution, rollback, and validation.
For operational pages, prefer this section order:
- Summary
- Scope
- Runtime Topology
- Config and Data Paths
- Network Exposure
- Authentication and Secret Locations
- Operations
- Monitoring and Logs
- Backup and Restore
- Failure Modes and Recovery
- Verification Date
¶ Writing Standard
- Write for a technical administrator, not an end user.
- Prefer exact container names, ports, compose paths, bind mounts, network names, and env keys.
- Use absolute dates when freshness matters.
- Distinguish verified facts from inferences.
- Keep secrets out of page content. Record secret locations and variable names instead.
- Explain intentional deviations from defaults.
¶ Naming and Linking Rules
- Use lowercase slash-separated paths, for example
docker/stacks/server.
- Keep one authoritative page per domain object. Update the page instead of creating duplicate notes.
- Use index pages to route readers into canonical pages.
- Treat Git history and Wiki.js page history as the revision log unless a separate runbook is explicitly needed.
Update the relevant page whenever one of these occurs:
- Compose or
.env changes
- New service or stack deployment
- Port, hostname, proxy, access-list, or certificate changes
- Storage, backup, or retention changes
- Auth, API key, or secret-location changes
- Monitoring, alerting, or logging topology changes
- Operational scripts added, removed, or repurposed
- Incidents that reveal missing or incorrect documentation
- Gather live facts from the host, compose files, service configs, runtime state, or logs.
- Read the current wiki page before changing it.
- Update the authoritative page through Wiki.js API mutations for routine edits.
- Re-read the page after writing.
- Confirm Git storage remains operational.
- Methodology established
2026-04-07