Do I need an OAuth app or a particular provider?

No. A deploy target is ultimately a URL Zuuna calls with your headers and body — a GitHub workflow, GitLab pipeline, Jenkins job, n8n flow or your own script.

Does an approval expire when more commits arrive?

Yes. The approval is pinned to the commit state it approved. If something lands afterwards it no longer holds — a specific state was approved, not the idea of the release.

Can I get past the gate?

Only with approval rights, a written reason and an audit entry. Break-glass is for the production emergency, not the daily routine — and it leaves visible traces.

How many targets can I create?

One per environment per group — staging and production are two targets with separate credentials and separate gates.

Set up a deploy target and approval gate

In many teams deploying means: find the right script, the right branch, the right person with the right rights. In Zuuna it means: a button on the release — with an approval gate in front, if you want one. Deploy targets belong to the Developer plan.

What you need

The Developer plan — see pricing.
A release bound to a git tag.
A pipeline that can be triggered over HTTP — which is practically any.

1. Check the prerequisites

The deploy target hangs on the group, the deploy button on the release. Without a tagged release there is nothing to ship.

2. Create the deploy target

A target is a URL plus whatever your pipeline expects: a GitHub workflow dispatch, a GitLab pipeline trigger, a Jenkins job, an n8n webhook — or a plain webhook with your headers and body. The credential is stored encrypted and never shown again.

3. Understand why the credential is bound to the URL

One deliberate quirk: change the URL and the credential is deleted. Otherwise anyone with write access could quietly point the URL at their own server and redirect the stored secret to it. New URL, new credential — the small inconvenience is the protection.

4. Pick the approval mode

Three levels, honestly named:

No gate — the button deploys immediately. Usually right for staging.
Record only — approvals are captured, nothing blocks. The adoption stage.
Hard block — no approval, no deploy. For production.

Plus the decision whether self-approval is allowed — whether the same person may trigger and approve. Four-eyes means: no.

5. Deploy from Zuuna

On the release: click deploy, read the spelled-out version, type to confirm. The typing is not ceremony — it prevents the muscle-memory click on the wrong release.

6. Follow the status on the board

The pipeline reports progress back and the release shows it: queued → building → deploying → live, with waiting under a gate and failed on error. Whoever wants to know whether v2026.08.1 is out looks at the release — not at three CI tabs.

7. Know about break-glass

For the emergency there is a route past the gate — deliberately uncomfortable: approval rights required, a written reason mandatory, an audit entry guaranteed. And one limit the feature itself states openly: the gate guards Zuuna's button, not your pipeline. Anyone who can deploy straight from CI is not stopped here — branch protection remains your job.

Troubleshooting

The deploy does not start. Check the credential — and whether the URL changed since it was created (then the credential is gone, see above).
"Approval required." The gate is set to hard. Get an approval — or break glass, with a reason.
The approval vanished. Commits arrived after it; it was pinned to the old state. Approve again.
Status stuck on queued. The pipeline is not reporting back — its token lacks deployments:write.

Next steps

Read the code graph — what actually went live.
Bind a release to a git tag.
Project management for developers.