promptfoo vs garak: which to choose

promptfoo vs garak: when to choose each for your release pipeline

Choose promptfoo when your release gate needs application-level evals and red teaming, covering the prompts, the tools the model calls and the business logic around it, defined in declarative configs and run in CI/CD. Choose garak when the question is about the model endpoint itself: whether it can be pushed into hallucination, data leakage, prompt injection, toxicity or jailbreaks, using probes and detectors the scanner runs for you. The decision turns on three questions. First, does your gate test prompts, tools and business rules, or the underlying model's behavior? Second, do several teams need a shared UI to review results? Third, who owns the tool? Promptfoo announced on March 9, 2026 that it had agreed to be acquired by OpenAI. The two tools are not mutually exclusive.

The shared review question is where the two differ in practice. garak writes a JSONL report of every attempt plus a hit log of attempts that found a vulnerability, which suits engineers who read run artifacts in the pipeline. promptfoo runs locally and can be self-hosted, but the self-hosted app stores data in a local SQLite database that cannot be shared across replicas, has no RBAC, horizontal scaling, built-in authentication or SSO, and is not recommended for production use. If several teams need shared history and access control, ask whether promptfoo Enterprise or On-Premise covers that need. Those editions add SSO, teams-based access control and custom roles, and their pricing is set by quote, so confirm the terms in writing.

Which scenarios favor promptfoo and which favor garak

This table maps common AI security scenarios to the tool that usually fits better, with the condition that decides it. Read each row as a starting point: the condition column tells you what to verify in your own environment before you commit.

Scenario	Better fit	Condition that drives the choice
Gating prompt or RAG changes in CI	promptfoo	Choose it when the team wants declarative configs in the repository that run on each pull request against the application's own prompts, retrieval context and expected outputs. garak fits CI less naturally because its probe runs target a model rather than your application logic.
Scanning a model endpoint before adoption	garak	Choose it when the question is how a specific hosted or self-hosted model behaves under known attack families. garak's probes and detectors, run from the command line against Hugging Face, OpenAI, AWS Bedrock, llama.cpp or a REST endpoint, are built for this comparison.
Air-gapped or internal REST endpoints	garak (confirm for your setup)	garak's REST generator connects to any endpoint that returns plaintext or JSON, configured with a short YAML file. Confirm that your application's auth, network path and any promptfoo provider you plan to use all work without outbound calls before choosing promptfoo.
Teams needing a shared team dashboard	Depends on edition and hosting	promptfoo Enterprise and On-Premise add team sharing, access control, SSO and a guardrail dashboard, on custom pricing. The self-hosted app is not recommended for production and has no SSO or RBAC, so confirm the edition you need. garak writes local JSONL reports and a hit log, so a shared view must be built by your team.
One-off assessments of a model or application	garak for a model, promptfoo for an app	A one-time model check favors garak's default probewise run and its reports. A one-time check of a specific chatbot's behavior and policies favors promptfoo, which runs locally from a config file and needs no shared infrastructure.
Mapping results to OWASP LLM Top 10 or NIST AI RMF	promptfoo	promptfoo's red teaming documentation references the OWASP LLM Top 10, the NIST AI Risk Management Framework and the EU AI Act. Confirm with the promptfoo documentation which framework tags your report needs, because mapping coverage may differ from what an assessor expects.
Teams that prefer Apache-2.0 licensing and NVIDIA maintenance	garak	garak is Apache-2.0 licensed and maintained in NVIDIA's GitHub organization. promptfoo is MIT licensed and now part of OpenAI, so teams with vendor-ownership concerns should weigh that ownership against the commitment to remain open source.
Testing across many model providers in one suite	promptfoo	Choose it when one config needs to compare outputs from several providers side by side during evaluation. Confirm the provider list for your models, since coverage changes between releases.

How promptfoo and garak are built and deployed

garak and promptfoo take very different shapes: one is a scanner you install and point at a model, the other is a config-driven tool that can also run as a shared web service. The cards below cover what each one is made of, where it runs, and what the self-hosted app does and does not provide before you put it in front of a release team.

garak is a probe-driven CLI

garak is built from five plugin types: probes that generate attacks, detectors that judge whether the model failed, evaluators, generators that connect to targets, and harnesses that run them. The default probewise harness runs each probe with its recommended detectors. Installation is through PyPI with pip, and the package requires Python 3.11 or newer. Check that your build agents meet that Python floor before you add it to a pipeline, and confirm which generator your target needs.

promptfoo runs as a local tool

promptfoo runs as a CLI, a library, or a step in CI/CD pipelines, and its documentation states that evals run on your machine and talk directly with the LLM. Tests are declared in config files, so the same definitions can run on a developer laptop and in a build job. This suits teams that want test definitions stored in the application repository. Confirm that your CI runners can reach the model provider and that secrets for provider keys are injected at run time, not committed.

Self-hosted promptfoo app

The self-hosted promptfoo app is an Express server that serves the web UI and API. It can be deployed with Docker, Docker Compose or Kubernetes with Helm. This gives a shared dashboard for results, but it is a separate service you must run, patch and place behind your own network controls. Ask your team whether it will be the shared results store or whether results will stay in the CI system.

SQLite storage limits the app

The self-hosted app stores data in a local SQLite database that cannot be shared across replicas. That rules out running more than one instance behind a load balancer against shared state, and it makes backup and restore a file-level task tied to one host. Plan for a single instance with tested backups, and treat the database file as sensitive because it holds test results and prompts. Confirm with the vendor whether a supported external database is on the roadmap before you assume one.

No RBAC or built-in authentication

The self-hosted app has no role-based access control, no built-in authentication and no SSO. Anyone who can reach the web interface can view and change results in that instance. For production, place the app behind an authenticating reverse proxy or private network, and restrict who can reach it. Enterprise and On-Premise editions add SSO and teams-based access control, so compare those against your identity requirements before you choose a path.

Production implications for the app

Taken together, the SQLite store, missing RBAC and missing authentication mean the open-source self-hosted app is not recommended for production use by its own documentation. A production setup needs an access layer, a backup routine, patch ownership and a clear owner for the results. garak has none of these concerns because it writes JSONL and log files to the local run directory, so its operating burden sits in the pipeline and the storage you choose for reports.

Side-by-side capability comparison for red teaming and CI

promptfoo is built to test an LLM application. Its configuration describes the prompts, providers, test cases and assertions that make up your product's behavior, so the evaluation reflects the system your users reach, including the prompt template and the way it calls the model. garak is built to scan a model. It sends probes to a target through a generator and judges the responses, which makes it well suited to comparing model endpoints or checking a base model before you build on it.

Application behavior: promptfoo evaluates prompts and outputs defined in a declarative config, so tests track your application's prompts and assertions across releases.
Model behavior: garak runs probes against a target model and reports how the model itself responded, independent of your prompt wrapper.
Local execution: promptfoo's documentation states that evals run on your machine and talk directly with the LLM.
Scope of a single run: a promptfoo test covers the workflows you encode; a garak run covers the probes you select.

Confirm with each vendor whether a single pipeline can run both an application-level eval and a model scan against the same endpoint without duplicating credentials or configuration.

What drives the running cost of each tool

This table lists who gets paid for what when running promptfoo or garak, and whether each cost is one-time or recurring. Use it to build the question list for a quote before you compare totals. The main takeaway is that both tools are free to license at the community level, so most of the spend sits in engineer time, model API calls and, for promptfoo, the self-hosted app and any Enterprise tier.

Cost component	What it covers for promptfoo	What it covers for garak
Engineer time to set up	Writing declarative configs, provider settings and red team plugin choices, then wiring checks into CI/CD. Recurs as the app changes.	Installing from PyPI, choosing probes and detectors, and writing a YAML file for any REST endpoint. Mostly one-time per target, then updated as targets change.
Model and API spend during runs	Each eval and red team run calls the model under test directly, so token charges recur with every pipeline run and grow with probe count.	Each probe generates attempts against the target, and the default of 5 generations per prompt multiplies calls. Charges recur per scan and depend on the generator you choose.
Hosting the self-hosted app	Compute, storage and networking for the Express server, which can run on Docker, Docker Compose or Kubernetes with Helm. Recurs for as long as it runs.	No server component is needed for a basic run. Local storage holds JSONL reports and the garak.log file, which grow with each run.
Storage and data retention	Self-hosted data sits in a local SQLite database that cannot be shared across replicas, so production use may need a different data layer that you must plan and pay for.	JSONL reports and logs accumulate on disk. Retention policy and archive storage are your cost to set.
Enterprise licensing tier	Team sharing, SSO, RBAC, continuous monitoring and on-premise deployment are sold at custom pricing. One-time negotiation, then recurring subscription.	Not applicable. garak is described by its maintainers as a free tool, so no license fee applies.
Upgrades and version pinning	Frequent releases mean regular Node.js and package upgrades, and config changes when plugins evolve. Recurs with each release cycle.	Frequent releases mean updating the Python package and re-running probes after changes to detectors. Recurs, with lower surface area for a CLI-only setup.
Support options	Community support on the Community edition. Priority support with SLAs and a dedicated deployment engineer apply only on Enterprise or On-Premise plans.	Community support through the project and documentation at docs.garak.ai. Any paid support or retainer comes from a third party, such as DeployOpen, under a written scope.

Moving test suites between promptfoo and garak

This sequence shows a team how to carry its LLM test coverage from promptfoo to garak, or the reverse, without losing track of which attack categories were covered and without breaking the release gate during the switch. The end state is one pipeline where both tools run side by side until the old path is safe to remove.

Inventory every existing test and its consumer
The team lists each promptfoo config, red team plugin set, assertion and CI job, then records who reads its output: a release approver, a dashboard, a ticket queue or an auditor's evidence folder. The engineer who owns the pipeline does this with the security lead, since the report consumers are often the hidden dependency. The step is done when every test has a row naming its target endpoint, its pass criteria and its consumer.
Map attack categories to garak probes
Each promptfoo red team category is matched to the garak probe family that tests the same concept, such as prompt injection, data leakage, jailbreaks, toxicity or misinformation. Categories without a clear match are flagged, because some app-level checks, such as tool misuse or business logic, have no direct model-scan equivalent and must stay in promptfoo. The output is a mapping table with three columns: covered, partially covered and not covered, reviewed by the security lead. Confirm current probe names against the garak user guide rather than relying on older documentation.
Rebuild endpoint definitions for garak
The promptfoo provider settings are translated into garak generator configuration, either a named generator for a supported provider or a REST generator YAML file for a custom endpoint. The engineer runs one probe against a staging target and confirms that responses are parsed correctly and that the JSONL report records each attempt. Credentials move to the CI secret store, not into the YAML file. The step closes when a single garak run completes against the same endpoint the promptfoo suite uses.
Rewrite the CI gate with explicit pass rules
The team rewrites the pipeline job so that promptfoo and garak each have a named step, with their own exit conditions. promptfoo's pass or fail results are a different shape from garak's probe-level FAIL status with a failure rate, so the gate needs a written rule for what blocks a release. A converter or a short script reads the garak report and produces the summary the approver expects. Done means a deliberately vulnerable test build fails the gate in both paths.
Update report consumers and evidence
Dashboards, ticket integrations and compliance evidence folders are updated to accept the new output format. The team checks whether an existing report template or auditor request depends on the promptfoo format, and whether the garak JSONL report and garak.log need retention rules. The security lead confirms the evidence set with the people who use it. Done when each consumer reads the new output correctly from a test run.
Run both paths in parallel and compare findings
For a period agreed in advance by the team, both pipelines run on every change and their findings are compared. Differences are sorted into three groups: a gap in garak coverage that promptfoo catches, a gap in promptfoo coverage that garak catches, and noise from configuration differences such as sampling. The test owner records each group and assigns an owner to close gaps. The parallel run is complete when the open gap list is either empty or accepted in writing by the security lead.
Retire the old path with a recorded decision
Once the parallel run shows the new gate covers the agreed categories, the team disables the old job and archives its configs, reports and run history. The decision, the coverage mapping and any accepted gaps are recorded in the repository so future reviewers can see why the change was made. The step is done when the old job is removed from the pipeline, the archive is confirmed readable, and the approver signs off on the new gate.

What implementing each tool involves and where projects run long

Implementing promptfoo is mostly configuration work, and the cost of getting it wrong sits in the deployment choice. A team writes a declarative config that names the providers under test, the prompts, the assertions and the red team plugins and strategies, then wires it into a pipeline step. Provider wiring is where most first-week effort goes: each model endpoint needs credentials handled through the pipeline's secret store, and the team should confirm which providers its chosen models are reached through. The harder decision is where the results live. The software runs locally and talks directly to the model, which suits a CI job. A shared, multi-team view is a different deployment. Self-hosted promptfoo stores data in a local SQLite database that cannot be shared across replicas, has no RBAC, horizontal scaling, built-in authentication or SSO, and is not recommended for production use, so identity requirements push the team toward the Enterprise or On-Premise editions. Ask the vendor to confirm the identity integration, role model and support terms in writing before the design is locked, since those features are priced as custom quotes.

Implementing garak is mostly test selection and triage. The team chooses probes that match its risks, confirms which detectors the default probewise harness will run, and writes a short YAML file if the application sits behind a custom REST endpoint, since the REST generator reads a plaintext or JSON response described by that file. Most of the effort then moves to reading the output. Each run writes a JSONL report of every attempt and a hit log of failures, and with the default of 5 generations per prompt a single failing attempt marks a probe as FAIL. Someone must own the triage: decide whether a hit is a real product defect, a detector false positive or a model behavior the application already mitigates, and assign a fix. Without that owner, hit logs accumulate unread.

Projects usually run long for three reasons that apply to either tool. The first is unclear ownership of findings: security, the platform team and the application team each assume another owner handles remediation. Settle this before the first run, and name who closes each finding. The second is identity and access integration on self-hosted promptfoo, which is often discovered late when the team needs per-user access. The third is cost and throughput of model calls. Both tools make many requests, so rate limits on the target provider, the number of prompts and generations, and the choice of judge model all change the bill and the runtime. Ask for an estimate of model calls per run from whoever quotes the work, and confirm provider rate limits with the vendor. Either tool can be run by the team's own staff, but a team without a named owner for triage and identity will find that the schedule, not the tooling, sets the pace.

Questions buyers ask before choosing between promptfoo and garak

Does OpenAI owning promptfoo change its license or open-source status?

No license change appears in the supplied facts. promptfoo is MIT licensed, and its README states that Promptfoo is part of OpenAI and remains open source and MIT licensed. OpenAI's acquisition was announced on March 9, 2026, and the founders state that promptfoo will remain open source and keep supporting a diverse range of providers and models. Read that as a public commitment that you can check over time. Review the repository license file and release notes at each upgrade, and confirm with counsel how the MIT terms apply to your use. garak is Apache-2.0 licensed and maintained in NVIDIA's GitHub organization, so its ownership question is different and should be checked on its own terms.

Can garak gate a release pipeline the way promptfoo does?

garak can produce results that a pipeline can act on, but the supplied facts do not confirm a built-in pass or fail exit code, so test that before you rely on it. Each run writes a JSONL report of every attempt and its evaluation, and a hit log of attempts that found a vulnerability. The default probewise harness marks a probe FAIL with a failure rate when any attempt produces undesirable output. A pipeline step can read those files and fail a build above a threshold you set. promptfoo documents running checks in CI/CD pipelines from declarative configs, so its gating path is more direct out of the box. Expect your team to own the threshold logic and the report handling for garak, and run a sample job in a staging pipeline before you write the gate.

What does self-hosted promptfoo need before it runs in production?

The self-hosted app needs more than a container to be production-ready. Its documentation says it stores data in a local SQLite database that cannot be shared across replicas, and it lists no RBAC, horizontal scaling, built-in authentication or SSO. The docs also state it is not recommended for production use. In practice, you need to decide how to handle these gaps:

Keep a single instance with a tested backup of the SQLite data, or accept that the service has limited availability.
Place access control in front of the web UI and API using your own identity layer.
Run evals from the CLI in CI, which runs locally and talks directly to the model, so the server is not on the critical path.

If you need team access control, SSO and centralized monitoring, the Enterprise and On-Premise tiers add those features. Confirm in writing exactly what each tier provides in your environment.

How long does a first setup take, and what drives it?

No setup duration is supplied for either tool, so ask for a written estimate tied to a defined scope rather than relying on a general figure. The main drivers are the number of model providers and endpoints under test, whether tests run only in CI or also on workstations, and whether you need the promptfoo web server at all. Data handling approvals for sending prompts to third-party APIs often take the longest. Runtime requirements also matter: promptfoo 0.124.1 requires Node.js 22.22.0 or newer, and the garak PyPI package requires Python 3.11 or newer. For garak, the default of 5 generations per prompt means more model calls per probe, which affects run time and cost. DeployOpen's engagements are usually fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

Which cost components should I ask for in a quote?

Ask for each component separately, because the two tools have different cost shapes. Software licensing is free for the open-source cores: garak is free, and promptfoo Community is free with red teaming up to 10k probes per month. Enterprise and On-Premise are custom-priced, so request their terms in writing if you need SSO, RBAC or a dedicated deployment engineer. Model provider usage is billed by your provider and grows with probe volume and generations per prompt. Infrastructure to host the self-hosted app and its storage recurs. Implementation work is a one-time cost, quoted from the written scope, and DeployOpen does not publish a price list. Ask for the one-time and recurring split, what is excluded, the probe volume assumed, and how upgrades and retainers are priced.

Do I need an outside partner to run these tools?

Not necessarily. Both tools are open source and run from the command line on infrastructure you control. A partner becomes useful when you must run self-hosted promptfoo for several teams with SSO and access control, when CI and identity integrations need careful design, when you want test plans mapped to frameworks such as the OWASP LLM Top 10 or the NIST AI RMF, or when your staff cannot absorb upgrades and maintenance. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms inside client infrastructure. It also runs AI and agent security testing and prepares evidence for compliance assessments. It does not issue audit reports or certifications, which come from independent auditors and certification bodies. Get the included deliverables and exclusions in the written scope before you decide.

How the two tools answer different release questions

promptfoo tests whether your application behaves as intended, and garak tests whether the underlying model can be pushed into failure. promptfoo evaluates the system you ship: the system prompt, tool calls, retrieval context, output format and business rules, all driven by declarative configs that run locally against the provider you choose. garak sends probes at a model or endpoint and asks whether it produced undesirable output such as prompt injection success, jailbreaks, data leakage, toxicity or hallucination. Both answer security-relevant questions, but they answer different ones, so a release decision should name which question each result is meant to settle.

*Illustrative example:* a support assistant that can look up orders. A promptfoo assertion might confirm it refuses to reveal another customer's order when asked directly, and that it calls the lookup tool with the correct ID. A garak run against the same model endpoint might show that a jailbreak probe still gets past the base model's safety behavior. The first result is about your retrieval and tool wiring, the second is about the model's baseline. Either can fail while the other passes, which is why a single green run does not prove the release is safe.

A mature pipeline usually runs both. promptfoo output gives you pass and fail results per test case, red team findings mapped to frameworks such as the OWASP LLM Top 10, and a config file that your team can version and review. garak output gives you a JSONL report of every attempt and its evaluation, plus a hit log of attempts that found a vulnerability, which is useful evidence of baseline model behavior for a given version. Ask your team to confirm which artifacts each tool's output will feed into your change record and retention process before you decide which gate blocks a release.

How DeployOpen helps choose, implement and run AI red teaming

DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and runs security testing of AI systems. For promptfoo vs garak, we start from your release pipeline and the question you need answered, then decide which tool or combination fits and how it runs in your environment.

How we scope

Map which parts of your LLM application are tested at the model level and which at the application level.
Confirm the model endpoints, providers and CI systems the written scope must cover.
Agree in writing which findings formats and report outputs the security and compliance teams need.

How we build

Install and configure the chosen tools in your own cloud accounts, data centers or air-gapped network.
Write promptfoo configs or garak probe and generator settings tied to your OWASP LLM Top 10 scope.
Wire test runs into your pipeline with defined pass and fail thresholds agreed with your release owners.

How we hand over

Deliver the written configuration, run procedures and the JSONL or hit-log reporting setup for your team.
Document how findings are triaged, retested and recorded as evidence for your assessments.
Walk your engineers through rerunning the suite after a model, prompt or provider change.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover.
Review tool version changes, such as new garak or promptfoo releases, before they reach your pipeline.
Keep the scope and deliverables in writing so any change to the testing program is agreed first.

promptfoo vs garak

promptfoo vs garak: when to choose each for your release pipeline

Which scenarios favor promptfoo and which favor garak

How promptfoo and garak are built and deployed

garak is a probe-driven CLI

promptfoo runs as a local tool

Self-hosted promptfoo app

SQLite storage limits the app

No RBAC or built-in authentication

Production implications for the app

Side-by-side capability comparison for red teaming and CI

What drives the running cost of each tool

Moving test suites between promptfoo and garak

Inventory every existing test and its consumer

Map attack categories to garak probes

Rebuild endpoint definitions for garak

Rewrite the CI gate with explicit pass rules

Update report consumers and evidence

Run both paths in parallel and compare findings

Retire the old path with a recorded decision