Preflight and self-hosted deployment readiness

Self-hosted deployment preflight

Self-hosted operation gives full control and therefore full responsibility. Before every run you must validate not only form inputs but also the environment where the run executes.

Purpose and audience

For teams managing their own infrastructure who need repeatability and strict control over change impact.

Prerequisites

• Server and network access configured (SSH, firewalls, DNS, certificates),
• current role model exists in workspace and database context,
• template stack matches deployment objective,
• rollback path is documented and tested.

Step-by-step

1. Target validation: verify server state, ports, DNS records, and repository accessibility.
2. SSH and secrets: check credential/key pairing is active and tracked through approved process.
3. Input validation: complete all required fields and compare values with current template expectations.
4. Run preflight: execute preflight and clear warnings before execution.
5. Tag selection: for baseline stability start with minimal tag set; expand only after successful baseline run.
6. Post-run checks: validate service availability, DNS, TLS and run logs.

Pre-run checklist

• Is the target environment fully verified?
• Are roles and ownership clear before execution?
• Were preflight warnings evaluated?
• Do you have a rollback path and designated verifier?
• Do you have a concise run note with reason and result?

Common mistakes

• Deployment started without network validation (DNS/ports/firewall),
• template updates not reflected before repetitive changes,
• out-of-window edits and mixed emergency changes,
• rollback step not documented or not rehearsed.

Next steps

• After baseline run, proceed to self-hosted day-to-day operations.
• Configure governance via self-hosted governance.
• For incident and recovery use troubleshooting.

Next step: Move from readiness checks into first deployment and production checklist.