When promptfoo Community is enough and when Enterprise is needed
If your question is whether the free edition can gate releases, the answer is yes for a single team that runs checks from CI, as long as usage stays within the 10k probes per month that Community includes at no charge. Community includes the full evaluation toolset: all LLM evaluation features, all model providers and integrations, red teaming, custom integration with your own app, vulnerability scanning and community support. The software runs locally, so evals execute on your machine and talk directly with the LLM, and your pipeline can run them on every pull request. Count probes before you commit. A nightly red team run across several targets can use the allowance much faster than a release-only gate, so model your expected volume against the limit and confirm current terms on the promptfoo pricing page.
Enterprise is the right choice when the constraint is people and control rather than test coverage. Choose it if several teams must share results, if access must follow team membership and custom roles through SSO, or if you need continuous monitoring and a centralized security and compliance dashboard. The Enterprise documentation marks team management, RBAC and external integrations as unavailable in Community and result sharing as limited, so a self-hosted Community server is not a substitute for these controls. Its SQLite database cannot be shared across replicas, it has no RBAC or built-in authentication or SSO, and the documentation does not recommend it for production. Before you buy, ask the vendor which tier and deployment model your identity and audit requirements need, and whether probes beyond the allowance can be purchased on your plan.
Which promptfoo features are paid and which are free
This table sets the free promptfoo Community edition against the paid Enterprise tiers, row by row, using the pricing page and the Enterprise documentation. Where the docs mark a feature unavailable or limited in Community, the cell says so, and where a feature appears on neither page, the cell tells you what to confirm with the vendor. The main takeaway: the paid tiers build on the same evaluation and red teaming features, and add team, access control, monitoring and support layers.
| Capability | Community (free) | Enterprise (custom pricing) |
|---|---|---|
| LLM evaluation and model providers | Included, with all LLM evaluation features and all model providers | Included per the pricing page; confirm the full provider list for your contract |
| Red teaming and probe allowance | Included, with 10k red team probes per month at no charge | Included, with custom red teaming limits; additional probes can be purchased |
| Customizable attack profiles | Not listed on the Community pricing page; confirm before relying on it | Included, as listed on the Enterprise pricing page |
| Team sharing and result sharing | Result sharing is limited; team sharing is not listed for Community | Team sharing and collaboration included |
| Team management, RBAC and custom roles | Unavailable, per the Enterprise documentation | Included, with teams-based access control and custom roles and permissions |
| SSO with granular permissions | Unavailable; the free self-hosted server has no built-in SSO | Included, with SSO and granular permissions |
| Continuous monitoring and security dashboard | Not listed for Community | Included, with continuous monitoring and a centralized guardrail dashboard |
| External integrations | Unavailable, per the Enterprise documentation | Included per the Enterprise documentation; confirm the specific integrations you need |
| API access and support | Community support only; no API access listed | promptfoo API access and priority support with SLA guarantees |
How the editions fit different team setups
A single developer or one CI pipeline usually needs the evaluation and red teaming features, not shared administration. Community includes all LLM evaluation features, all model providers and integrations, red teaming, custom integration with your own app, vulnerability scanning and community support, and it runs locally from declarative configs. Its red team allowance is 10k probes per month at no charge, which is the main limit to plan around as the test suite grows.
- Local execution: evals run on your machine and talk directly to the model, so no shared server is needed.
- CI gating: promptfoo can run checks in CI/CD pipelines from the same config file developers use locally.
- Probe budget: count the probes each scheduled run consumes against the 10k monthly allowance before you add more plugins or strategies.
- Results sharing: the Enterprise docs describe result sharing as limited in Community, so a shared report across a team may need a workaround or an upgrade.
- Community support: support is community-based, so plan for your own troubleshooting if a pipeline breaks.
Before relying on Community for a release gate, confirm the current probe allowance and the sharing limits in the promptfoo pricing page and Enterprise documentation.
A platform team that runs promptfoo for several product teams has a different problem: many configs, many owners and one place to see results. Community has no team management or RBAC, and the Enterprise docs mark team management as unavailable in Community. Self-hosted promptfoo stores data in a local SQLite database that cannot be shared across replicas and has no RBAC or horizontal scaling. The Community pattern works for a small number of owners who trust each other, but it strains as ownership grows.
- Shared ownership: Enterprise adds team sharing, teams-based access control and custom roles, which map to product team boundaries.
- Replica limits: the self-hosted server's SQLite store cannot be shared across replicas, so scaling out the web tier does not solve shared state.
- Monitoring across teams: continuous monitoring and a centralized dashboard are Enterprise features, so a platform owner would otherwise assemble status from separate runs.
- Attack profiles: customizable attack profiles are listed as Enterprise, which matters when each product needs its own threat focus.
- Operational cost: running the self-hosted server yourself means you own backups, upgrades and access control.
Ask the vendor which team, role and sharing features apply to your tenancy model and whether the probe allowance can be raised for your volume.
A regulated organization usually needs identity-backed access, a central record of who ran what, and evidence that testing happens before deployment. Community does not include SSO or granular permissions. Enterprise adds SSO with granular permissions, a centralized security and compliance dashboard, a centralized guardrail dashboard and remediation recommendations. promptfoo's red teaming documentation references the OWASP LLM Top 10, the NIST AI Risk Management Framework and the EU AI Act as frameworks that support systematic testing before deployment, so the scans can feed a compliance file, though the scans themselves do not certify compliance.
- Identity: SSO with granular permissions is an Enterprise feature, so Community leaves sign-in and access control to you.
- Dashboards: the compliance dashboard is Enterprise, and Community requires you to build evidence collection yourself.
- Framework mapping: the OWASP, NIST and EU AI Act references support test design, while your auditors decide what counts as evidence.
- Priority support: Enterprise includes priority support with SLA guarantees, which some regulated buyers require in writing.
- Integrations: external integrations are unavailable in Community, so confirm which ticketing or SIEM connections your Enterprise contract includes.
Confirm with the vendor the SLA terms, the SSO protocols supported and what audit logs the platform keeps. Ask your compliance team which evidence it needs before the purchase.
A team that cannot let prompts, model responses or scan results leave its network has a deployment question before a feature question. The promptfoo documentation states that the open-source software runs completely locally, with evals running on your machine and talking directly to the LLM. That covers the CLI workflow. For a shared, multi-user deployment with a central store, the choice is between the self-hosted server, which the docs say is not recommended for production, and an Enterprise option. promptfoo On-Premise runs the Enterprise functionality on your infrastructure with complete data isolation and a dedicated deployment engineer.
- Local CLI: the command-line workflow keeps evaluation traffic between your machine and the model you choose.
- Self-hosted limits: the self-hosted server lacks RBAC, built-in authentication and SSO, and the docs advise against production use.
- On-Premise option: Enterprise On-Prem is the documented path for complete data isolation with Enterprise features.
- Model endpoints: isolation covers the promptfoo side only, so confirm where each target model is hosted and what it logs.
- Deployment engineer: the dedicated engineer is part of the On-Premise offering, so ask what it covers during installation.
Confirm with promptfoo where scan data is stored, what telemetry leaves the network and how On-Premise is priced and installed, because those answers decide whether isolation holds in your environment.
What the free self-hosted server lacks for production
The self-hosted promptfoo app is an Express server that serves the web UI and API, and it can be deployed with Docker, Docker Compose or Kubernetes with Helm. That makes it easy to stand up, but the promptfoo documentation says it stores data in a local SQLite database that cannot be shared across replicas, has no RBAC, no horizontal scaling, no built-in authentication or SSO, and is not recommended for production use. Treat it as a single-instance tool for one team's evaluation work, not as a shared service.
For a team that wants shared dashboards, the practical consequence is that results live in one local database on one instance. You cannot run two replicas behind a load balancer against the same data, and anyone who can reach the server has no role-based limits to rely on. Before you deploy, confirm with promptfoo which of these gaps your use case can tolerate, for example whether a single pod with a persistent volume and network-level access control meets your internal policy, and write that decision down.
If you need multi-user access, role-based permissions and SSO, the paid path is promptfoo Enterprise, and the On-Premise option runs that Enterprise functionality on your own infrastructure with complete data isolation and a dedicated deployment engineer. It is a separate commercial product, so ask promptfoo for its scope, deployment model and pricing in writing. Also ask whether it can run in the network segment where your red team data must stay, and how the dedicated engineer's involvement is defined in the agreement.
License, support and update terms for each promptfoo edition
The open-source CLI, the free Community edition and the paid tiers each carry different license, support and ownership terms. The cards below separate what is published and licensed from what is priced per contract, so you know which terms to read in writing before committing.
MIT license for the open-source CLI
The promptfoo CLI and library are licensed under the MIT license, so your team can run, modify and redistribute the open-source code under those terms. Version 0.124.1 was published on October 8, 2026, and it requires Node.js 22.22.0 or newer. Check that your build images and CI runners meet that Node.js floor before you pin a version, and confirm which release your security team has reviewed.
Community support and free terms
The Community edition is free and includes all LLM evaluation features, all model providers, red teaming with 10k probes per month and community support. Community support is not a contracted response commitment. If a scanner finding blocks a release, your team resolves it through its own engineers or the public community, so plan that ownership before you rely on the free tier for a gated pipeline.
Enterprise priority support and SLAs
Enterprise adds priority support with SLA guarantees, and pricing is custom. Ask for the SLA document itself and read the response targets, severity definitions, service credits and how they apply to self-hosted deployments. Confirm whether support covers the self-hosted server or only the vendor-run service, because those two setups can carry different responsibilities.
On-Premise deployment engineer terms
On-Premise runs the Enterprise functionality on your own infrastructure with complete data isolation and a dedicated deployment engineer. Clarify in writing what that engineer does, whether that work is one-time setup or recurring, how upgrades reach your environment, and who patches the underlying host and database. Those answers decide your internal staffing load more than the license does.
OpenAI ownership and open-source pledge
Promptfoo announced on March 9, 2026 that it had agreed to be acquired by OpenAI. The founders state that promptfoo will remain open source and keep supporting a diverse range of providers and models, and the README says the project remains MIT licensed. Treat this as a stated commitment, not a contract. Ask for any change-of-control, data handling or provider-neutrality terms in writing if they matter to your procurement.
Update cadence and SLA terms to confirm
Neither the public pricing page nor the supplied sources state a release cadence, an upgrade window or SLA response times for Enterprise. Ask the vendor for its release policy, how long older versions receive security fixes, the upgrade path for self-hosted installs and the exact SLA language. Get those terms in the order form so your compliance file reflects what you actually bought.
What each promptfoo edition costs and what drives the bill
This table separates what each promptfoo edition charges for from the costs that sit with your own team and infrastructure, and marks which items are one-time and which recur. Read it as a checklist: the subscription line is only one part of the total, and the rows on staff time, CI runner use and model API spend apply to both editions.
| Cost component | Who is paid | One-time or recurring | What drives it |
|---|---|---|---|
| Community edition licence | Nobody. Community is free forever per the promptfoo pricing page | Not applicable | Free edition includes evaluations, all model providers, red teaming with 10k probes per month and community support |
| Enterprise subscription | promptfoo, at custom pricing per the promptfoo pricing page | Recurring | Seats or teams, custom red teaming limits, SSO, continuous monitoring and priority support with SLAs. Ask for the price basis in writing |
| Additional red team probes | promptfoo, for Enterprise customers who buy extra probes | Recurring, if your scan volume exceeds the included allowance | Number of probes your scheduled and release scans generate. Ask how overage is billed and whether unused probes roll over |
| On-Premise deployment | promptfoo, for the Enterprise functionality plus a dedicated deployment engineer, per the pricing page | Mostly one-time setup, with recurring support terms | Infrastructure footprint, network isolation requirements and deployment engineer time. Ask what is included in setup and what is ongoing |
| Your staff time to operate | Your own engineers or a services partner such as DeployOpen, under a written scope | One-time for setup, recurring for upkeep | Self-hosted Community runs on SQLite with no RBAC or SSO, so you carry access control, backups and upgrades yourselves |
| CI runner minutes | Your CI provider (for example GitHub Actions, GitLab or Jenkins) | Recurring, per pipeline run | How often evaluations and red team scans run on each pull request versus on a schedule. Scope scans to changed components to limit cost |
| Model API spend | Your model providers, billed for the calls promptfoo makes | Recurring, per test run | Number of test cases, models under test and attacker or grader models used. Promptfoo runs locally and talks directly to your LLM, so this bill is yours in both editions |
Moving from Community to Enterprise without losing evaluation work
This sequence keeps your evaluation work in files your team controls while you add a shared instance, access controls and CI gates. The end state is a team workspace where the same configs produce the same results before and after the move.
Keep eval configs in version control
Platform engineering or the team that owns the LLM application moves every promptfoo config, test file and red team setting into the application repository, so the declarative configs become the shared source of truth. promptfoo runs from these configs locally, which makes them portable across machines and environments. The step is complete when a fresh clone of the repository runs the eval from the CLI and produces the same results as the original local run. Each change to a config should then go through a pull request review.
Record a Community baseline
Before any infrastructure changes, the team runs the full eval and red team suite on the Community edition and saves the outputs, including pass and fail counts per test. This baseline shows which tests fail today and gives a reference point for later comparisons. Track how many red team probes each monthly run consumes against the 10k monthly allowance on Community, so you know whether the Enterprise plan's custom limits are needed. The step is done when the baseline outputs are committed alongside the configs.
Stand up a shared instance
The platform team chooses where the shared instance runs: the vendor-hosted Enterprise service, On-Premise Enterprise in your own infrastructure, or the self-hosted promptfoo app deployed with Docker, Docker Compose or Helm. The self-hosted app stores data in a local SQLite database that cannot be shared across replicas, and it has no RBAC, built-in authentication or SSO, so the documentation does not recommend it for production. Confirm with the vendor which deployment fits your data isolation and scaling needs. The step is complete when a test run from a team member's machine appears in the shared instance.
Plan SSO and RBAC before onboarding
The security team and the platform team map existing identity groups to promptfoo teams, custom roles and permissions before any user logs in. Enterprise adds teams-based access control, SSO and granular permissions that the Community edition does not include. Ask the vendor which identity providers and SSO protocols the Enterprise tier supports, how group membership syncs, and who can grant admin rights. The step is done when a written role matrix is approved and a pilot group can sign in through SSO with only the permissions assigned to its role.
Migrate result history if required
The team decides whether historical eval results must move into the shared instance or can stay as archived files. Export the baseline outputs from the Community runs and keep them in the repository with dated folder names, which preserves the evidence regardless of platform. Ask the vendor whether the Enterprise tier offers an import path for prior results and what format it accepts, because this is not covered in the supplied materials. The step is done when each historical result set is either imported and spot-checked or archived in a readable format.
Repoint CI jobs to the shared instance
The DevOps or pipeline team updates the CI configuration so jobs in GitHub Actions, GitLab or Jenkins call the shared instance, and confirms the runner uses Node.js 22.22.0 or newer, which the current CLI requires. Keep the existing failure behavior and any JUnit output in place so gate semantics do not change silently. Validate the gate by running one pipeline with a deliberately failing test and one with a passing test. The step is complete when the failing run blocks the release and the passing run completes as expected.
Document the downgrade path
Before going live, the team writes down what happens if the organization later returns to Community or drops the Enterprise plan. Configs, local runs and archived results stay in the repository because they never depended on the platform. Team sharing, centralized dashboards, continuous monitoring history and SSO-linked access live in the shared instance and may not carry over, so ask the vendor what data can be exported, in which format, and how long access to the instance continues after a plan change. The step is complete when the answers are recorded in the runbook and reviewed by the security owner.
What buyers ask before paying for promptfoo Enterprise
Is promptfoo Community enough for CI gating?
For many teams, yes. Community includes evaluation features, all model providers and integrations, and red teaming, and promptfoo can run checks in CI/CD pipelines from declarative configs. The limits are the 10k red team probes per month allowance, community-only support, and the fact that result sharing is limited in Community. If your gate only needs to pass or fail a build and stay under the probe allowance, Community may cover it. If several teams need shared results, a central view, or a probe budget above 10k per month, price Enterprise. Confirm your monthly probe count from your pipeline runs before deciding.
What does promptfoo Enterprise cost?
promptfoo lists Enterprise at custom pricing, so there is no public figure to compare. The quote follows from the written scope: the number of seats or teams, the probe volume you need beyond the Community allowance, whether you want the vendor-run SaaS or On-Premise deployment, and the support level. Ask the vendor which of these are recurring subscription fees and which are one-time, what additional probe purchases cost, and whether SSO and continuous monitoring are priced together. DeployOpen does not publish prices and does not estimate promptfoo licensing costs.
How much effort does a self-hosted promptfoo rollout need?
The self-hosted app is an Express server with a web UI and API, deployable with Docker, Docker Compose or Kubernetes with Helm. Effort depends on the target platform, the network path to your LLM providers, how you handle secrets and TLS, and whether you need backups and upgrades on a schedule. The documentation also says the default store is a local SQLite database that cannot be shared across replicas and is not recommended for production. Running it well therefore means planning storage, access control in front of the app, and an upgrade routine. Ask for a written scope that lists each of these items.
How long does migrating from Community to Enterprise take?
No migration duration is published by promptfoo, so confirm the timeline with the vendor before planning. Migration effort usually depends on how many eval configs, red team suites and CI pipelines you already run, how much history you need to keep, and how many users must move to team sharing and SSO. Ask the vendor what moves automatically, what needs manual reconfiguration, and what the cutover steps look like. If DeployOpen is engaged, the timeline comes from the fixed scope agreed in writing before work starts.
Can our team run promptfoo ourselves without outside help?
Often yes for Community, since it runs locally from declarative configs and fits into existing pipelines. A team with Node.js experience and someone who owns CI can usually start with the CLI. Self-hosting for shared use, or running Enterprise On-Prem, adds infrastructure, identity and operations work that many teams do not have spare capacity for. Assess your skills across Node.js, container platforms, identity integration and security testing. DeployOpen can plan, implement, harden, back up, upgrade and document a self-hosted deployment under a fixed-scope agreement, or support it through a retainer.
What does our side need to provide for a promptfoo deployment?
Start with the runtime: promptfoo 0.124.1 requires Node.js 22.22.0 or newer. For Enterprise, you will need an SSO provider that supports the integration you plan to use, and a list of teams and roles to map to promptfoo permissions. Decide data residency early: Community evals run on your machine and talk directly with the LLM, but a shared self-hosted or On-Premise server stores results in your environment, so confirm where those results, prompts and logs live. Name an owner for CI secrets, probe budgets and upgrades.
What happens to the MIT-licensed promptfoo code under OpenAI ownership?
OpenAI agreed to acquire promptfoo, announced on March 9, 2026, and the promptfoo README states that it is part of OpenAI and remains open source and MIT licensed. The founders state it will remain open source and continue to support a diverse range of providers and models. The MIT license lets you keep using, modifying and self-hosting the released code. What is not guaranteed is the commercial roadmap, pricing or which Enterprise features stay paid. Review the license text, pin versions in your pipeline, and confirm roadmap and data terms with the vendor in writing.
How DeployOpen scopes promptfoo edition work
DeployOpen plans, implements and integrates self-hosted platforms inside the client's own cloud accounts, data centers or air-gapped networks, and it runs security testing alongside that work. If your team is weighing promptfoo Community against Enterprise, the practical question is which of the scope items below you need written down before any work starts: how the free CLI or self-hosted server fits your pipelines, whether you need team sharing, RBAC, SSO or continuous monitoring, and whether you want an on-premises Enterprise deployment. Those decisions change the deliverables, so they belong in the scope document, not in a later change request.
Most DeployOpen engagements are fixed-scope, which means the scope, deliverables and timelines are agreed in writing before work begins. For promptfoo, a useful written scope names the specific components (for example, the GitHub Actions or GitLab jobs that run red team checks, the promptfooconfig.yaml files, the authentication model for any shared web UI, and the handover of configs and reports). Ongoing support, upgrades and continuous testing are available as retainers and should be listed as separate line items so you can see what recurs. Ask for the exact Node.js and runtime versions the work will target, and confirm them against the promptfoo release notes before quoting.
DeployOpen does not publish a price list. A quote follows from the written scope, so the most useful thing you can bring to the first call is a list of your pipelines, your number of users who need shared results, your access and identity requirements, and where the data must stay. DeployOpen is a Chainscore Labs company, and it is not an official partner, reseller or certified provider of promptfoo or OpenAI. Any licensing for promptfoo Enterprise or On-Prem is quoted and contracted directly by the vendor, and you should confirm those terms with promptfoo before finalizing your scope.
How DeployOpen delivers and supports either promptfoo edition
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so the same method applies whether you stay on promptfoo Community or buy Enterprise. The work starts with a written scope that states which edition, which environment and which evidence your team needs.
How we scope
- Confirm which promptfoo edition fits the team, the release gate and the audit evidence required
- Agree the written scope, deliverables and timeline before any work starts, since most engagements are fixed-scope
- Define which red team plugins, frameworks and CI pipelines are in scope, and where scans will run
How we build
- Configure promptfoo runs locally or in CI/CD pipelines, with declarative configs kept under version control
- For Enterprise or self-hosted deployments, set up SSO, roles and the chosen Docker, Compose or Helm footprint
- Test the red team configuration against your own application and document the results before handover
How we hand over
- Deliver written runbooks covering configuration, edition limits such as the 10k monthly probe allowance, and upgrade steps
- Document access controls, data storage and backup decisions so your operators can run the setup without us
- Walk your engineers through the pipeline gate, report review and how findings move into your remediation process
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Ask any quote to itemize implementation, licensing you buy directly from promptfoo, and recurring retainer work
- Confirm with promptfoo which Enterprise features, SLAs and additional probe purchases apply to your contract
