GitOps Configuration Ownership
Management stores the appliance’s desired configuration in Gitea. It publishes a captured configuration to the appliance’s node-local registries during an active cluster access lease. Flux then reconciles that selected configuration on the appliance.
Use the Management task pages for routine changes. Before editing repository files, check which settings belong to the release and which belong to your installation.
Repository Layout
| Path | Owner and purpose |
|---|---|
|
Release-owned component declarations and guides. An appliance update replaces this directory, overwriting any changes you made here. |
|
Installation settings and encrypted secrets, including product overrides and HSM configuration. |
|
The installation’s reconciliation root and generated Flux settings. |
|
Identities and digests of packaged Helm charts. Chart content is delivered separately through appliance registries. |
Keep installation settings in config/ and the designated overrides in clusters/mtg-vapp/. The presence of a chart value or internal manifest does not make it a supported customer setting. See configuration for the supported workflow.
Save, publish and verify
Gitea is authoritative during normal operation. Only changes to main trigger ordinary publication. Each publication captures a fixed revision with its Git history, branches and tags. Later commits follow in later publications.
Publication succeeds after Management verifies delivery to the configured registries and confirms the selected artifact. It does not prove that Flux has applied every resource or that workloads are healthy. Check monitoring and logs after a change.
Transient publication failures retry automatically. Invalid configuration produces a dashboard notice linked to its Gitea commit. Correct the configuration in a new commit. Re-pushing the same revision is not a new publication request. A successful later publication clears the notice; merely saving a correction does not.
When access expires, reconnect to permit synchronization. A pending appliance update pauses ordinary configuration changes and publication; use the update workflow’s available controls before resuming configuration work.
Recovery Implications
Management reconstruction restores the selected published GitOps artifact and captured history from the surviving appliance. A full backup captures the selected artifact and its history as part of the recovery set.
The original installation artifacts do not contain every later unpublished edit. Keep sensitive artifact bundles outside the appliance and use the published-state recovery workflow instead of reimporting an old initial repository.