Which tool can gate a release in CI/CD today
If your team wants a pass or fail signal on every model, prompt or config change, promptfoo is the tool that can gate a release today. Its documentation covers CI/CD setups for GitHub Actions, GitLab CI and Jenkins, and it publishes a GitHub Marketplace action, promptfoo/promptfoo-action. Its --fail-on-error flag fails the build on any test failure, and it writes JSON, HTML and JUnit XML output that native CI test report viewers can read. garak writes JSONL reports of every attempt and a hit log of attempts that found a vulnerability, but its README does not describe CI pipeline integration. You would need to write the pass or fail logic yourself, and you should confirm that against the garak user guide before you commit to it.
The right answer depends on what the gate is for. A per-commit gate needs a fast, deterministic exit code, and promptfoo fits that pattern directly. A periodic deep scan, such as a weekly run against a new model version or a full probe sweep before a major release, is a different job. Plan for promptfoo's --fail-on-error in the pull request pipeline and treat garak as a scheduled job whose output is reviewed by a person or parsed by a script. Before you rely on either, confirm that the runner has the required versions: promptfoo 0.124.1 requires Node.js 22.22.0 or newer, and garak's PyPI package requires Python 3.11 or newer.
Neither tool provides a CI gate and a deep scan out of the box in the same way, so decide who owns the parsing step. For promptfoo, check whether the JUnit XML output is enough for your reviewers or whether you need to transform the JSON. Direct SonarQube output is available only in Promptfoo Enterprise. For garak, write a small script that reads the JSONL report and fails the job when the hit log is not empty, and agree on a threshold with your security owner. For the wider comparison of the two tools, see the overall verdict on this page.
How promptfoo and garak differ on CI/CD fit
This table compares how promptfoo and garak fit into a release pipeline, from documented CI platforms and failure behavior to report formats and what you must build yourself. Read the garak column as the work your team takes on, since its README does not describe CI integration.
| Aspect | promptfoo | garak |
|---|---|---|
| Documented CI platforms | GitHub Actions, GitLab CI and Jenkins, plus Azure Pipelines, CircleCI, Bitbucket Pipelines and Travis CI, with a GitHub Marketplace action | No CI pipeline integration described in its README; confirm any wrapper your team builds |
| Build failure behavior | --fail-on-error fails the build on any test failure | Marks a probe as FAIL with a failure rate when an attempt produces undesirable output; a pipeline must map this to a build result |
| Report formats | JSON, HTML and JUnit XML for native CI test report viewers | JSONL report of every attempt and its evaluation, plus a hit log of vulnerable attempts and a garak.log file |
| Native test report viewers | Yes | No |
| Runtime requirements | Node.js 22.22.0 or newer for the 0.124.1 npm release | Python 3.11 or newer, developed on Linux and macOS |
| Install method | npm package, promptfoo/promptfoo-action for GitHub | pip install from PyPI |
| Output shape for reviewers | Pass or fail per test case in CI report views | Per-probe FAIL and failure rates, with attempt-level detail in JSONL to parse |
| What the pipeline must add | Little beyond the documented setup for basic gating; export to other tools such as SonarQube requires a transform in open source | A parser for JSONL and hit logs, an exit-code policy, and a budget for run time; confirm how your wrapper handles the default 5 generations per prompt |
What changes the CI/CD result in practice
Six factors decide whether a promptfoo or garak gate fits your pipeline. Some are about the CI platform and report format, others about scan volume and how the self-hosted server is operated. Check each one before you choose a gate design.
Your CI platform
promptfoo documents setups for GitHub Actions, GitLab CI and Jenkins, plus Azure Pipelines, CircleCI, Bitbucket Pipelines and Travis CI, and publishes the promptfoo/promptfoo-action Marketplace action. The garak README does not describe CI pipeline integration, so you would write the wrapper yourself. Confirm which runner your organization uses before you estimate the integration work for either tool.
How your team reads results
promptfoo can write JSON, HTML and JUnit XML, so a native test report viewer can show failing cases beside other unit tests. garak writes a JSONL report of every attempt and a hit log of attempts that found a vulnerability. Those files suit security reviewers who triage individual prompts, but your pipeline must parse them before developers see a clear pass or fail.
SonarQube output requirements
If results must reach SonarQube, promptfoo's CI/CD page says direct SonarQube output is available in Promptfoo Enterprise. With the open-source tool you export JSON and transform it yourself. Decide early whether that transform is an acceptable maintenance cost, or whether the SonarQube requirement pushes you toward a commercial tier.
Probe volume per run
garak makes 5 generations per prompt by default, and a probe is marked FAIL when any attempt produces undesirable output. Every probe multiplies the number of model calls, so a full scan can be slow and costly on a per-commit pipeline. Run a small, fixed probe set on each change and reserve the full scan for scheduled runs. Ask your provider how it bills for the calls each run makes.
Self-hosted promptfoo limits
The self-hosted promptfoo app stores data in a local SQLite database that cannot be shared across replicas. It has no RBAC, no horizontal scaling and no built-in authentication or SSO, and the documentation says it is not recommended for production. If you host it for shared reporting, put access control in front of it and do not expose it to the open network.
Whether you need Enterprise features
The Community edition is free and includes all evaluation features, all providers and red teaming with 10k probes per month. Enterprise adds SSO, team RBAC, continuous monitoring and SonarQube output at custom pricing, and On-Premise runs that functionality in your infrastructure. Compare the gate's needs against the free tier first, and request a written quote only for the features you cannot meet without it.
How a promptfoo gate and a garak scan fit one pipeline
Run promptfoo on every commit as the release gate and run garak on a separate schedule or after a model change. The gate is the part that can block a merge, so it should be fast and deterministic enough to trust. In a typical setup, a commit triggers a promptfoo run configured to exit non-zero on any failing test through --fail-on-error, and the JSON, HTML or JUnit XML output is published to the CI system's native test report viewer. The JUnit file is the piece to wire into your pipeline first, because it turns individual red team and eval cases into visible failures that reviewers can open. Confirm the exact flags and output paths against the promptfoo CI/CD integration documentation for your runner before you rely on them.
garak runs as a separate job because its default settings make it slow to gate on. By default garak makes 5 generations per prompt, and a probe is marked FAIL with a failure rate when any single attempt produces undesirable output. A probe that passes most attempts can still fail the run, so a single noisy result is not a clean signal for blocking a release. Its README does not describe CI pipeline integration, so a team that wants a scheduled garak job must write the wrapper itself: invoking the scanner, storing the run output, and deciding what counts as a failure. Plan for the runtime of the probe set you choose and for the triage time needed to review the JSONL report of every attempt and the hit log of attempts that found a vulnerability.
Assign triage ownership before the first scheduled scan produces a hit log. A reasonable split is that promptfoo failures block the merge, while garak findings open tickets for the model owner and security team to review, with the model version and garak version recorded in each report. Ask your team to confirm three things before adopting this layout: which garak probes match the application's risk, how long a full run takes against your target endpoint, and who decides whether a hit log entry is a true vulnerability or a detector error. Since garak v0.17.1 is the release pinned in this design, keep that version in the job definition so results remain comparable across runs.
How to test both tools in your own pipeline
This sequence lets your team check, on its own runners, whether promptfoo can fail a build and whether garak can run against your endpoint, then compare the output each one leaves behind. The result is a side-by-side view of the gate you can add to a release pipeline and the deeper scan you would run on a schedule.
Install both tools on a CI runner
A platform or security engineer adds a job to a non-production runner that installs promptfoo on Node.js 22.22.0 or newer, using the npm package, and garak with pip on Python 3.11 or newer. Pin both versions in the job so that later results can be reproduced. The step is done when the job prints a promptfoo version and a garak version without errors.
Build a sample promptfoo config with a known failure
An engineer writes a small declarative config file that points promptfoo at a test model or your staging endpoint and includes one assertion that the output is expected to fail. This is an illustrative setup, so the failing case is deliberate. The step is done when a local run shows the failing assertion in the console output.
Confirm the build fails with fail-on-error
The same engineer runs promptfoo with the --fail-on-error flag inside the pipeline job, using the GitHub Actions, GitLab CI or Jenkins setup your team already uses. The job should return a failing status code and stop the release stage. The step is done when the pipeline shows a red result and the downstream deploy stage does not run.
Open the JUnit output in your CI viewer
A platform engineer has the job write JUnit XML output and publishes it to the native test report viewer of the CI system. Check that each assertion appears as a test case with its name and status. Ask promptfoo for direct SonarQube output only if you use SonarQube, since the vendor documents that direct output in Promptfoo Enterprise, while open-source users export JSON and transform it. The step is done when the failing case is visible in the report view.
Point garak at your endpoint through the REST generator
A security engineer writes the short YAML file that describes your endpoint for garak's REST generator, then runs garak against a staging copy of the application using a scheduled or manual job rather than the release gate. Garak's README does not describe CI pipeline integration, so the job must be wired by your team. The step is done when garak finishes and writes a JSONL report and a hit log to the output directory.
Read the garak report and hit log
A security engineer opens the JSONL report, which records every attempt and its evaluation, and the hit log, which lists only attempts that found a vulnerability. Check whether a failing probe is marked as FAIL with a failure rate, which reflects the default of five generations per prompt. The step is done when each finding can be traced to a probe, a detector and a stored prompt.
Measure report size, runtime and triage effort
The team records how large each output is, how long each run takes on the runner, and how many minutes it takes an analyst to triage the findings from each tool, then decides which tool fits a per-release gate and which fits a periodic deep scan. Ask each vendor for guidance on report volume and retention, and confirm any SonarQube or custom parsing approach in writing before you commit to it. The step is done when the team has a short table comparing both tools on these measures.
Gate-only, scan-only or combined setups
Teams that change only prompts, system messages or model settings usually need a fast check that blocks a merge when a change breaks a known behavior. promptfoo leads here. Its declarative configs run locally, it can run checks in CI/CD pipelines, and its CLI can fail a build on any test failure with --fail-on-error. garak is a weaker fit as a merge gate because its README describes a command-line scanner that writes reports and does not describe CI pipeline integration. Its probes add value as a separate check of the underlying model.
- Gate with promptfoo: Put the eval suite in the pipeline and set
--fail-on-errorso any failing test stops the release. - Run garak on a schedule: Use it for longer probe runs, such as after a model version change, where waiting for results is acceptable.
- Read garak output as a record: Its JSONL report lists every attempt, and the hit log lists attempts that found a vulnerability.
- Pin both toolchains: garak requires Python 3.11 or newer and promptfoo requires Node.js 22.22.0 or newer, so runners need pinned versions.
- Confirm provider support: Check that your model provider is supported by each tool before you depend on it for a gate.
Check whether your changes ever touch the model itself. If they never do, a scheduled garak job may add little to a prompt-only team.
Regulated teams usually need more than a pass or fail result. They need records showing that testing happened on a defined schedule, against defined frameworks, with results kept for review. garak's per-run JSONL report of every attempt and its hit log give a detailed record of each scan, and its garak.log continues across runs. promptfoo's red teaming documentation references the OWASP LLM Top 10, the NIST AI Risk Management Framework and the EU AI Act, which helps map tests to a control set. Both tools produce material for your evidence file, but neither issues an audit report or certification.
- Keep scan records: Store garak JSONL reports and hit logs with the release record for each scheduled run.
- Map tests to frameworks: Use promptfoo's red team plugins aligned with the OWASP LLM Top 10 and NIST AI RMF as the mapping layer.
- Check access controls: Self-hosted open-source promptfoo has no RBAC, built-in authentication or SSO, so confirm whether that is acceptable for your environment.
- Compare Enterprise features: Team sharing, SSO, RBAC and continuous monitoring are listed for promptfoo Enterprise, with pricing set by quote.
- Ask your auditor: Confirm which evidence format and retention period they expect before you design the schedule.
Work out with your assessor which artifacts count as evidence before you choose a scan frequency or a tool.
Teams with an existing Jenkins or GitLab estate can usually adopt promptfoo with the least new plumbing. promptfoo documents CI/CD setups for both, plus JUnit XML output that native test report viewers can read. garak's README does not describe CI integration, so a team using garak in these systems must write its own pipeline stage, invoke the command, check the exit behavior and parse the JSONL report. That work is reasonable, but it is effort you own. For SonarQube, promptfoo's CI/CD page says direct output is available in Promptfoo Enterprise, while open-source users export JSON and transform it.
- Use the documented promptfoo setup: Start from the GitHub Actions, GitLab CI or Jenkins examples in promptfoo's CI/CD documentation.
- Publish JUnit results: Write JUnit XML so your existing pipeline test report shows failed cases beside other tests.
- Wrap garak yourself: Add a stage that installs garak with pip, runs it against your endpoint and archives the output directory.
- Plan the SonarQube path: Export JSON from promptfoo and transform it, unless you adopt Enterprise.
- Confirm agent capacity: Check that your build agents can run Python 3.11 and Node.js 22.22.0 or newer.
Before committing, have your platform team test one failing build in a non-production pipeline to confirm how each tool's exit code and report reach your dashboards.
Questions teams ask before choosing a CI/CD tool
Can garak fail a build on its own?
Not in a way its documentation describes. garak is a command-line scanner that writes a JSONL report of every attempt and a hit log of attempts that found a vulnerability, but its README does not describe CI pipeline integration. A pipeline can still run it and read those outputs, yet your team must write the step that parses the hit log, decides what counts as a failure and returns a non-zero exit code. Confirm that logic with your own test plan before you rely on it as a release gate.
What does JUnit output give a promptfoo pipeline?
JUnit XML lets a CI system show promptfoo results in its native test report viewer, so failed prompts appear next to other test failures. promptfoo can also fail the build on any test failure with --fail-on-error, and it writes JSON and HTML output alongside JUnit. Teams that use SonarQube need to export JSON and transform it, since direct SonarQube output is listed for promptfoo Enterprise. Check which report format your CI platform reads before you design the gate.
What does self-hosting promptfoo leave out?
The self-hosted promptfoo app is an Express server with a web UI and API, deployable with Docker, Docker Compose or Kubernetes with Helm. Its documentation says it stores data in a local SQLite database that cannot be shared across replicas, and it has no RBAC, horizontal scaling, built-in authentication or SSO. The documentation also says it is not recommended for production use. If you need shared access controls or a central dashboard, ask the vendor about Enterprise or On-Premise editions and get their scope in writing.
How much effort does a garak wrapper take to build?
The effort depends on your pipeline, the target and how strict the gate must be. garak installs with pip on Python 3.11 or newer, and its REST generator needs a short YAML file describing your endpoint. The default probewise harness runs each probe with its recommended detectors, and by default it makes 5 generations per prompt. Your team then owns the parsing script, the pass or fail threshold, secrets handling, scheduling and the upkeep of the wrapper as garak releases change. Ask any consultant to list each of those items in the scope.
Are promptfoo and garak free to use?
Both tools are open source. promptfoo is MIT licensed and its Community edition is free, with all LLM evaluation features, all model providers and red teaming with 10k probes per month, plus community support. garak is Apache 2.0 licensed and its maintainers describe it as a free tool. Your recurring costs come from the compute that runs scans, model API usage against your targets, the engineering time to maintain pipelines, and any Enterprise or support contract you choose.
Can our team set this up without outside help?
A team with CI experience and an owner for LLM security can often start with promptfoo's documented GitHub Actions, GitLab or Jenkins setups. A pipeline gate built around garak needs more custom work, and deeper model scans need a schedule, storage for reports and someone who reviews hit logs. Outside help is useful when you need hardened runners, secret management, evidence for an assessment or a written scope with deliverables and timelines agreed before work begins. DeployOpen plans, implements, integrates and documents self-hosted platforms in your own environment, and most engagements are fixed-scope. Ask for a written scope that names each pipeline, target and handover item.
What should we ask a vendor or consultant for in a written scope?
Ask for the exact pipeline steps, the report formats produced and who reads them, the pass or fail rule and who owns it, and the target systems and credentials involved. Request the versions and licenses to be deployed, the hosting location, the backup and upgrade plan and the handover documentation. For promptfoo, confirm which edition you need and whether self-hosting limits matter for your team. For garak, confirm how the hit log is parsed and how scan results are retained. Ask for timelines and deliverables in writing before work starts.
How DeployOpen helps teams put AI test gates into CI
DeployOpen plans, implements, integrates and documents self-hosted open-source platforms inside the client's own infrastructure, including security testing of AI systems. For teams weighing promptfoo against garak as a release gate, we scope the pipeline, the test configuration and the handover in writing before work starts.
How we scope
- Agree in writing which pipeline runs the gate, such as GitHub Actions, GitLab CI or Jenkins
- Define which target models, endpoints and prompts the gate must cover before any build is blocked
- Set the pass, fail and reporting rules, including how JUnit or JSONL output is reviewed
- Confirm whether periodic deeper garak scans are in the written scope or handled separately
How we build
- Write and version promptfoo configs and CI jobs that run inside the client's own runners
- Wire garak runs into scheduled jobs and convert its JSONL and hit log output into reviewable reports
- Test the gate itself with deliberate failures so a broken check cannot pass a release silently
- Keep secrets for model providers in the client's own secret store, not in pipeline definitions
How we hand over
- Document the pipeline configuration, the test inventory and the steps to add or retire a test
- Deliver runbooks for reading failure output and deciding whether a finding blocks a release
- Record which open-source versions were used, so upgrades can be planned and tested deliberately
- Hand over the working setup to the client's engineers with a walkthrough of each job
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Re-run the gate when promptfoo or garak releases change defaults, probes or output formats
- Review new model versions and provider changes against the existing test suite on request
- Ask for a written quote built from the agreed scope, since DeployOpen does not publish a price list
