Skip to content
chant Docs Demo

Live Import

llms.txt lists every page for an agent
Optional: hand this page to your coding agentThe steps work by hand too.
Show the whole prompt
Read https://intentius.io/chant/guide/live-import/.
Run `npx chant lifecycle plan <env>` and `npx chant import --from <env> --output src/` only for the environment I name, with `--name` or `--type` to select the resources I ask for. Both only read the live system.
Review the generated files for secrets before anything else, replace each secret with a reference, and tell me what you replaced.
Run `npx chant build` and `npx chant lint`, and open a pull request with the new source.
Never deploy to a real cloud account or shared environment (with `chant run`, `chant components` or a platform's own CLI), approve (a pull request review, `chant approve` or `chant run approve`), override a policy denial (`chant approve policy-override`), or merge; never cut or publish a release (`chant release cut --yes` or `chant release publish`), push or delete a `ci/*` tag (`chant ci tick` pushes them), or change the value of an existing flag; never touch `.chant/allowed_signers` or `chant/lifecycle`.

chant import <template-file> reads a template from disk. chant import --from <env> reads the live cloud or cluster instead, regenerating chant TypeScript from what is actually running. This is the cloud → code direction. Use it to adopt infrastructure you didn’t author or to pull an orphan back into source.

How it works

Section titled “How it works”
Terminal window
chant import --from prod --output src/
  1. Resolve the environment the way chant lifecycle diff --live does.
  2. Call each project lexicon’s exportResources() capability for full-fidelity config.
  3. Generate TypeScript with the same by-category organization as file import.

Unlike chant lifecycle observation, which only ever reads scrubbed metadata, live import emits the resource’s full input config, so it may include secrets. The command prints a warning; review generated files before committing.

Selectors

Section titled “Selectors”
FlagEffect
--type <ResourceType>only resources of this type
--name <name>only the resource with this name
-d, --lexicon <name>restrict to one lexicon (e.g. aws, k8s)
--ownedonly chant-owned resources (carrying the ownership marker)
--verbatimkeep server-defaulted fields instead of stripping to declared shape
--skip-undeclarableimport what can be declared, and warn about each live object no declaration can hold instead of failing

Per-provider fidelity

Section titled “Per-provider fidelity”

Each lexicon reads live config its own way and strips it to the shape you would have authored:

LexiconSourceStripped by default
AWScloudformation get-template --template-stage Originalnothing — the original template is already declared shape
Azureaz group export (the env is the resource group)nothing — the exported ARM template is already declared shape
KubernetesTyped API client LIST per kind (chant #1074)status, managedFields, server metadata, server annotations
GCP (Config Connector)kubectl get <*.cnrm.cloud.google.com> -A -o jsonstatus, server metadata, cnrm.cloud.google.com/* annotations

--verbatim keeps the stripped fields when you need an exact copy rather than a clean authoring starting point.

The adopt-an-orphan loop

Section titled “The adopt-an-orphan loop”

When drift detection reports an orphan — something in the cloud that source doesn’t declare — live import is how you adopt it:

Terminal window
# 1. see what's orphaned
chant lifecycle plan prod


# 2. regenerate the orphan as chant TypeScript
chant import --from prod --name my-bucket --output src/


# 3. review, commit — the orphan is now declared

To automate this across many resources as a reviewable PR, use the ReconcileOp workflow, which runs exactly this loop and opens the PR for you.

See also

Section titled “See also”

chant