The server init template applies when the target’s operation depends on host state, services, network posture, secrets, storage, startup behavior, or deployment readiness. It addresses the full surface of a server environment — from OS and kernel through runtime versions, service configuration, firewall policy, secret references, logging destinations, and backup expectations — and creates or configures only what the specific host target requires.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/bitwikiorg/init.md/llms.txt
Use this file to discover all available pages before exploring further.
Template metadata
| Field | Value |
|---|---|
| Name | Server Init Protocol |
| Target | Server, service host, production infrastructure, or deployment environment |
| Purpose | Inspect server-specific operational requirements, configure what applies, validate readiness, and report deployment state |
| Modes | Active, Dry Run, Repair, Reinitialize |
| Creates | Server report when host state must be recorded; service definitions or startup scripts when required; environment examples when configuration must be documented without secrets; runbook or validation report when operations need handoff material |
| Configures | Operating system prerequisites; runtime settings; services; networking and firewall policy; secret references; logging, backups, and deployment checks |
| Validates | Required services start or are already running; dependencies and ports are available; configuration parses; resource, storage, time, and security checks pass or produce warnings |
| Optional outputs | SERVER.md; RUNBOOK.md; SNAPSHOT.md; INIT_CONTEXT_SNAPSHOT.md; .env.example; health check or readiness report |
When to use
Use this template when the target’s operation depends on host state, services, network posture, secrets, storage, startup behavior, or deployment readiness.When NOT to use
Do not use this template for a non-server target unless server infrastructure is actually part of its operation. A software project hosted on a server does not automatically require the server template — use the development project template for the codebase, and the server template for the host environment if that host must also be initialized.What it inspects
The server template builds a relevant picture of the host and service environment using read-only inspection first:- OS and kernel — distribution, version, kernel release.
- Clock and time source — NTP synchronization status, clock accuracy.
- Resources — CPU, RAM, storage capacity and headroom, current load.
- Users and service accounts — required accounts exist with correct permissions.
- Runtime versions — languages, runtimes, and interpreters required by services.
- Service manager — systemd, init, or equivalent; known service states.
- Container or orchestrator state — Docker, Kubernetes, or equivalent when applicable.
- Network interfaces — configured addresses, expected interface availability.
- Listening ports — which ports are open and what is bound to them.
- Firewall policy — inbound and outbound rules, default policy.
- Secret locations by reference — where secrets are stored, not what they contain.
- Logging destinations — where service logs are written or forwarded.
- Backup expectations — backup targets, schedules, and accessibility.
Conditional artifacts
All outputs are conditional on the server target’s actual needs:| Artifact | Condition |
|---|---|
| Service definitions | Required services need startup configuration |
| Startup scripts | Services require documented or scripted startup procedures |
.env.example | Configuration must be documented without writing actual secrets |
SERVER.md | Host state must be recorded for operations or handoff |
RUNBOOK.md | Operations require handoff material or recovery documentation |
SNAPSHOT.md / INIT_CONTEXT_SNAPSHOT.md | A point-in-time host record is useful for audit or rollback |
| Readiness or health-check scripts | Deployment requires automated readiness checks |
| Deployment notes | Deployment steps must be documented |
| Backup or restore instructions | Recovery procedures must be explicit |
What it configures
- Operating system prerequisites and runtime paths.
- Service units and startup order.
- Container settings when applicable.
- Scheduler entries (cron, systemd timers) when applicable.
- Firewall rules and default policy.
- Reverse proxy routes and TLS expectations.
- Secret references (locations and expected environment variable names, not values).
- Log locations and log forwarding configuration.
- Backup targets and backup verification commands.
- Deployment commands and rollback expectations.
The procedure
INSPECT
Build a relevant picture of the host and service environment.
- Inspect OS, kernel, clock and time source, CPU, RAM, storage, load, users or service accounts, runtime versions, service manager, container or orchestrator state, network interfaces, listening ports, firewall policy, secret locations by reference, logging destinations, backup expectations, and existing runbooks.
- Use read-only inspection first. Avoid privileged or destructive actions unless the operator explicitly authorizes them.
- Use host files, service definitions, package manifests, deployment docs, cloud or container metadata, monitoring notes, and operator constraints as sources.
DETERMINE
Decide what the server needs to become operational.
- Identify required packages, services, ports, environment variables, secret references, storage paths, permissions, startup order, deployment commands, monitoring hooks, backup strategy, and rollback expectations.
- Treat every output as conditional. A snapshot, server report, or runbook is useful only when it helps operation, handoff, audit, or recovery.
- Produce a server-specific initialization plan.
CREATE
Create only artifacts required by the server target.
- Possible outputs include service definitions, startup scripts,
.env.example(without secrets),SERVER.md,RUNBOOK.md,SNAPSHOT.md, readiness or health-check scripts, deployment notes, and backup or restore instructions. - Do not write raw secrets to disk.
- Do not create unrelated project files because this is a server template.
CONFIGURE
Configure the server elements required for operation.
- Set or document runtime paths, service units, container settings, scheduler entries, firewall rules, reverse proxy routes, TLS expectations, secret references, permissions, log locations, backup targets, and deployment commands.
- Make active changes only in active or repair mode and only with appropriate access.
VALIDATE
Confirm the server can perform its intended role.
- Use relevant checks such as configuration parsing, service status, startup commands, port availability, dependency resolution, disk headroom, clock coherence, firewall review, secret reference availability, log writeability, backup path accessibility, and health endpoint response.
- Do not declare a server operational if required services cannot start, required configuration cannot parse, or required secrets are unavailable.
- Report status as
OPERATIONAL,OPERATIONAL_WITH_WARNINGS,BLOCKED, orDRY_RUN_COMPLETE.
REPORT
Report the complete server initialization result:
- Target host or environment.
- Inspected host, service, network, secret, logging, and backup areas.
- Created or updated artifacts.
- Configured services or settings.
- Validation checks and outcomes.
- Warnings, missing access, or blockers.
- Final operational state.
Server-specific notes
The following concerns are server concerns. They belong here — not in the root protocol, and not imposed on unrelated targets:- Host operating-system checks — distribution, kernel version, installed packages.
- Clock and NTP — time synchronization is a server concern; other targets do not need clock checks.
- CPU, RAM, storage, and load metrics — resource headroom matters for servers and infrastructure; it does not apply to codebases or agent workspaces.
- Firewall policy — network security rules are a server concern.
- Secret handling — server init references secret locations without writing values; secret injection belongs to the runtime environment.
- Backups — backup targets and verification are server concerns.
- Centralized logging — log forwarding and log destination verification belong on the server, not in project initialization.
- Generated environment snapshots — point-in-time host records are useful for servers and infrastructure; they are not normative outputs for other template types.