Skip to content
Intropy
RunDeploy

Deploy

Deploying an Intropy System is four moves, all through Git. CI builds an image per component; intropy release create names what it built (a version, the source commit, the exact image digests) as an immutable manifest. intropy deploy pin writes those digests into one environment’s overlay in the GitOps repository, and ArgoCD reconciles the cluster toward the commit. intropy deploy promote then copies the digests one environment runs into the next, resolving nothing along the way, so what reaches prod is byte-for-byte what staging tested. An environment marked sync: manual is the gate: a deploy or promotion into it records intent and stops, and a person spends the gate with deploy diff and deploy sync. kubectl is never involved.

release 1.4.2commit · digestspinGITOPS REPOSITORYdevsync: autopromotestagingsync: autopromoteMANUAL SYNC GATEapplied by deploy syncprodsync: manualreconcilesArgoCDapplies each environment’s overlay to its cluster
FIG D1The environment ladder: a release is pinned into dev, its digests promoted upward unchanged, and prod applies only through the manual sync gate.

The pages in this section, in the order a team meets them:

  • GitOps repository — the repository everything above edits: deploy.yaml, the directory layout, and onboarding a System with manifests create.
  • Releases — naming what CI built: release create, list, and show, and why publishing a release changes no environment.
  • Promote and sync — moving digests through the environment graph: pin, promote, diff, status, and sync.
  • Local cluster — rendering the same manifests onto a cluster on your own machine with manifests render --env local.

If the model behind this (topology, releases, the repository as deployment state) is new, read Runtime concepts first. Flag-by-flag detail lives in the CLI reference: intropy manifests, intropy release, intropy deploy.