How promptfoo SSO and access control work on a shared instance
A team that wants one shared promptfoo instance for evals and red team results should know first that the self-hosted app has no built-in authentication, RBAC or SSO. Identity has to be added around the application, or it has to come from promptfoo Enterprise, where SSO and teams-based access control are listed as features. promptfoo On-Premise runs that Enterprise functionality on the customer's own infrastructure, so the choice is less about whether identity exists and more about who operates it and where it runs.
This is harder than it looks because the open-source server gives you no login gate to configure. Anyone who can reach the web UI and API can read eval results, prompts and red team outputs, and can run evals that spend provider API keys. The self-hosted data store compounds the problem. promptfoo's self-hosting documentation describes a local SQLite database that cannot be shared across replicas and is not recommended for production use. That means a load-balanced, multi-replica deployment behind a company login proxy will not work on the default storage, and you cannot put several replicas in front of one shared dataset without changing the storage layer.
Before any design work, confirm three things with promptfoo in writing. First, where login happens: at the Enterprise application, at a reverse proxy or gateway in front of a self-hosted instance, or in another layer your platform team controls. Second, which identity providers and protocols are supported for SSO in your deployment model. Third, how identity groups from your directory map to promptfoo teams and custom roles, and whether that mapping can be managed through your provisioning process rather than by hand. Do not assume these answers from the marketing pages. Ask for them against your specific deployment target, whether that is Docker, Docker Compose or Kubernetes with Helm.
Define the access model before you build the login path. A useful starting point is to list the groups that need to see results (for example, evaluators, red team reviewers, release approvers and read-only auditors), the projects or eval suites each group should reach, and who may change provider configurations that hold API keys. Map each group to a role, then test that a user in one team cannot read another team's suites through the UI, the API or exported files. Record each test result as evidence, because access control on a shared instance is only as credible as the checks behind it.
Plan for the parts identity does not cover. A proxy or SSO layer controls who reaches the application, but it does not protect the SQLite file on disk, the backups that contain eval outputs, or the API keys stored in provider configuration. It also does not stop an authorized user from exporting sensitive red team results. Ask promptfoo which controls ship with the Enterprise tier and which you must supply yourself, and agree on who owns session timeouts, offboarding, and the review of group membership over time.
Which promptfoo components carry identity and access
Identity and access in a promptfoo deployment is spread across several components, and each one controls a different part of who can reach what. The self-hosted app, its SQLite store, the deployment method, the network entry point, the Enterprise access features and the provider keys each need to be checked separately before a shared instance goes live.
Express server serving the web UI and API
The self-hosted promptfoo app is an Express server that serves both the web UI and the API from the same process. It is the first place where a user request is accepted, so any login or session control has to be enforced here or in front of it. Self-hosted promptfoo does not include built-in authentication, so the server alone does not tell you who is calling. Confirm which requests are reachable without a session and whether the API can be called directly from other networks.
Local SQLite database
Self-hosted promptfoo stores its data in a local SQLite database. This file holds eval results and related records, so it is where access to past outputs ends up. The database cannot be shared across replicas and has no role-based access control of its own, which means anyone with file-system access to the volume can read its contents. Check the file permissions, the volume mount and who can run backups of it.
Docker, Compose and Helm deployment options
The app can be deployed with Docker, Docker Compose or Kubernetes using Helm. The chosen method decides where the container runs, which ports are published, how secrets are injected and who can change the configuration. None of these options adds user login or SSO by itself. Review the published ports and the secret handling in your chosen template before treating the deployment as access controlled.
Network entry point
A reverse proxy or ingress in front of the app is usually the only place where identity can be checked for a self-hosted instance. Whatever sits at this layer decides which users and networks reach the UI and API at all. Confirm that the app is not directly exposed on a public address, that the proxy enforces the authentication method your organization chooses, and that health and metrics endpoints are handled consistently with the rest of the service.
Enterprise teams and custom roles
Enterprise adds teams-based access control, SSO and custom roles and permissions. These features are what provide per-team separation inside promptfoo itself, and they are not present in the self-hosted app. Ask the vendor which Enterprise features are included in the On-Premise deployment, how SSO is configured, and how role changes are logged and reviewed. Verify each permission against the team structure you actually need.
Provider API keys
Provider API keys let promptfoo call model providers, so they are a form of access in their own right. Their location decides who can use them: environment variables, configuration files, a secrets manager or the UI. Keys supplied through the UI or stored in shared configuration can be seen by anyone with access to that layer. Confirm where each key is stored, how often it is rotated and which accounts or services are allowed to read it.
Which access model fits the team
This table compares five ways to give a team access to promptfoo, from a single local run to On-Premise Enterprise. Read each row for when the option fits and what it asks your team to operate, such as ownership of a proxy, tiers to maintain and who manages identity. The main takeaway is that identity features are the dividing line: the self-hosted app has no built-in authentication or SSO, so any shared instance needs protection added around it or an Enterprise tier.
| Access model | When it fits | Ongoing operational cost |
|---|---|---|
| Single-user local run | One engineer runs evals and red team scans on a workstation or CI runner. Evals run locally and call the model provider directly. | Little beyond keeping the install current and protecting provider API keys on each machine. No shared identity to manage. |
| Self-hosted instance restricted at the network layer | A small group needs a shared results view on a private network, and the team accepts that the app itself has no user accounts. | Your team owns network segmentation, VPN or allowlist rules and their review. Anyone who reaches the network can use the app, so access lists need regular checks. |
| Self-hosted instance behind an identity-aware proxy | Several teams need individual sign-in on a shared instance and you have an identity provider and a platform team to run the proxy. | Your team owns the proxy, its upgrades, its session and policy configuration and its logs. Confirm how the proxy handles SSO groups, since promptfoo itself does not enforce per-user roles on this path. |
| Enterprise hosted with SSO and teams-based access | You want teams-based access control, SSO, custom roles and permissions without operating the access layer yourself. | Subscription cost at custom pricing, plus the vendor-managed identity setup. Confirm which SSO protocols, role mappings and hosting regions are included before you commit. |
| On-Premise Enterprise on your infrastructure | Data must stay inside your own environment with the Enterprise feature set, and you need a dedicated deployment engineer. | Your infrastructure, hosting and patching costs, plus a subscription at custom pricing. Ask who operates identity integration and upgrades after handover. |
What the access controls can and cannot restrict
A network gate, reverse proxy or identity-aware front door decides who can reach a self-hosted promptfoo instance at all. It does not decide what a user sees or changes once inside. Inside the application, the controls that matter are the teams-based access control, SSO and custom roles and permissions that the Enterprise edition adds, and the self-hosted app has none of them. Plan for two separate layers: a perimeter layer that you build and operate yourself, and an in-app layer that exists only if you license Enterprise or On-Premise. Confirm with promptfoo which of the two you are actually buying before you design the perimeter around it.
Provider API keys are shared by whoever runs an eval. Evals run against model providers using keys configured for the instance or the project, and anyone who can start a run can cause those keys to be used, and spend to accrue, regardless of what else their role allows. Access controls that limit viewing do not necessarily limit running. Ask promptfoo how permissions apply to launching evals and red team runs, who can read or rotate provider credentials, and whether keys can be scoped per team or per project. Decide where the keys live and who holds them before users are onboarded.
Red team outputs can contain sensitive material. Generated attack prompts, model responses, and any data pulled into a test may reflect internal system prompts, customer data, or policy-sensitive content. Restricting who can open a shared result is a different question from restricting who can export it, copy it into a ticket, or download the underlying database file on a self-hosted instance. Confirm with promptfoo whether shared results inherit team permissions, whether exports are logged or restricted, and what a user with read access can retrieve. Treat any result set as sensitive data until that is confirmed.
A control outside the application may not cover the API. Browser sessions passing through an SSO-backed proxy are straightforward to gate, but programmatic access through the API, CLI calls from CI/CD runners, and service tokens often bypass the interactive login path. If the perimeter only checks browser sessions, an API client might still reach the instance. Confirm with promptfoo how API access is authenticated and authorized in the Enterprise edition, whether team and role rules apply to API calls, and how automation accounts are provisioned and revoked.
Build a short test plan before go-live. Use a non-privileged account to try each action: open a shared result, start a red team run, change a provider key, call the API directly with a token from outside the browser flow, and confirm that a removed user loses access on every path. Record which checks pass and which depend on a control you have not verified. The gaps you find here are the items to raise with promptfoo, and they should be closed or accepted in writing before real provider keys or production prompts enter the instance.
How to set up SSO and access control in sequence
This sequence takes a promptfoo instance from an unprotected local tool to a shared deployment where each person reaches only the teams and actions they need. Each step ends with a check, so the team knows when to move on and when to stop before inviting users.
Inventory users, teams and the roles each needs
List every person who will use the instance, the teams they belong to, and the actions each needs, such as running evals, reviewing results, editing configurations, running red team tests and administering the instance. Name an owner for each team and a small set of administrators. Record which identity provider holds each account and which groups already exist there. Self-hosted promptfoo has no built-in RBAC, so this inventory becomes the specification for every later step. The step is closed when the security owner signs off on the list and each role maps to a defined set of actions.
Choose the deployment model
Decide between self-hosting the Community edition, using Enterprise with teams-based access control and SSO, or On-Premise, which runs the Enterprise functionality on your own infrastructure with complete data isolation and a dedicated deployment engineer. Self-hosted promptfoo is an Express server deployable with Docker, Docker Compose or Kubernetes with Helm. Confirm with promptfoo which edition provides the SSO and access features your policy requires. The step is closed when the decision is written down with the edition, hosting platform and the owner who approves it.
Keep the instance off the public internet
Place the promptfoo server on a private network segment reachable only through approved routes, such as a VPN, a private load balancer or a bastion host. Restrict inbound rules to the users and systems that need the web UI and API, and block direct access from the internet. Keep the provider API keys and eval data on the same private boundary. Because the self-hosted app has no built-in authentication, network isolation is the first control in place. The step is closed when a scan from outside the approved network cannot reach the web UI or API port.
Put identity in front of the instance
Add an authentication layer before any user reaches promptfoo. Options include Enterprise SSO, which connects promptfoo to your identity provider, or an identity-aware proxy that checks each request against your directory before forwarding it. Confirm with promptfoo which SSO protocols and identity providers the Enterprise edition supports, and check whether an identity-aware proxy can pass user and group claims to the application. The step is closed when a test account without an approved identity is refused and an approved test account reaches the login flow.
Map identity groups to teams and roles
Create a mapping from each identity provider group to the matching promptfoo team and custom role, based on the inventory from the first step. Assign administrative rights to as few groups as possible and check that no group grants more access than its inventory entry allows. Record how group membership changes will be handled, including who approves them and how removed users lose access. The step is closed when a test user in each group sees only the teams and actions assigned to that group, and a user outside every mapped group sees nothing.
Move SQLite data to persistent storage
The self-hosted app stores data in a local SQLite database that cannot be shared across replicas, so run a single instance with exactly one writer. Place the database on persistent storage that survives container restarts and is backed up on a schedule your team sets. Restrict file permissions so only the service account can read or write it. Ask promptfoo which storage layouts the Enterprise and On-Premise editions support before you scale out. The step is closed when a restart of the server keeps existing evals and team data, and the backup restores into a clean instance.
Confirm the access model before inviting users
Before any broader invitation, run a short acceptance test covering each role and team in the mapping. Try actions each role should not have, such as viewing another team's evals, changing shared configurations or managing users, and confirm they are blocked. Check that removing a user from an identity group removes their access on the next login. Log who ran the tests and what they found, and keep the results with the access inventory. The step is closed when the security owner accepts the test results and the first invitation list matches the approved mapping.
How the setup changes across Docker Compose, Kubernetes and restricted networks
A single host running Docker Compose is the simplest place to run the self-hosted promptfoo app, and the SQLite limit matters least here because one container writes to one local database. Identity is the harder part. Self-hosted promptfoo has no built-in authentication or SSO, so any sign-in flow depends on Enterprise functionality being available for this deployment, and the identity provider must send users back to the host's address. That address is usually an internal DNS name or a reverse proxy in front of the container.
- Replicas: Keep the service at one container. Two containers sharing a SQLite file on a volume risk corrupted or lost writes, and the documentation states the database cannot be shared across replicas.
- Callback location: The redirect URL must resolve and be reachable from every user's browser. A service bound only to localhost will not work for colleagues.
- TLS termination: Identity providers commonly require HTTPS callbacks, so plan the reverse proxy and certificate before testing sign-in.
- Backups: Back up the volume holding the SQLite file on a schedule, since it is the only copy of shared state.
Before committing, confirm with promptfoo whether SSO is available for a Compose deployment and which identity protocols it supports. Confirm with your network team which hostname and certificate the callback will use.
Helm makes the deployment repeatable and maps the app onto Kubernetes objects such as Ingress, Secrets and persistent volumes. It does not remove the SQLite constraint. The database file still lives in one pod's storage, so a Deployment with several replicas cannot share state safely. Availability therefore depends on rescheduling a single pod rather than on horizontal scaling. The identity callback passes through the cluster's ingress controller, load balancer and DNS record, so each of those layers must agree on one hostname.
- Replicas: Keep the replica count at one and use an update strategy that stops the old pod before the new one starts, so two pods never write to the same volume.
- Persistent storage: Bind the database to a PersistentVolumeClaim using a storage class your cluster supports, and confirm how volume snapshots and restores work with your backup tooling.
- Ingress and certificates: The callback hostname must route to the ingress, match the TLS certificate and appear in the identity provider's list of allowed redirect addresses.
- Node failure: A single pod means a node failure causes downtime until the pod is rescheduled. Agree the acceptable recovery approach with your platform team.
Before committing, confirm with promptfoo whether the Helm chart supports Enterprise SSO settings, secret injection from your secrets manager and any external database option. Confirm with your platform team how the ingress and DNS records will be managed.
On a restricted or air-gapped network, the promptfoo server cannot depend on internet access at runtime, and the identity callback must stay inside the network boundary. The identity provider must be reachable from user browsers and from the promptfoo server for the sign-in exchange, which often means an internal identity provider. Installation also changes, because container images, Helm charts and npm packages must be mirrored inside the network before anything is deployed.
- Artifacts: Mirror container images, charts and npm packages internally. The current npm release requires Node.js 22.22.0 or newer, so mirror that runtime as well.
- Identity reachability: Confirm the identity provider is inside the boundary, that its metadata and signing certificates can be imported, and that it can reach the callback URL.
- Trust chains: Install the internal certificate authority in the server and in user browsers, or the callback will fail certificate checks.
- Model endpoints: The documentation states evals run locally and talk directly to the LLM. List which provider endpoints your evals and red team runs need, and confirm each one is inside the boundary or approved for an exception.
Before committing, confirm with promptfoo whether the Enterprise deployment runs without outbound internet access and whether any licensing or telemetry check needs connectivity. Confirm with your network team the DNS, proxy and firewall rules for the callback and the identity provider.
promptfoo On-Premise runs the Enterprise functionality on the customer's own infrastructure with complete data isolation and a dedicated deployment engineer. That moves much of the deployment and identity configuration into a vendor-supported model, but it does not answer the storage question for you. Ask promptfoo how the On-Premise build stores shared state, whether it still depends on a single SQLite file, and whether it scales beyond one instance. The identity callback still has to be reachable from every user's browser, whatever the vendor engineer configures.
- Engineer scope: Confirm what the dedicated deployment engineer handles, such as identity provider configuration, upgrades, backups and troubleshooting, and what remains with your team.
- Storage model: If the architecture is still single-writer, ask which backup, failover and recovery approaches the vendor supports.
- Identity agreement: Agree the supported identity protocols and the callback URL pattern before configuration starts.
- Group mapping: Map teams-based access control and custom roles to your identity provider groups, and confirm how group membership syncs and how removed users lose access.
Before committing, confirm with promptfoo the support terms, including any service levels, which are described as part of custom pricing and must come from the written agreement. Confirm with your identity team the group structure they will supply.
How to protect a shared promptfoo instance
A self-hosted promptfoo instance has no built-in authentication or role-based access control, so the controls around it carry the weight. The cards below cover the access and secrets decisions that matter most when several people or pipelines share one instance, and what to check for each.
Restrict network exposure and admin paths
The self-hosted app is an Express server that serves both the web UI and the API, and it does not provide its own login. Decide which networks can reach it at all, and keep it off public routes. Put any administrative or configuration paths behind your identity-aware proxy or VPN, and confirm that API endpoints are not reachable without that gate. Test from outside the approved network to verify the restriction.
Enforce least privilege at the gateway
Because promptfoo self-hosting has no RBAC, role separation must be enforced in front of the application. Define which groups may view evals, which may run red team jobs, and which may change configuration, then map those groups to proxy or gateway rules. Ask the vendor or your team to confirm exactly which roles, if any, the Enterprise edition enforces, so you do not assume parity with your own model.
Keep provider API keys out of shared views
Provider API keys are the most valuable secret in a shared instance, since anyone who can read a config or a log may be able to reuse them. Load keys from environment variables or a secrets manager rather than hard-coded config files. Review shared eval views, exported results and application logs for key fragments before granting wider access, and rotate any key that has appeared in a shared location.
Limit who can export or delete red team outputs
Red team outputs can contain harmful prompts, model responses and the weaknesses found in your application, so they are sensitive in their own right. Decide which role may export results to files, download them, or delete a run. Restrict those actions to a small group, and record who performed each one so that deletions and exports can be traced during an incident or review.
Enable access logging at the proxy
The application's own records may not show who viewed or exported a result, so log access at the reverse proxy or gateway as well. Capture the user identity supplied by your SSO layer, the path accessed, the method and the timestamp. Confirm that logs themselves do not store provider keys or full request bodies, and set a retention period that your security policy requires.
Keep the SQLite file under service account control
Self-hosted promptfoo stores its data in a local SQLite database, which cannot be shared across replicas. Make the file readable and writable only by the account that runs the service, and keep it off shared volumes and out of backups that broader teams can read. Check file permissions after each upgrade or container rebuild, because a new volume mount can silently widen access.
How to test that access control works and fails safely
Access control for a shared promptfoo instance is only proven when each control has a test that can fail. Before anyone relies on SSO or team boundaries, the team should run a fixed set of cases against the deployed stack and record the result of each one. The cases below cover the normal paths and the failure paths, and each one states the behavior that counts as safe. Run them against the same proxy, identity provider configuration and promptfoo deployment that users will reach, not against a local test copy.
Normal-path cases. Start with unauthenticated requests. Send requests with no session to the entry point (the reverse proxy or identity-aware gateway in front of promptfoo) and then directly to the API paths the web UI calls. The expected safe behavior is a refusal at both layers, with no eval data in the response body. Next, sign in as a user who belongs to no team and try to open an eval owned by a team that user is not in, both through the UI and by requesting the eval identifier through the API. Expected behavior is a denial that does not reveal whether the eval exists. Then, as a role with read-only rights, attempt to edit an eval configuration and to delete an eval or results. Each edit and deletion should be refused by the server, not only hidden in the interface.
Session and bypass cases. Confirm that sessions expire after the lifetime your identity policy sets, and that a session revoked in the identity provider stops working in promptfoo within the time your proxy and token settings allow. Record the actual window; the test is that it is bounded and documented, not that it matches a figure from a vendor page. Then test direct access to the promptfoo service, bypassing the proxy: from a network position that can reach the container or pod, call the application port directly with forged identity headers and with no headers. Expected behavior is that the service refuses these requests, which usually requires network policy or firewall rules, not only proxy configuration. Confirm that Community self-hosted instances have no built-in authentication, so these controls must come from your infrastructure.
Failure cases. Simulate an identity provider outage by blocking the provider's endpoints from the proxy. The safe behavior is that new sign-ins fail closed and existing unexpired sessions do not silently gain new rights. Next, present an expired or untrusted certificate to the SSO connection, and confirm that login is refused and that the error is logged, not bypassed by a fallback. Finally, misconfigure a group mapping on purpose, for example by mapping an identity provider group to the wrong team or to an admin role in a test tenant. The test passes only if an alert or review step catches the mistake and the user receives no more rights than the mapping grants. Ask your Enterprise contact to confirm how group-to-team mapping is stored, audited and changed before you write these tests.
Recording the results. Keep each case with its input, observed response, log entry and the person who reviewed it. Repeat the full set after any change to the proxy, identity provider, promptfoo version or Helm values. Confirm with DeployOpen or your own security team which tests your assurance function requires and how the evidence will be retained, since the tests prove your configuration but do not constitute an audit.
What drives the effort and cost of SSO and access control
This table lists the factors that change the work and cost of putting SSO and access control around promptfoo, and how to keep each one contained. Read each row as a lever: the first column names the driver, the second explains why it matters, and the third gives the way to reduce it. Most of the recurring cost comes from ongoing role and group maintenance, so decide those early.
| Driver | Why it changes effort or cost | How to keep it down |
|---|---|---|
| Number of users and teams | Self-hosted promptfoo has no built-in authentication or RBAC, so every user and team change falls to your team to manage. Enterprise adds teams-based access control, which must be designed and tested for each team's projects and eval data. Expect ongoing onboarding and offboarding work that recurs for the life of the instance. | Start with a named pilot group, grant access by team rather than per person, and confirm the vendor's Enterprise seat and team model before quoting. |
| Role variations and custom permissions | Enterprise supports custom roles and permissions. Each extra role needs a defined set of rights, a mapping to identity groups, and test cases to prove it works. Role design is largely one-time, but role reviews recur as teams change. | Limit roles to a few clear functions such as viewer, evaluator and administrator, and document what each can run, view and export. |
| Number of identity providers and groups to map | Each identity provider, and each group that must map to a promptfoo team or role, adds configuration and testing. Mismatched claims are a common source of lockout or over-broad access. Mapping is one-time setup with recurring maintenance when groups change. | Use one identity source for the first rollout, and map a small set of groups from it. Ask the vendor which SSO protocols Enterprise supports before choosing a provider. |
| Number of environments | Each environment, such as development, staging and production, needs its own identity configuration, test users and access checks. Repeating the setup per environment roughly multiplies one-time effort and doubles the recurring review burden. | Start with a single environment for SSO and access control, then copy the validated configuration to others with environment-specific secrets. |
| Network and security review requirements | Internal security teams often need a review of how the instance is exposed, how sessions are handled, and where logs go. Reviews add one-time time and may require evidence that you keep for later audits. Restrictive network rules can also block identity provider callbacks until tested. | Agree the review criteria before build, reuse existing reference architectures, and keep a written record of the decisions for the assessor. |
| Sensitivity of eval and red team data | The more sensitive the prompts, outputs and red team findings, the stricter the access rules, logging and retention settings you must design. Stricter controls add build and test effort, and retention rules recur as data accumulates. | Classify eval data before the rollout, restrict who can export results, and keep sensitive projects in a separate team with tighter roles. |
| Custom integration with existing access tooling | Connecting promptfoo to an existing ticketing, access request or privileged access system needs custom work, and that code must be maintained when either side upgrades. This is usually the most variable cost, and it recurs through upgrades and support. | Prefer the identity provider's native group mapping over custom scripts. Ask for each integration to be listed as a separate line item in the written scope. |
What to monitor, back up, upgrade and document after go-live
After go-live, the access layer needs routine review, because the controls you set up only help if someone notices when they fail. Start with three signal sources: authentication failures at the identity provider and at whatever gate sits in front of a self-hosted promptfoo instance, access logs from the web app and reverse proxy, and every change to role assignments, team membership and group mappings. Self-hosted promptfoo does not ship its own authentication, so the first two sources may live outside the promptfoo process. Confirm which events your deployment writes, where they go, who reads them and how long they are kept before you rely on them in an investigation.
The data that matters most sits in one place. Self-hosted promptfoo keeps its data in a local SQLite database, and the self-hosting documentation says that database cannot be shared across replicas, so the instance holds a single copy of its state. Back up that file on a schedule your team sets, and choose a copy method that gives a consistent snapshot while the application may be writing. Confirm the approach with your platform team before the first run. A backup you have never restored is an assumption, so test restores into a separate environment and check that users, team membership, shared evals and custom roles come back as they were. Treat backups as sensitive, because eval data and red team outputs can contain prompts, model outputs and provider details, and restrict who can read them.
Upgrades change the access layer too, so treat each version as a change to test. Pin the promptfoo version and read the release notes before moving it. Node.js requirements are a common trap: release 0.124.1, published on 8 October 2026, requires Node.js 22.22.0 or newer, so a host or base image still on an older runtime may fail to start or behave unpredictably. Check the engine requirement in the package metadata, the runtime in your container image and the runtime on any CI runner before changing the pin. After every upgrade, re-run your access tests: sign in as each role, confirm the SSO redirect and group-based team assignment, check that custom role permissions still hold, verify that unauthenticated requests are refused, and confirm that sign-out ends the session.
Documentation is what lets someone other than the original builder run the access model. Keep four records current: a role matrix listing each promptfoo role, its permissions and the people or groups allowed to hold it; the mapping from identity provider groups to promptfoo teams and roles, with the date and approver of each change; named owners for the instance, the identity integration, each team and the reverse proxy or gate in front of it; and a break-glass procedure. The break-glass procedure should state when an administrator may bypass SSO, which account is used and where its credentials are held, who must approve its use, how the session is logged and reviewed, and how the account is disabled again. Rehearse that procedure on a schedule, because a break-glass path nobody has tested often fails when it is needed.
Questions buyers ask before hiring help with promptfoo SSO
Does the promptfoo Community edition include SSO?
No. The Community edition is free and includes all LLM evaluation features, all model providers and integrations, and red teaming with 10k probes per month, but the pricing page places team sharing, teams-based access control and SSO under Enterprise. The self-hosted app also has no built-in authentication, so a Community instance on a shared network has no login layer of its own. Confirm the current edition boundaries on the pricing page and with promptfoo before you plan, because packaging can change. If SSO is required, the choice is between buying Enterprise or On-Premise and placing a supported gateway or reverse proxy in front of a Community instance. DeployOpen can scope and build the gateway option in your environment, but it does not license or resell promptfoo Enterprise.
What drives the cost of adding SSO to promptfoo?
Two kinds of cost are involved, and they are paid to different parties. The first is the promptfoo license, which for Enterprise or On-Premise is custom priced and quoted by promptfoo. The second is services work, such as identity provider configuration, gateway or proxy setup, Kubernetes and Helm changes, persistence changes, testing and documentation. Setup work is one-time, while licensing, upgrades, support and model API spend recur. Costs rise with the number of identity providers, the complexity of group-to-role mapping, the number of environments, the need to move data off SQLite, and the evidence your auditors expect. Ask any quote for an itemized scope, the assumptions behind it, which items are vendor fees and which are services, and the process for change requests.
How long does a promptfoo SSO project take to complete?
Duration depends on scope rather than a fixed number, and no reliable figure can be given before the design is known. The main factors are the number of identity providers, the group and role model, the network path into the instance, the approval steps in your change process, and how many environments need testing. Dependencies on other teams often set the pace more than the technical work does. Most DeployOpen engagements are fixed-scope, which means the scope, deliverables and timeline are agreed in writing before work starts. Ask for milestones, named dependencies on your identity and network teams, and the assumptions behind each date.
What does promptfoo SSO need from our identity and network teams?
The identity team usually supplies the protocol choice, application registration in the identity provider, redirect URIs, the group or role claims to map, test accounts, MFA and session policies, and a named owner for the application. The network team supplies the ingress path, DNS records, TLS certificates, firewall rules, which subnets may reach the instance, and outbound access to model providers. Your platform engineers will need to agree on how secrets are stored and how the gateway or Enterprise configuration is deployed. Confirm the protocols and login flow your chosen approach supports, both in the promptfoo documentation for your version and with the gateway vendor, before you request access from these teams.
Can an internal team set up promptfoo SSO without outside help?
Yes, if the team has skills in identity federation, Kubernetes, networking and application security, and enough time to test authorization carefully. The first decision is the path: vendor-delivered Enterprise, On-Premise, or an external gateway in front of a Community instance. Each path has different configuration, support and upgrade obligations. Internal teams often underestimate testing for bypass of the login layer, documenting role mappings for audit, and keeping the gateway aligned with promptfoo upgrades. A useful check is to ask whether the team can write a test plan that proves unauthenticated requests are refused and that role changes in the identity provider take effect as expected. External help can cover the design review, the build or a second set of eyes on the test results.
Is SQLite acceptable for self-hosted promptfoo behind Kubernetes?
Not for a shared production deployment, according to the promptfoo self-hosting documentation. The local SQLite database cannot be shared across replicas, and the self-hosted app has no horizontal scaling. Running several pods against separate local files would produce inconsistent data, and a single pod with a persistent volume is a fragile single point of failure. A small, non-production instance with a single replica and a persistent volume may be acceptable for testing, provided you accept that limit in writing. For a shared production instance, confirm whether your promptfoo version supports a shared database, and check the release notes for the version you run. The npm release 0.124.1 requires Node.js 22.22.0 or newer, which is a useful detail for your image build.
Does DeployOpen issue compliance certifications for promptfoo access controls?
No. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. DeployOpen prepares the systems, configuration, access controls and evidence that an assessor will review, such as documented SSO settings, role mappings, access logs, test results and change records. Before the work starts, ask which framework applies to your organization and which controls it covers, then ask the assessor what evidence they expect. The promptfoo red teaming documentation references the OWASP LLM Top 10, the NIST AI Risk Management Framework and the EU AI Act as testing references. They support systematic testing and do not confer certification on a deployment.
How DeployOpen works on this
DeployOpen plans and implements access control for promptfoo inside your own infrastructure, from the point where a shared instance needs authentication to the point where it is handed to your team. The work follows a written, fixed scope, so you know what gets built, tested and documented before anything starts.
How we scope
- Confirm which edition fits the need: self-hosted Community, Enterprise, or On-Premise, with SSO and teams-based access control as the deciding requirements.
- Map who needs access to evals, red team results and provider settings, and which teams should be separated from each other.
- Record the identity provider, hosting target, Docker, Compose or Helm deployment method, and the data retention rules in the written scope.
How we build
- Place the self-hosted app behind an authentication layer or the Enterprise SSO configuration, and test login, logout and session expiry end to end.
- Address the self-hosted SQLite limits by planning persistence and access for a shared instance, and confirm replica and scaling constraints with the vendor.
- Test role boundaries with named test accounts, confirming users cannot view or change other teams' evals, provider keys or red team outputs.
How we hand over
- Deliver configuration files, deployment manifests and a runbook covering role assignments, onboarding and offboarding steps for users.
- Document the access model, including which roles exist, what each role can do, and the evidence produced by each access test.
- Walk your platform and security staff through the setup and transfer administrative ownership of the identity integration to your team.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, covering promptfoo release changes and Node.js requirements.
- Re-test access control after each upgrade or identity provider change, and update the runbook with the results.
- Agree support scope, response expectations and review cadence in writing, with pricing provided through a quote based on that scope.
