intropy manifests

Authoritative reference for intropy manifests: inspecting, rendering, and creating Kubernetes manifests. The deployment workflow these commands serve is described on the intropy.run Deploy pages.

All three subcommands derive the same deployment model from the System topology and the scaffold records: extractors become CronJobs, every other Component becomes a Deployment, and the model resolves app IDs, pub/sub scopes, topics, and ports. What differs is the side-effect boundary: inspect writes nothing, render writes YAML to stdout, create writes a review branch to the GitOps repository. Pinning image digests afterwards is intropy deploy, never this command.

The surface

intropy manifests inspect [flags]
intropy manifests render [flags]
intropy manifests create [flags]

intropy manifests inspect

Read the System topology and scaffold records, resolve the template release, and print the components, workloads, ports, and available local fixtures. Nothing is rendered or written, and Git is not touched. Use -o json for the machine-readable model.

Flag	Description
-o, --output <format>	plain (default) or json.
--system <name>	Selects the host when the workspace holds several.
--template-repo <owner/repo>	Template library on GitHub. Defaults to templateRepo from configuration, or INTROPY_TEMPLATE_REPO.
--template-version <tag>	Template release tag. Defaults to the latest release.

intropy manifests inspect

reading topology from order-flow (building first; this can take a minute)
fetching integrio-intropy/intropy-templates@v0.4.1
system          order-flow
template        integrio-intropy/intropy-templates@v0.4.1
local fixtures  sftp, http, file, blob

components
  order-extractor  extractor  cronjob
  order-loader     loader     deployment

ports
  order-extractor-source  external system not declared
  order-loader-destination  external system not declared

Note the deploy template release is resolved separately from the release the components were scaffolded with: unpinned, the latest library release is fetched. Pass --template-version to pin it.

intropy manifests render

Render and validate the complete manifest stream for one environment. YAML is written to stdout; every progress message, prompt, and error goes to stderr, so the pipe is safe:

intropy manifests render --env local | kubectl apply -f -

The complete render is buffered and validated (kustomize build runs on the result), so a failed render writes no YAML: if topology discovery, template rendering, Kustomize, or final validation fails, stdout stays empty. Nothing is written to Git, and the command does not inspect the cluster.

Flag	Description
-e, --env <environment>	Target environment. Required.
--binding <port>=<fixture>	Local port fixture. Repeatable; one per port.
--image <component>=<name:tag>	Image override for one component; --image :<tag> retags every component. Repeatable.
--namespace <ns>	Target namespace. Defaults to the System name.
--system <name>	Selects the host when the workspace holds several.
--template-repo <owner/repo>	Template library on GitHub. Defaults to templateRepo from configuration, or INTROPY_TEMPLATE_REPO.
--template-version <tag>	Template release tag. Defaults to the latest release.

Local bindings

A topology port names an external edge but does not decide its deployed adapter. For --env local, every port needs a fixture binding. When one is missing and the terminal is interactive, a selector asks for it (on stderr, so stdout stays YAML-only); the selection applies to that render only and is never saved. A non-interactive render fails instead:

reading topology from order-flow (building first; this can take a minute)
fetching integrio-intropy/intropy-templates@v0.4.1
error: local bindings are required for ports: order-extractor-source, order-loader-destination
pass one '--binding <port>=<fixture>' for each; available fixtures: sftp, http, file, blob

With one --binding per port the render is reproducible:

intropy manifests render --env local \
  --binding order-extractor-source=file \
  --binding order-loader-destination=file

This emits a Deployment for the loader (with dapr.io annotations and app-port 8080), a CronJob for the extractor, and the Dapr Component resources the fixtures require.

intropy manifests create

Render one environment from the System topology and create its missing files on a manifests-create/<domain>-<system>-<environment> review branch in the GitOps repository. The command is strictly additive:

• a missing file is created;
• a byte-identical existing file is accepted and left alone, so a repeated or interrupted run is harmless;
• an existing file that differs is a conflict and stops the whole operation;
• no file is ever replaced or deleted, and the default branch is never updated directly.

On success, only the created paths are committed and the review branch is pushed; a no-op creates no commit. Created files carry no ownership marker: after creation they are ordinary, editable GitOps source, and port bindings are left as explicit REPLACE-ME configuration for maintainers to complete. Creation is one-time onboarding for the selected environment; later structural changes are normal, reviewed GitOps edits.

Flag	Description
-e, --env <environment>	Target environment. Required.
--domain <name>	Domain to place the System under. Defaults to where it already is in the GitOps tree, else the workspace layout.
--dry-run	Report file actions without creating manifest files, commits, or pushes.
--diff	Print generated file differences; like --dry-run, writes nothing.
--gitops-repo <url>	GitOps repository URL. Defaults to gitopsRepo from configuration, or INTROPY_GITOPS_REPO.
--system <name>	Selects the host when the workspace holds several.
--template-repo <owner/repo>	Template library on GitHub. Defaults to templateRepo from configuration, or INTROPY_TEMPLATE_REPO.
--template-version <tag>	Template release tag. Defaults to the latest release.

The GitOps path is domains/<domain>/<system>/<component>/; the System comes from the topology record.