Block bad Kubernetes releases before they reach production

A deployment gate is the last automated check between your code and your users. It asks one question: is this release safe to ship? If the answer is no, the pipeline fails, the developer gets immediate feedback, and the bad release never touches the cluster. Most Kubernetes teams lean on code review and staging to catch problems, but those processes miss misconfigured resource limits, missing security contexts, vulnerable base images, and policy violations that only surface on a real cluster. kubeqa deployment gates are CI/CD-native quality gates that validate your manifests and images at deploy time and block releases that break your quality, security, and compliance standards.

How it works

kubeqa runs gate as a single step in your pipeline. It validates the manifests in a directory, optionally scans every container image they reference, enforces your policies, and runs a compliance pre-check, then exits with a standard code: 0 for pass, 1 for failure, 2 for warnings-only. That exit code is what makes integration trivial on any platform.

# .github/workflows/deploy.yaml
- name: kubeqa gate
  uses: nomadx-ae/kubeqa-action@v1
  with:
    fail-on: critical
    compliance: cis-1.8

Run the same logic locally before you ever push:

$ kubeqa gate run k8s/ --policies .kubeqa/policies/production.yaml --fail-on high

  Scanning 14 manifests...

  CRITICAL  deployment/payments: privileged security context
  WARNING   deployment/frontend: no readiness probe
  INFO      deployment/worker: image tag is 'latest' (prefer pinned versions)

  Gate: FAILED (1 critical finding)

kubeqa fills the gap left when Datree shut down in 2023 and removed a popular deployment-policy enforcement layer from the ecosystem. Unlike admission controllers such as OPA Gatekeeper or Kyverno, which reject resources at the API server inside the cluster, kubeqa gates run before the manifest reaches the cluster. Both have value: admission controllers are a safety net, while pipeline gates are a shift-left prevention layer that gives developers faster feedback.

What it covers

A kubeqa gate validates across five layers and checks for over 80 manifest issues out of the box:

• Manifest validation - missing resource limits, privileged containers, root users, missing liveness or readiness probes, unpinned latest tags, port mismatches, and missing required labels.
• Image scanning - every container image is scanned for known vulnerabilities via Trivy, Grype, or Snyk, then your severity threshold decides what blocks.
• Policy enforcement - custom organizational rules written in a simple YAML format. No Rego, no CEL, no programming language to learn.
• Compliance pre-check - verify the incoming manifests will not push the cluster out of compliance with a target framework like CIS Kubernetes Benchmark v1.8, catching regressions in the pull request instead of the quarterly audit.
• Diff analysis - compare incoming manifests against what is running so an accidentally removed memory limit or downgraded security context gets flagged before it ships.

Why it matters

• Catch issues pre-production, where a fix is a code-review comment rather than a 3am incident.
• One tool covers manifests, images, policy, and compliance instead of stitching together four to six separate checks.
• Findings are non-negotiable and automatic, so quality standards no longer depend on whether a reviewer remembered to look.
• Gates share the same engine as kubeqa health scans, chaos experiments, and compliance audits, so findings correlate across your whole QA pipeline.

CI/CD integration and severity thresholds

kubeqa gates plug into GitHub Actions, GitLab CI, ArgoCD, Jenkins, and Flux. Because not every finding deserves to block a release, kubeqa uses a four-level model - critical, high, warning, and info - and lets you choose what fails the pipeline with configurable severity thresholds like fail-on: critical.

# .kubeqa/gate-config.yaml
gate:
  fail-on: high          # Block on high and critical
  warn-on: warning       # Print warnings but don't block
  namespace-overrides:
    development:
      fail-on: critical  # More lenient in dev
    production:
      fail-on: warning   # Stricter in production

Roll out without breaking day-one pipelines: start in audit mode to baseline your violations, then tighten progressively from critical to high to warnings.

$ kubeqa gate run manifests/ --audit-only

Open source and pricing

kubeqa is Apache 2.0 licensed and the CLI is free forever. Deployment gates and every other scanning feature stay open and ungated. kubeqa Cloud (coming soon) adds multi-cluster dashboards, historical trends, team collaboration, SSO, audit logs, and compliance PDF exports, but it never gates the open-source engine. See pricing for details.

Related

• Kubernetes Deployment Gates: Blocking Bad Releases Before They Hit Production - the deep-dive walkthrough.
• Cluster Health Scanner
• Chaos Engineering
• Compliance Automation
• Kubernetes QA Tools Compared

Add gates to your pipeline today: brew install nomadx-ae/tap/kubeqa. Star kubeqa on GitHub and see pricing.