Make the service visible.
Start with its purpose, people, data and dependencies. Then put a realistic boundary around the first version.
The self-hosting field guide
Find a route through the work: map the service, decide who can reach it, then prove that its data can return.
Start with its purpose, people, data and dependencies. Then put a realistic boundary around the first version.
Separate member access from administration and make the quiet background tasks somebody’s responsibility.
Keep an independent recovery copy and find out what your exports preserve before relying on them.
Service facts and catalogue tables · The self-hosting glossary · Answers to 28 practical questions
Build a practical inventory for a shared wiki: owners, data, dependencies, access decisions and the order of recovery.
Map a collective’s wiki accounts, database, attachments, search, maintenance and recovery before choosing resources.
Build a storage worksheet for originals, versions, deleted items, previews, temporary exports and an independent recovery copy.
Choose public, member and administration access deliberately, then verify the boundary with a practical account and network matrix.
Separate member, application and host permissions, handle arrivals and departures, and plan updates with a usable recovery point.
Map scheduled tasks, outgoing mail, retries and restore-time side effects so a small group can notice and handle failures.
Plan a safe wiki restore rehearsal with isolated dependencies, witness accounts, attachment checks and a result sheet that records evidence.
Prepare an export folder with readable content, attachments, format notes and import checks that another maintainer can use.
Plan a small collective’s wiki around complete data, sensible permissions, a resource budget and a recovery handover another person can follow.
See this service plan ↗Budget a personal document collection for originals, versions and working space, with independent copies and a recovery exercise beyond the VPS.
See this service plan ↗Write the plan, selected options, country, term, rate and local reference before opening the wallet.
Separate repository access, encryption password and recovery instructions so a server loss does not remove every recovery route.
Record peers, allowed addresses, key owner, service binding and a safe revocation path before adding a private route.
Give a cover maintainer a bounded action list, a status-note location and a clear escalation point.
Map data files, database, configuration and custom components before calling an application copy a backup.
Choose the exact version, map storage and database format, and prepare an independent pre-change copy.
List ordinary members, application administrators and host administrators as different roles with separate reasons.
Count originals, previews, database data, logs, imports, exports and a working margin separately.
List records, attachments, metadata, permissions and links that a future application must receive.
Record registrar owner, renewal contact, DNS authority and a recovery email independent from the service.
Describe the sessions, SSH keys, authenticators and recovery codes that may need review after a device is lost.
Identify the destination, recovery authority and credential path needed after loss of the VPS.
Choose a buying worksheet before payment, a comparison when the hosting model is unclear, or a maintainer-manual entry when the service needs a durable record.