GitOps ownership

Overview

Terraform prepares cloud infrastructure, and Helm bootstraps PIG once. After bootstrap, PIG owns its application releases, including supervisor updates. GitOps can continue to own your desired deployment configuration and secret delivery.

Use this guide before you bootstrap PIG through a GitOps controller, and before you change the collector Ingress later. It shows which tool owns each resource and how to hand ownership to PIG, so that no controller reverts the supervisor’s self-updates.

Resource ownership

Each owner manages these resources:

Owner	Resources
Terraform	Cloud databases, storage, workload identity trust and grants, networking, backup and retention settings.
Your Kubernetes configuration	Namespaces, the analyzer ServiceAccount and its identity annotations, `PIGDeployment.spec`, external Secret delivery, the database CA ConfigMap, and certificates.
The `pig-supervisor` Helm release	The supervisor Deployment, its RBAC, and the HTTPS collector Ingress, configured through the chart’s `ingress` values. Its first install creates the PIG custom resource definition.
The supervisor	Generated analyzer Deployment and Service, migration and verification Jobs, its own image updates, and additive custom resource definition updates within installed permissions.

The supervisor can’t widen its own permission grants. A release that needs new bootstrap permissions stays blocked until an administrator reviews and installs those grants. Cloud management permissions stay with Terraform.

Don’t put the bootstrap in a Terraform helm_release resource, and don’t reconcile PIG-generated workloads through another controller. PIG’s release policy is the single owner of their versions. Keep the bootstrap chart and values for recovery, but don’t reapply them on a schedule.

Bootstrap with Helm directly

Run the Helm installation once. Helm doesn’t reconcile resources continuously. After you create PIGDeployment, use its release fields for application updates, pauses, and pins.

Run a later helm upgrade only to change the collector ingress or to follow a release’s documented procedure. Each time, carry forward the supervisor’s current image and release catalog.

Bootstrap with Flux

If Flux installs the bootstrap, hand ownership to PIG before you enable application updates.

Create an OCIRepository for oci://ghcr.io/promptless/charts/pig-supervisor. Pin it to the chart’s OCI digest from the release manifest, artifacts.supervisorChart.ociDigest. For 0.3.6, the digest is sha256:ee04fc023c7a6a22fde882cdb1852646b08804fe822a246d4040c7afe73b09fb.
Create a HelmRelease in pig-system with the same bootstrap values as the direct Helm guide, including watchNamespace: pig and the required ingress fields.
Keep PIGDeployment out of the reconciled path while Flux installs the chart. The supervisor waits for this resource before it starts release transitions.

Wait for the bootstrap HelmRelease to become ready:

kubectl wait helmrelease/pig-supervisor --namespace pig-system \
  --for=condition=ready --timeout=10m

Commit spec.suspend: true on that HelmRelease in Git. Suspending only the OCIRepository leaves the installed release active; see Flux’s HelmRelease suspend control.
After Flux applies the change, confirm that the HelmRelease is suspended. The command prints true:
Terminal window
```
kubectl get helmrelease pig-supervisor --namespace pig-system \
  -o jsonpath='{.spec.suspend}{"\n"}'
```
Add your PIGDeployment to the GitOps path that owns desired configuration. Keep its secret delivery and analyzer ServiceAccount in that path too.

Keep the bootstrap HelmRelease suspended and present in Git. Deleting it can trigger a Helm uninstall, and resuming it can restore an older chart over PIG’s self-updates. Don’t reconcile the chart’s rendered resources separately through a Kustomization. The one exception is the collector Ingress, described in Change the collector ingress.

Bootstrap with other GitOps controllers

Run a direct Helm bootstrap outside the controller’s managed application set. Let the controller manage only the customer-owned configuration in the ownership table. Turning off automatic sync isn’t a durable ownership boundary while manual sync or pruning can still touch PIG’s generated resources.

If your policy requires continuous Helm reconciliation, choose manual Helm management. Your platform workflow then applies every release.

Change the collector ingress

The bootstrap release owns the collector Ingress, so hostname, class, TLS, and annotation changes go through Helm. These changes don’t change the analyzer’s registered configuration or trigger its revalidation.

The supervisor may have updated its own image since bootstrap. Carry its current values into the upgrade so that the upgrade doesn’t revert a self-update.

Read the image the supervisor runs now:

kubectl get deployment pig-supervisor --namespace pig-system \
  -o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'

In your bootstrap values, set image.digest and releaseCatalogURL to the values the supervisor runs now, and make your Ingress changes.

Render the verified chart, where PIG_VERSION is the chart version you verified:

helm template pig-supervisor "./pig-supervisor-${PIG_VERSION}.tgz" \
  --namespace pig-system --values supervisor-values.yaml > rendered-supervisor.yaml

Compare the rendered Ingress with the live object.

Upgrade the bootstrap release:

helm upgrade pig-supervisor "./pig-supervisor-${PIG_VERSION}.tgz" \
  --namespace pig-system --values supervisor-values.yaml --wait --timeout 5m

If Flux performed the bootstrap, keep its HelmRelease suspended. Either run the explicit upgrade above with current values, or manage the rendered Ingress directly in your GitOps repository.

Change release policy and recover a cluster

Commit pause and pin changes to the GitOps source of PIGDeployment.spec.release. If Git still declares another value, your controller can revert a live patch.

For cluster recovery, restore the same deployment identity and customer-owned configuration. Repeat the bootstrap handoff before you create the restored PIGDeployment. To reconnect retained storage safely, follow Manage updates and recovery.