GCP Org Host Quickstart Onboarding

The GCP org-host quickstart is ready only when a new operator can follow it without knowing the implementation history. That means the docs have to do more than list resources. They need to move from a clean local checkout and a clean GCP project to a working host with a mounted disk, installed matic, active listeners, scheduled routines, logs, backups, and cleanup.

The quickstart is an operator path, not a product announcement. It describes a self-operated Compute Engine org host. It does not market a managed cloud service.

Split Local Setup From The GCP Host

The first usability improvement is structural: keep the local MVP path separate from the GCP org-host path.

Local setup proves the package and filesystem behavior on a developer machine. The GCP quickstart proves the same runtime contract on a host with a mounted Persistent Disk, host-level supervision, and cloud identity. Blending those two paths makes the instructions harder to trust because the operator cannot tell which steps belong to development and which belong to deployment.

The GCP path should therefore name its own prerequisites, variables, expected resources, and verification commands.

Every Step Needs An Expected Result

A quickstart is not complete if it only says what to run. It should also say how the operator knows the step worked.

The GCP path walks through:

• selecting project, region, zone, and resource names,
• enabling the required APIs,
• creating the user-managed runtime service account,
• creating secrets without writing values into files,
• creating and attaching the Persistent Disk,
• creating the Compute Engine org host,
• mounting the disk at the Matic state root,
• installing Python and matic,
• initializing or restoring the org root,
• installing systemd units,
• installing cron entries,
• checking logs and state,
• creating a backup,
• cleaning up resources.

Each major stage should have a verification command or an observable outcome. For example, the host should answer matic --help, the org root should inspect cleanly, systemd should report listener status, and the cron file should be present before the operator treats scheduled routines as configured.

Verification Is Part Of Onboarding

The runbook should make verification feel normal rather than optional.

Useful checks include:

• matic inspect "$MATIC_ORG_ROOT" for the durable org root,
• systemctl status matic-channel@telegram.service --no-pager for an active listener,
• sudo test -f /etc/cron.d/matic for the routine schedule,
• routine log inspection for scheduled work,
• disk snapshot creation for backup coverage,
• cleanup commands for cost control.

Those checks keep the operator from confusing "the VM exists" with "Matic is operational." The deployment is not ready until state, supervision, scheduling, logs, backup, and cleanup can all be explained.

Production Readiness Is A Checklist

The quickstart is still the first GCP deployment path, so it should stay honest about what operators must review before relying on it:

• IAM scope for deployers, operators, and the runtime service account,
• secret rotation and materialization,
• systemd failure behavior,
• cron logs and missed-run handling,
• package rollback,
• disk restore,
• routine overlap policy,
• cost guardrails,
• known limitations.

This is the part that keeps the content from drifting into launch language. The host is useful because it is concrete and recoverable, not because it hides operations behind a managed-service claim.

What Day 3 Proves

Day 3 turns the GCP deployment into an onboarding surface:

• the local and GCP paths are separated,
• the GCP path names prerequisites and variables,
• the runbook verifies each major stage,
• secrets stay out of checked-in files,
• systemd and cron are inspected explicitly,
• snapshots, rollback, and cleanup are included,
• the docs keep future managed-cloud work outside the current scope.

That makes the org-host quickstart shareable. A new operator can bring up the host, verify it, recover it, and shut it down without guessing which parts of the implementation are real deployment requirements.