Provisioning vs Deployment

inforge separates two distinct lifecycles: provisioning and deployment.

Provisioning

Provisioning creates a VM's host-side scaffolding:

• The on-host folder /srv/wardnet/<service>
• An inforge-managed systemd unit wardnet-<service>.service whose ExecStart is inforge-bootstrap
• The service's secret-free descriptor.yaml and, for a secret-bearing service, its host-key-encrypted credential.age under /etc/wardnet/services/<service>/ (the service fetches its secrets at runtime)

Provisioning is triggered by inforge deploy when the Pulumi state shows changes. inforge owns the unit — it controls start, restart, and configuration. Service code is never touched during provisioning.

Deployment

Deployment delivers a service's payload to the provisioned host in two steps (ADR-0016):

• push — the build artifact is uploaded to an R2 release store as an immutable, SHA-keyed tarball (<service>/<SHA>.tar.gz)
• deploy — a chosen SHA is downloaded, SCP'd to the host, the inforge-managed unit is restarted, and the SHA is recorded per host in manifest.<env>.yaml

Both run from the service repo's CI via inforge releases (see the service release starter). See inforge releases.

Deployment is independent of provisioning. A service can deploy code dozens of times without touching infrastructure. Infrastructure can change (e.g. resize a VM) without triggering a code redeploy. Because artifacts are SHA-keyed and retained, rolling back is re-deploying a previous SHA.

Why separate?

• Independent cadences: infrastructure changes and code releases don't have to happen together
• Ownership clarity: inforge owns the runtime contract; service repos own the code
• Simpler rollbacks: rolling back code doesn't require re-provisioning infrastructure
• Parallel operations: multiple services can deploy simultaneously while infrastructure changes are serialised through Pulumi

Target resolution

inforge releases deploy resolves the deploy target (host DNS, folder, systemd unit) live from the Pulumi stack in the platform repo at release time. No descriptor file needs to be committed or kept in sync. The service repo only needs a deployments/ directory that names the platform repo and the artifact path per environment.

Delivery types

Type	Status	Description
raw	Available	SSH-push of a gzip payload
container	Reserved	Pull-based container deployment (future)