GovernanceMode v3 · on k3s · interactive

See how GovernanceMode actually runs

Five small machines you can poke at: send a request through the cluster, change a file and watch which images rebuild, boot a pod and break it, trace an environment variable from file to process, and see how one Helm chart turns into 14 services. The plain-text image reference stays at gm-images.adnan.vaza.dev.

host ubuntu@84.8.125.207 · k3s, namespace governance-mode, release gm · https://governance-v2.advancedcontrols.tech/governance_mode/ · as of 2026-11-08

CHAPTER 1

Follow a request through the cluster

Pick something a user does, then press Play (or Step to go one hop at a time). The dot is the request; the list below says what each box does with it.

The user…
    CHAPTER 2

    Build the images: what rebuilds when you change something?

    Every PHP service sits on one shared base that compiles the slow gRPC extension once. Choose a change and see which images rebuild (purple), which come from cache (dashed), and how long you wait. Some changes need no build at all.

    I changed…

    Pick a change above

    Or click any box in the diagram to see what that image is.

    wait time, roughly
    –

    CHAPTER 3

    Boot a pod, then break it

    Every PHP service pod goes through the same stages before it gets traffic. Choose what is wrong (or nothing), press Start pod, and watch where it stops and what kubectl get pods would say.

    What's wrong?
    kubectl -n governance-mode get pods
    NAME regulator-7c9… STATUS –

    Press Start pod.

    Click a stage

    Each box in the diagram is clickable: it shows what that stage really runs.

    CHAPTER 4

    Trace an environment variable from file to process

    Settings take one of two roads. Run-time values travel as Kubernetes objects and are read when the pod starts; change them and the pod restarts, no build needed. Build-time values (the front end's VITE_*) get compiled into the JavaScript, so changing one means building a new web image. Pick a variable.

    Variable

    inside the pod: envFrom is applied top to bottom; a later source overwrites an earlier one

    Then php artisan config:cache freezes these values when the container starts, which is why a changed value needs a pod restart.

    CHAPTER 5

    One chart, 14 services: where does each value come from?

    The 13 PHP services and the Reverb websocket server do not have 14 charts. They are one generic chart, charts/php-service, listed 14 times under different aliases. Each alias gets the chart's defaults, then the umbrella values.yaml, then the site file. Pick a service to see the merged result and which file set each value.

    Service
    1 · charts/php-service/values.yamldefaults for any PHP service
    →
    2 · values.yaml (umbrella)
    →
    3 · site/84.8.125.207.yaml

    Merged values

    keyvalueset by

    What Helm creates for it

    Plus, once for the whole release

    Ingress governance-modehost governance-v2… → web:80, TLS from cert-manager
    Ingress governance-mode-ipno host rule: the bare IP over plain HTTP (ingress.bareIp)
    Ingress governance-mode-reverb/app → notification-reverb:7002 (ingress.reverbPath)
    Issuer letsencrypt-prodACME HTTP-01 through ingress-nginx
    NetworkPolicy ×2mongodb and redis accept only pods from this namespace (no DB auth)
    mongodb · redis · api-gateway · webtheir own small subcharts

    Secrets are never in values files. scripts/20-deploy.sh creates gm-shared, gm-<service> and gm-registry before helm runs; the chart only refers to them by name.

    CHAPTER 6

    Test yourself

    Six questions about the stack you just explored.