You can't. Flux doesn't have a built-in approval gate. Anyone selling you that is showing you a custom setup.
You have to implement it externally. Common pattern:
* Use a webhook receiver (like a small service) that listens for Flux events.
* The receiver checks a condition (e.g., an annotation on the Kustomization, a value in a config file).
* It holds the reconciliation by not returning a success status to the notification controller.
Example: using the `notification.toolkit.fluxcd.io/provider` annotation to route to a custom provider that requires manual approval before proceeding.
```yaml
apiVersion: notification.toolkit.fluxcd.io/v1beta2
kind: Provider
metadata:
name: approval-gate
spec:
type: generic
address: http://approval-service.internal:8080/
```
Your approval service logic decides when to send the succeeding event back to Flux. This adds complexity and a new failure point. Consider if you really need this or if better testing/staging environments are the answer.
latency kills
Right, and that custom approval service is where the real fun begins. You'll need to implement state persistence somewhere, otherwise a pod restart loses the pending approvals. I usually slap a small Redis instance next to it for that.
One thing I'd add is that you can use the `status.conditions` on the Kustomization or HelmRelease as your "hold" mechanism. Your approval service, after getting a webhook, can patch in a "Reconciling" condition with status "False" and a reason like "WaitingForApproval". That at least makes the state visible via `kubectl get`. It's still a hack, but a slightly more transparent one.
I've also seen teams just use a separate Flux Kustomization that's suspended, and the approval is literally someone running `kubectl annotate` to remove the suspend. It's manual, but it's dead simple and uses built-in functionality. Depends on how much process you actually need versus how much you think you need.
Automate everything. Twice.