Serialization

The fountain lexicon serializes to fountain’s own manifest YAML — nothing else. fountainApply reads that same YAML, so there is no sidecar to keep in sync with it.

Manifests

Each declared resource becomes a manifest document with apiVersion: fountain.dev/v1:

apiVersion: fountain.dev/v1
kind: Environment
metadata:
  name: team-env
spec:
  name: team-env
  networking_type: limited
  networking_config:
    allowed_hosts:
      - github.com

metadata.name is the resource’s declared name, not the name of the variable you exported it as. fountain reconciles by that name, so renaming the variable does not orphan the resource. An entity declared without a name falls back to the export name.

The output is ejectable — fountain apply -f accepts it verbatim, so adopting chant here does not trap the manifests behind chant.

Applying the manifest

fountainApply parses this same YAML and sends it to fountain’s bulk POST /api/apply endpoint in one request — the server reconciles by name, Environment → Vault → Agent, and resolves an agent’s environment reference itself, against the manifest or the tenant’s existing environments. See the Ops page for the activity’s own behavior (prune, secrets, failure reporting).

Ownership

Resources carrying metadata."managed-by": chant are chant-owned. That marker gates the opt-in prune (fountainApply deletes only owned resources absent from the manifest) and the --owned filter on drift and live export. Set it on every declaration you want reconciled.

Secrets

spec.secrets is authored as an ordered {key, value}[], same as any other typed prop. fountainApply converts it to the {KEY: value} map fountain’s bulk apply expects on the wire; the server upserts it through the encrypted envelope path. Values are write-only upstream, so this is upsert-always — a changed value cannot be detected, only overwritten.