Self-hosted first run onboarding

First run on own infrastructure

Self-hosted gives flexibility, but the first run sets your operational quality bar. If the first run is stable and well-documented, later runs are easier to run repeatedly.

Purpose

• Verify baseline environment readiness,
• create a first repeatable run record,
• define role model before production cadence.

Prerequisites

• Self-hosted installation completed and reachable,
• network, SSH, DNS, firewall verified,
• workspace and template prepared.

Step-by-step

1. Validate infrastructure — IP, SSH, DNS, firewall, repository access.
2. Review setup via self-hosted installation and dependencies.
3. Fill values in initial template and prepare baseline tags.
4. Run preflight in self-hosted preflight and resolve warnings.
5. Confirm team flow — who executes, who verifies, who can rollback.
6. Execute the first run with minimal baseline tag set.
7. Validate output — DNS/TLS, service health, run log.
8. Close run with notes and follow-up actions.

Checklist

• Is infrastructure availability confirmed before run?
• Are roles and ownership explicit?
• Did preflight pass required checks?
• Is rollback path documented and tested?
• Is the run output persisted and auditable?

Common mistakes

• Running before SSH/DNS/firewall checks.
• Skipping rollback scenario design.
• Mixing test and production values.
• Undefined owner after execution.

Next steps

• Move to self-hosted day-to-day operations.
• Institutionalize checks with self-hosted preflight.
• Secure access and ownership in self-hosted workspace and security.

Next step: Extend the process in self-hosted governance and keep long-term governance in the runbook.