Every team wants a bespoke approval gate in your pipeline, and you did not sign up to maintain governance logic in Groovy. ArcRelease holds the gates, the freezes and the dependency graph above the pipeline and reads what your CI already emits — nothing in the deploy path changes.
It sits above Jenkins, GitHub Actions and GitLab CI as a read-only layer: it ingests deployment events, enforces dependencies and freezes through an advisory check you choose whether to gate on, and holds no deployment credentials — so it cannot break a build.
Every team wants a bespoke approval gate in my pipeline. I did not sign up to maintain governance logic in Groovy.
Governance logic rots in pipeline scripts nobody owns and everybody is scared to touch.
When the tool is down, the last thing I want is for it to be able to stop a deploy.
Gates, freezes and dependency rules live in ArcRelease, not in Groovy you maintain. Teams get the approval logic they want without turning your CI into a governance engine.
ArcRelease reads what your tools emit and writes an advisory check. It holds no deploy credentials, so if it is unavailable your deploys still ship — that is an architectural property, not a promise.
No. There are no runners, no agents and no plugin in your pipeline. ArcRelease reads deployment events over webhooks and APIs.
Only if you deliberately wire its advisory check into branch protection. By default it is advisory, and it never holds the credentials that would let it deploy or block on its own.
Tell us about your release process. Connect your stack in ten minutes, run a Gaja preflight on a real release, and see the reasons behind the verdict.
Free plan · ten minute setup · we reply in one to two business days