Deutsch
Server documentation should let an authorised teammate understand what a VPS does, where its dependencies live, how it changes, and how to recover it without relying on one person's memory. A list of hostnames and passwords is not enough, and reusable secrets should not be copied into the document.
Use one maintained record per server or tightly coupled service group. Link to controlled credential, repository, monitoring, and backup systems instead of duplicating sensitive values. The schema below is designed to be filled in, tested, and handed over.
Document the purpose
Start with the context that determines every later decision:
- Server/service purpose: what user or business capability the server provides, what is explicitly out of scope, and what acceptable degraded operation looks like.
- Environment: production, staging, development, test, or another named environment.
- Owner and backup owner: the accountable primary contact and the person or team that can act when the owner is unavailable.
- Hostname/IP/region: system hostname, public and private addresses where appropriate, and deployment region or location.
- OS/runtime versions: operating-system release plus the application, language, container, proxy, database, or other runtime versions needed to operate it.
- Last reviewed date: the date the record was reconciled against the live system, with the reviewer named.
Write the purpose for someone who did not build the service. Avoid labels such as “main server” or “normal stack”; name the actual function, consumers, operating boundary, and consequence of failure.
Record access and ownership
Document who owns each administrative boundary and where access is managed:
- Domains/DNS ownership: domains, DNS provider, registrar, responsible owner, validation method, and the controlled location of account or API credentials.
- Access identities and where credentials are managed: named human users, service identities, vendor access, emergency access, SSH or VPN path, and the approved secrets manager or access system. Store references, not plaintext passwords, private keys, tokens, or recovery codes.
- Firewall/network notes: intended listeners, exposed and internal ports, source restrictions, proxies, VPNs, allowlists, and who approves changes.
- Incident/escalation contacts: service owner, technical responder, business contact where relevant, and the escalation path when the first responder is unavailable.
Separate server access from account recovery. Record who controls the provider account, DNS/domain account, secrets manager, and backup restore access so a working Linux login is not mistaken for complete organisational recovery.
Map applications, data, and dependencies
Describe what must work together for the service to operate:
- Applications/services and ports: process or container names, purpose, bind address, protocol and port, start mechanism, health check, and owning team.
- Repositories/deployment path: source repository, branch or release convention, build system, deployment identity, artefact location, target path, deployment steps, verification, and rollback reference.
- Databases/storage and dependencies: database names and owners, volumes or mounts, storage purpose, external APIs, queues, caches, object storage, certificates, DNS, and other required services.
- Monitoring/alerts and owner: dashboards, log sources, health checks, alert destinations, thresholds or objectives, and the person or team expected to respond.
- Recovery dependencies: accounts, encryption keys, DNS access, package or image registries, external data, licences, and other prerequisites needed to rebuild or restore.
- Known limitations: accepted single points of failure, capacity constraints, manual steps, unsupported scenarios, or technical debt that changes incident decisions.
Show direction and consequence for dependencies. “Uses database” is weaker than “checkout API requires the production PostgreSQL database; writes stop if it is unavailable; database owner is Data Operations.”
Define backup, change, and recovery
For backup and recovery, record the backup method, retention, restore procedure, and last restore test. Name what is and is not backed up, schedule, destination, encryption ownership, retention rule, monitoring, restore order, verification step, and the date and result of the latest restore exercise.
Document the patch/change process: maintenance owner, update sources, approval path, pre-change checks, backup or rollback prerequisite, deployment window, verification, rollback trigger, and where change history is recorded. A package-update command without a rollback and validation path is not a change process.
Keep the restore procedure independent of the running server where practical. If the only copy of the instructions, credentials, or decryption material is on the failed VPS, the documented recovery path will fail with it.
Keep runbooks short
A runbook should cover one trigger and one bounded response. Start with this minimum format:
| Trigger | Check | Action | Verification | Escalation |
|---|---|---|---|---|
| Alert or observed symptom | Exact command, dashboard, log, or user-path check | Safe action and its preconditions | Evidence that the service and user path recovered | Named owner, condition, and contact route |
Use several small runbooks rather than one long page that mixes deployment, disk pressure, certificate expiry, database recovery, and incident communication. Link commands to their expected output, identify destructive steps, and state when the responder must stop and escalate.
Copyable server documentation template
Copy this Markdown into the team's controlled documentation system and replace every placeholder. Keep secret values in the approved credential system and link only to their managed references.
Template: VPS server and service record
# Server/service record: [descriptive name]
## Purpose and ownership
- Server/service purpose: [capability, consumers, scope, failure impact]
- Environment: [production/staging/development/test]
- Owner: [name or team and contact route]
- Backup owner: [name or team and contact route]
- Hostname/IP/region: [hostname; public/private references; region]
- OS/runtime versions: [OS; application/runtime/proxy/database versions]
- Last reviewed: [YYYY-MM-DD by reviewer]
## Domains, access, and network
- Domains/DNS ownership: [domains; registrar/DNS provider; owner; credential reference]
- Access identities: [human, service, vendor, emergency identities and scope]
- Credential management: [approved system and record references; no secret values]
- Firewall/network notes: [listeners; ports; source restrictions; VPN/proxy/allowlists]
## Applications and delivery
- Applications/services and ports: [name; purpose; bind address; protocol/port; start/health check; owner]
- Repositories/deployment path: [repository; release rule; build/deploy identity; target; verification; rollback]
- Patch/change process: [owner; approval; pre-check; window; verification; rollback; history]
## Data and dependencies
- Databases/storage: [database; volume/mount; purpose; owner]
- External dependencies: [API; queue; cache; object storage; certificates; DNS; consequence]
- Recovery dependencies: [accounts; keys; DNS; registries; external data; licences]
- Known limitations: [failure domains; capacity constraints; manual steps; unsupported cases]
## Monitoring and incidents
- Monitoring/alerts and owner: [dashboards; logs; health checks; alert routes; responder]
- Incident/escalation contacts: [technical; service; business; secondary escalation]
## Backup and restore
- Backup method: [scope; schedule; destination; encryption owner; monitoring]
- Retention: [rule and deletion responsibility]
- Restore procedure: [location or ordered steps]
- Last restore test: [YYYY-MM-DD; scope; result; evidence; follow-up]
## Runbooks
| Trigger | Check | Action | Verification | Escalation |
| --- | --- | --- | --- | --- |
| [symptom/alert] | [evidence to inspect] | [bounded safe action] | [service and user-path proof] | [condition, owner, contact] |Review after incidents and changes
Update the record when a deployment or architecture change alters a port, dependency, owner, credential reference, alert, backup, recovery step, or limitation. After an incident, compare what responders needed with what the document contained, then correct missing or misleading fields.
Schedule periodic reconciliation even when no incident occurs. Verify the record against the live server, repositories, DNS, monitoring, backup configuration, access system, and restore evidence. A recent date without that comparison is not proof that the document is current.
When a VPS is the right fit
A VPS can fit a team that needs customer-operated control over its operating system, applications, network configuration, deployment, monitoring, backup, and documentation. That control means the customer must maintain the record and test the procedures it describes.
Virtarix VPS services are self-managed. Virtarix providing server access, snapshots, or plan-entitled backups does not make Virtarix the owner of the customer's application documentation, monitoring, patching, restore procedure, or incident response. A single VPS remains one failure domain; document and design redundancy separately when the workload requires it.
FAQs
Where should the documentation live?
Use a controlled system that authorised responders can reach even if the VPS is unavailable. Keep version history and access control, and avoid storing plaintext credentials or private keys in the document.
How detailed should a runbook be?
It should be detailed enough for an authorised responder to identify the trigger, perform the check, take one bounded action, verify the result, and know when to escalate. Split unrelated responses into separate runbooks.
How often should the record be reviewed?
Review it after relevant changes and incidents, during ownership handovers, and on a scheduled cadence. The review is complete only after the document is reconciled with the live systems and recovery evidence.
