GCP Org Host Infrastructure, Identity, And Operations

Once the org-host runtime contract is clear, the GCP deployment becomes a resource graph rather than a vague "cloud setup." The first production target is still a Compute Engine VM, but the VM is only one part of the operating model. The deployment also needs durable state, a runtime identity, controlled administrative access, runtime secrets, logs, backups, rollback, and cleanup.

The goal is not to make the host feel managed. The goal is to make it explicit enough that an operator can audit and recover it.

The Resource Graph

The first GCP org host has a small set of required resources:

• a Compute Engine VM that runs the installed matic package,
• an attached Persistent Disk mounted as the durable Matic root,
• a dedicated matic system user on the host,
• a user-managed service account for runtime identity,
• Secret Manager entries for runtime credentials,
• OS Login or IAP for administrative access,
• systemd units for active channel listeners,
• cron entries for scheduled routines,
• logs, disk snapshots, and cleanup commands.

That list matters because it separates the host from the state. The VM can be rebuilt. The mounted disk is where the org lives.

Identity Is Part Of The Deployment

The org-host service account should be user-managed and narrowly scoped. The Compute Engine default service account is not the runtime identity, and broad project roles such as Editor or Owner are not acceptable shortcuts.

There are three identities to reason about:

• deployers create and update resources,
• the org-host service account reads approved secrets and writes required logs,
• operators administer the VM through OS Login or IAP.

The VM may use the cloud-platform OAuth scope so Compute Engine can reach services such as Secret Manager. That does not make the host broadly authorized by itself. Authorization still comes from the service account's IAM grants, so the useful control remains the role set bound to the runtime identity.

Secrets Are Named, Not Stored

Secrets belong in Secret Manager. Repo files and org files can name expected secret resources, but they should not contain values.

This keeps two promises at once:

• the deployment is repeatable because the runbook names the needed variables,
• the filesystem remains readable because sensitive values are not committed or persisted as operational markdown.

If a runtime process needs a local environment file, that materialization should be root-owned, host-local, and disposable. The file is plumbing, not durable org state.

Administrative Access Should Be Constrained

A single-host deployment still needs a serious access boundary. The runbook prefers OS Login or IAP instead of broad public SSH ingress and unmanaged key sprawl.

That choice keeps host administration tied to identity and audit trails. It also makes the quickstart safer for new operators, because the documented path does not start by opening a wide network door just to make setup easier.

Operations Are Not An Afterthought

The operating model is part of the infrastructure:

• systemd owns active channel listeners,
• cron owns routine schedules,
• logs need clear inspection commands,
• disk snapshots or machine images need a documented recovery path,
• rollback needs to be possible without redefining the host,
• cleanup needs to remove billable resources in the right order.

Those details are the difference between a demo host and an operator-ready quickstart. A VM that starts once is not enough. The operator needs to know what is running, where state is written, how to recover it, and how to shut the whole thing down.

What Day 2 Proves

Day 2 turns the org host into an auditable cloud deployment:

• durable state is on a mounted Persistent Disk,
• runtime identity is a user-managed service account,
• secrets are sourced from Secret Manager,
• administrative access uses identity-aware host access,
• active listeners and routines remain OS-supervised,
• backups, rollback, logs, and cleanup are documented as part of the setup.

That gives Day 3 a real onboarding path. A new operator can follow a concrete resource graph instead of reverse-engineering the deployment from scattered commands.