GCP Org Host Runtime Contract

The first GCP deployment decision for Matic is deliberately plain: the production target starts as a Compute Engine org host with durable local files. That sounds less glamorous than a container platform or a managed scheduler, but it matches the shape of the system. Matic coordinates an organization through files, git, channels, routines, and the installed CLI. The first cloud host has to preserve that contract before it adds more platform machinery.

The useful question is not "which GCP product can run code?" The useful question is "where does the org live, and which operating-system primitives keep it running?"

The Host Is Not The State

The host is a machine. The durable org root lives on the mounted Persistent Disk.

That distinction prevents a subtle deployment failure. A VM can be recreated, patched, resized, or replaced. The org state cannot be treated as incidental boot-disk data. The deployment runbook therefore uses a stable mount such as /var/lib/matic, with each org rooted beneath that filesystem:

/var/lib/matic/orgs/<org-handle>

The exact host path is an operator convention, not a new Matic primitive. What matters is the contract: active listeners, scheduled routines, smoke checks, backups, and recovery commands all point at the same mounted org root.

The Installed CLI Is The Runtime Surface

The GCP path runs the installed matic command. It does not depend on source-tree path injection, repo-local imports, or a developer checkout pretending to be a host installation.

That constraint is more than packaging hygiene. It gives the operator one command surface to reason about:

matic --help
matic init "$MATIC_ORG_ROOT" --handle "$MATIC_ORG_HANDLE" --name "$MATIC_ORG_NAME"
matic inspect "$MATIC_ORG_ROOT"
matic routines sync-cron "$MATIC_ORG_ROOT"

If the package cannot expose those commands cleanly, the cloud deployment is not ready. A deployment runbook should not smuggle development assumptions onto a production machine.

systemd Owns Active Channels

Always-listening channels are foreground processes supervised by systemd. That keeps the long-running process visible to the host:

• the unit names the channel,
• the command invokes installed matic,
• restart policy is handled by the OS supervisor,
• status and logs are inspected with standard host tools,
• writes are constrained to the mounted Matic state path.

For Telegram, that means the service is shaped around a command like:

matic channels telegram listen "$MATIC_ORG_ROOT"

The important part is not Telegram specifically. The important part is that an active channel is not hidden in an ad hoc shell loop, a detached terminal, or an application-owned background scheduler. It is a service the operator can start, stop, inspect, and recover.

cron Owns Routines

Routines stay in plain cron.

That is the smallest honest scheduler for the first org-host target. It keeps the schedule inspectable, lets the host own timing, and avoids turning the MVP into a second scheduler before the filesystem contract is proven.

The cron entry calls matic directly:

matic routines run "$MATIC_ORG_ROOT" --handle daily-check-in

The routine overlap posture remains a Matic concern, but the trigger stays boring. Operators can inspect the cron file, inspect logs, and verify that routine execution is using the same durable org root as the active listeners.

Secrets Stay Out Of Org Files

The runtime contract also sets a security boundary. Repo files, org markdown, and examples may name variables, paths, secret names, and expected locations. They must not contain secret values.

On GCP, Secret Manager is the source of truth for sensitive runtime values. If a service needs a materialized environment file, that file is root-owned, host-local, and disposable. It is not part of the org's durable readable state.

That separation preserves the filesystem-first model without turning the filesystem into a secret dump.

What Day 1 Proves

Day 1 of the GCP quickstart is a boundary-setting step. It proves that the deployment has a coherent runtime shape before the resource graph expands:

• Compute Engine is the first org host.
• Persistent Disk carries durable local org state.
• installed matic is the host command surface.
• systemd supervises active channel listeners.
• cron triggers scheduled routines.
• secrets stay out of checked-in files and org files.
• smoke checks run against the same mounted org root the host will use.

That is enough to make the next GCP work concrete. Day 2 can focus on identity, secrets, access, logs, snapshots, and cleanup without reopening the core question of what kind of runtime Matic needs.