Which promptfoo Enterprise model fits your team's data and operating rules
Choose promptfoo Enterprise SaaS if your team wants governed red teaming without running infrastructure, and your data rules allow scans and results to be handled by the vendor. Promptfoo maintains the SaaS product, so your team starts without operating servers. Choose promptfoo Enterprise On-Prem if your data classification, network policy or regulator requires that scans stay inside your perimeter. On-Prem deploys into your own environment on a major cloud provider, and its dedicated runner executes scans within your network perimeter, which is the component that answers the question "where do the attack prompts actually run?" Before you pick, write down three things: which data may leave your boundary, whether your network team will permit outbound calls from a runner, and who on your side will patch and back up the platform.
On-Prem moves operating work to you, even though the vendor provides the software and a dedicated deployment engineer. The pricing page describes On-Premise as deployment on your own infrastructure with complete data isolation and an assigned deployment engineer, at custom pricing. Ask the vendor in writing what the engineer covers during deployment, what remains your team's job for upgrades and backups, which cloud services and runner resources you must provision, and what the quote includes beyond the license. Those answers, not the license line, determine your recurring cost. Confirm also which identity and sharing controls are available in your chosen model, since the Enterprise docs and pricing page describe SSO, RBAC and team sharing as Enterprise features.
The free self-hosted server is not a substitute for either paid model. The self-hosting documentation describes an Express app with 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. If your reason for self-hosting is data control, the On-Prem tier is the option that adds network isolation, a dedicated runner and self-hosted sharing. If your reason is cost alone, the Community edition runs evals locally and includes red teaming with a monthly probe allowance, but it lacks the governance controls a shared red team program needs. Confirm these details against the current promptfoo Enterprise documentation before you commit.
How promptfoo Enterprise SaaS and On-Prem differ on control, operation and features
This table compares the vendor-run SaaS, the on-premises deployment in your own cloud and the free self-hosted server across the factors that decide who runs the platform and where data and scans sit. Rows marked to verify are items the published facts do not settle, so confirm them with the vendor before you commit.
| Factor | Enterprise SaaS | Enterprise On-Prem | Self-hosted server (free) |
|---|---|---|---|
| Who operates it | Promptfoo maintains the managed service, so your team runs no infrastructure | Deployed in your environment on a major cloud provider, with an assigned deployment engineer | Your team installs, patches and runs the Express app with Docker, Compose or Helm |
| Where red team scans execute | On the vendor-managed service (confirm the exact hosting region with the vendor) | Inside your network perimeter through the dedicated runner component | On the host or cluster where you deploy the server |
| Data isolation | Vendor-managed environment (verify tenancy model and data residency with the vendor) | Complete data isolation in your own infrastructure, per the pricing page | Local SQLite database on your infrastructure, not shared across replicas |
| Network isolation | Not listed as a feature in the Enterprise docs (verify egress paths and model access) | Listed as a feature, so scans and results can stay inside your network | Depends on how you deploy and segment the server |
| Self-hosted sharing | Team sharing is hosted by the vendor | Self-hosted sharing is listed for complete control over data | Not offered as an Enterprise sharing layer |
| SSO and RBAC | Teams-based access control, SSO and custom roles are listed for Enterprise (verify which identity providers are supported) | Enterprise functionality is listed, so confirm the SSO and role model in your build | Not available: no RBAC, built-in authentication or SSO |
| Continuous monitoring and guardrail dashboard | Listed in Enterprise, with remediation recommendations (confirm which features ship in each deployment type) | Runs the Enterprise functionality per the pricing page (confirm parity with the SaaS feature list) | Not listed for the self-hosted server |
| Pricing basis and support | Custom pricing, with priority support and SLAs listed (ask for the SLA terms in writing) | Custom pricing covering deployment and a dedicated engineer (ask for the scope and support windows) | Free to self-host, with community support only |
What data location and network isolation mean for compliance
Compliance evidence for AI red teaming depends on where prompts, responses and scan results are stored and where scans execute. The cards below separate the two deployment models, the runner inside your network, data isolation, access control and the framework evidence you will need to assemble.
Where data and scans run
In promptfoo Enterprise, the vendor operates the platform as a fully-managed SaaS, so the control plane sits outside your environment. In promptfoo Enterprise On-Prem, the platform is deployed in your own cloud account. Ask each vendor where scan traffic, stored results and logs are written, which regions are used and who holds administrative access to the hosting environment.
Dedicated runner inside your perimeter
The On-Prem edition includes a dedicated runner component that executes scans within the customer's network perimeter. This matters when target model endpoints are internal or reachable only from private networks. Confirm which network paths the runner needs to reach your models, whether outbound egress to the model providers is allowed, and how runner updates are staged.
Complete data isolation
The pricing page describes On-Premise as providing complete data isolation on your own infrastructure. Treat that as a vendor statement to verify, not an assumption. Ask which telemetry, usage data or license checks leave your environment, whether any prompts or model outputs are sent to the vendor, and how isolation is documented for an assessor.
Access control through teams, roles and SSO
Enterprise tiers add teams-based access control, SSO and custom roles and permissions. These controls determine who can view red team results, change configurations and export findings. Map them to your identity provider groups before rollout, and confirm whether role assignments are logged in a form your auditors can sample.
Evidence for OWASP, NIST and the EU AI Act
The OWASP LLM Top 10, the NIST AI Risk Management Framework and the EU AI Act are referenced in promptfoo's red teaming documentation as frameworks that support systematic testing before deployment. They do not prescribe a product. Your evidence will be scan configurations, dated results, remediation records and access logs mapped to each framework's requirements.
Who prepares evidence and who attests
DeployOpen can plan the deployment, document data flows and prepare the controls and evidence that an assessment will examine. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so agree the evidence list with your assessor before implementation begins.
Where red team scans execute in each deployment model
In the vendor-run model, Promptfoo operates the Enterprise service, so your team does not run the control plane. Scans are orchestrated from the managed service, and the decision you must make is whether that location is acceptable for the systems under test. promptfoo Enterprise On-Prem changes this placement. It is deployed in your own environment on any major cloud provider, and its dedicated runner executes scans within your network perimeter. The first question is therefore not who hosts the dashboard but where each scan request starts and which network boundary it crosses before it reaches the model under test.
The promptfoo introduction states that the software runs completely locally, with evals running on your machine and talking directly with the LLM. That description covers the open-source workflow. It does not by itself say where the Enterprise control plane, attack generation or result storage sits in each tier, so do not assume it carries over. For the request path, trace three roles: the component that generates adversarial prompts, the component that sends them to the target, and the component that receives responses and scores them. Ask Promptfoo in writing which of these run in the vendor's service, which run in your runner, and which call external model providers such as hosted APIs. Your design may route traffic through an internal gateway, so confirm each egress point and the endpoint each call uses.
Use this as a check before you choose a tier. Draw the scan path for one target, mark every outbound connection, and record the firewall rules each one needs. If the model under test is an internal endpoint, a SaaS deployment may not be able to reach it without exposing it, while an On-Prem runner inside the same network may reach it without public exposure. Verify that against your own segmentation. The free self-hosted server is a different case. It is an Express application backed by a local SQLite database, it has no built-in authentication or SSO, and it is not recommended for production, so scan execution on it remains entirely your responsibility. Keep this diagram with your evidence for later assessments.
Which deployment fits which team situation
Teams without engineers to run databases, upgrades and access controls usually get the most value from the vendor-run SaaS. Promptfoo Enterprise is described as a fully-managed SaaS maintained by Promptfoo, so the team starts without running infrastructure. The trade-off is that the operating burden moves to the vendor, and your scan history and configuration live in the vendor's environment. This model is the better fit when security testing is a new practice, the team's priority is getting pre-release checks running, and nobody has time to patch a service. The Enterprise On-Prem option changes who operates the stack, and the pricing page says it includes a deployment engineer, so a team without platform staff should ask what that engineer does after go-live.
- Operator responsibility: Confirm which upgrades, backups and incident response the vendor performs in the SaaS model and which the customer still owns.
- Time to first scan: Ask how many engineering hours your team must spend before the first red team run, since this is a key cost driver.
- Vendor-held data: Ask where scan results, prompts and target details are stored and how long they are retained.
- Support commitments: Request the written support and SLA terms for the tier you are buying, because the pricing page ties priority support with SLAs to Enterprise.
- Exit path: Ask how you export configurations and results if you later move to self-hosting.
Before committing, confirm each of these in writing with the vendor, since the pricing page leaves the quote custom.
Regulated teams whose prompts, retrieval data or target responses cannot leave their network usually need the on-premises model. Promptfoo Enterprise On-Prem is deployed in the customer's own environment on any major cloud provider, and its dedicated runner executes scans within the customer's network perimeter. The pricing page describes complete data isolation for this tier. This is the better fit when a data protection policy, contract or regulator requires that test traffic and results stay inside your boundary. It is not automatically compliant, and it does not replace your own control evidence, so treat it as one input to your assessment rather than the answer.
- Runner location: Confirm where the dedicated runner executes and which outbound connections it makes, including model provider calls.
- Model endpoints: Map which target models receive red team prompts and whether they are hosted inside or outside your perimeter.
- Isolation scope: Ask which components, logs and telemetry remain inside your network and which, if any, reach the vendor.
- Hosting footprint: Confirm the cloud accounts, regions and Kubernetes or VM requirements your platform team must provide.
- Frameworks: Map the OWASP LLM Top 10 and NIST AI RMF controls you need evidence for, since promptfoo documentation references both as testing frameworks.
Get the isolation and data flow described in a written architecture document before procurement signs off.
Some teams need scan results and findings shared across application owners, security reviewers and auditors without sending data to a vendor-hosted service. Promptfoo Enterprise On-Prem offers network isolation and self-hosted sharing, a capability the promptfoo Enterprise documentation lists as absent from the Community and cloud tiers. This model suits organizations where collaboration is required and external hosting is not acceptable. It is a weaker fit if your only need is for one engineer to run scans locally, because the sharing features add a deployment that someone must operate.
- Sharing scope: Define which roles see which results, and confirm that team sharing and access control in the tier you buy cover those roles.
- Identity integration: Confirm SSO support with your identity provider, since the pricing page lists SSO and custom roles with the Enterprise tier.
- Access review: Ask how role changes and access logs are recorded, because auditors will ask for them.
- Notification paths: Check whether findings can flow into your ticketing or SIEM through supported integrations, or whether you must build them.
- Operating ownership: Assign a named owner for the on-premises instance, including upgrades and backups.
Confirm the sharing model, identity integration and operating owner with the vendor before scoping any internal deployment work.
Teams that only need automated checks on prompt or model changes often do not need an Enterprise tier at all. The promptfoo CLI is MIT licensed, runs locally from declarative configs, and can run checks in CI/CD pipelines. The documentation states that evals run on your machine and talk directly with the LLM. The Community edition is free and includes all LLM evaluation features, all model providers and integrations, and red teaming with 10k probes per month, with community support. This model is the better fit when the pipeline gate is the primary control, volume stays within the probe allowance, and no one needs shared dashboards or role-based access. The self-hosted server is a different case, because it stores data in a local SQLite database that cannot be shared across replicas, has no RBAC or built-in SSO, and is not recommended for production use.
- Probe volume: Estimate monthly probe use against the 10k allowance before relying on the free tier for scheduled scans.
- Pipeline setup: Confirm the CI runner image meets the Node.js requirement (22.22.0 or newer for release 0.124.1).
- Result retention: Decide where JSON or JUnit outputs are archived, since the CLI does not provide a shared history.
- Self-hosted server: Do not place the self-hosted app in production as a shared service without a plan to move beyond SQLite and local authentication.
- Upgrade path: Track release notes so the pipeline stays on a supported version.
Verify your probe volume and runner requirements against the current pricing and release pages before choosing this path.
What your team runs in each model
Who patches and upgrades promptfoo Enterprise in the SaaS model?
Promptfoo maintains promptfoo Enterprise as a fully-managed SaaS, so the vendor runs the platform and its upgrades. Your team does not install patches or schedule platform upgrades on infrastructure you own. What you still control is how your own configurations, test suites and CI integrations change as the product changes. Ask the vendor how it communicates release timing and what notice you receive before changes that affect your workflows, and confirm those terms in writing before you sign.
Who handles deployment and upgrades for promptfoo Enterprise On-Prem?
promptfoo Enterprise On-Prem is deployed in your own environment on a major cloud provider, and the pricing page lists an assigned deployment engineer as part of the On-Premise tier. That engineer supports the deployment, but your team still owns the cloud account, the network, and the host and identity layers beneath it. Confirm with the vendor who applies each upgrade, who holds administrative access to the environment, and how the deployment engineer's responsibilities are written into the agreement.
Where do red team scans run in each model?
In the SaaS model, the vendor operates the service, so scan execution is part of the managed platform. In On-Prem, the dedicated runner component executes scans inside your network perimeter, which is the setting that matters most for teams whose target systems sit behind internal networks. Ask the vendor which components call out to external model providers, where results are stored, and what the runner needs in terms of compute and network paths, since these determine how you size and monitor it.
How does runner capacity differ between SaaS and On-Prem?
On-Prem gives you a dedicated runner, so scan capacity is a resource you provision in your own cloud and can scale to match your release cadence and scan volume. In the SaaS model, capacity is managed by the vendor as part of the service, and you do not size it. Plan for the runner's compute, storage and network needs before rollout, and ask the vendor for its sizing guidance and how capacity changes when you add pipelines or teams.
How does identity integration work in each model?
The promptfoo pricing page lists SSO, teams-based access control, and custom roles and permissions as Enterprise features, and On-Prem runs the Enterprise functionality on your infrastructure. Your team owns how those integrations connect to your identity provider in each deployment. Confirm which identity protocols the vendor supports in your chosen model, how group mappings are maintained, and who administers accounts and role assignments over time.
Who is responsible for backups in each deployment model?
In the SaaS model, data retention and recovery are part of the vendor's managed service, so ask the vendor what it backs up, how often, and how you would restore data after an incident. In On-Prem, backups are your responsibility within your own environment, including the storage that holds scan results and configuration. Your backup plan should cover the data stores, the runner's configuration, and tested restore procedures that your recovery objectives require. Confirm the backup scope and restore responsibilities in the written agreement.
What monitoring and network rules does each model require?
On-Prem offers network isolation and complete data control, which means your security team defines the network rules, egress paths and monitoring for the deployment. In the SaaS model, the vendor manages the service boundary, and your team controls the connections from your pipelines and targets to it. Decide which logs you need for security operations, how they reach your monitoring stack, and which outbound destinations the scanners may reach. Confirm with the vendor which logs and metrics are exposed in each model.
Can a team run promptfoo Enterprise On-Prem without vendor help?
The On-Premise tier includes an assigned deployment engineer, so the vendor's involvement is part of what you buy at that level, while a self-hosted promptfoo server has no equivalent managed support. Running the free self-hosted server is a different job: the documentation describes a local SQLite database that cannot be shared across replicas, and it lacks RBAC, built-in authentication and SSO, and is not recommended for production. Teams that need production controls should compare the Enterprise options against the effort to build those controls themselves, and ask the vendor which responsibilities transfer to them.
How cost is structured for SaaS, On-Prem and the free server
The promptfoo pricing page lists Community as free, with all LLM evaluation features, all model providers and integrations, and red teaming with 10k probes per month, supported by the community. Enterprise and On-Premise are both at custom pricing, so there is no published figure to compare. The cost of the two commercial options is set by the written scope, and the free server carries a different set of costs that most teams underestimate. Start by separating what you pay the vendor from what you pay your own staff and infrastructure.
For Enterprise (SaaS), the main recurring cost is the subscription, which covers team sharing, SSO, custom roles, continuous monitoring and priority support with SLAs. Promptfoo operates the platform, so your staff cost is mostly integration and governance. For Enterprise On-Prem, the subscription sits alongside cloud infrastructure you pay for in your own account, the compute and storage that host the platform and the dedicated runner that executes scans inside your network perimeter, plus the internal engineers who patch, upgrade and back it up. For the free self-hosted server, there is no vendor fee, but you carry all hosting, authentication work, backups and the SQLite limitations, and the documentation says it is not recommended for production. Those engineering hours recur every month and are often the largest line item.
Ask for the quote to state the subscription term, the number of seats or teams, whether the dedicated runner and assigned deployment engineer are included, who performs the initial deployment and upgrades, and what support response commitments apply. Confirm which infrastructure is provisioned by you and which by the vendor, and whether the probe allowance or scan volume is limited. Ask how renewals and price changes are handled. Model your own staffing cost for the On-Prem and self-hosted options before you compare the subscription figures, because a lower quote can still cost more to run.
Moving between the free server, SaaS and On-Prem
This sequence moves evaluations, red team datasets, access rules and CI gates from the self-hosted server to Enterprise SaaS or Enterprise On-Prem while keeping a record of what was tested. It matters because the self-hosted server stores data in a local SQLite database that cannot be shared across replicas, and it has no RBAC, horizontal scaling, built-in authentication or SSO. The promptfoo documentation does not recommend it for production use.
Inventory configs, datasets and access
The team that owns the current server lists every evaluation config, red team dataset, provider target, scheduled scan and user with a login. Record where each item lives, including any results kept only in the local SQLite database on the server. Mark each item as keep, rebuild or drop. The output is a written inventory signed off by the security lead and the platform owner, so nothing is lost during the move.
Confirm migration tooling with the vendor
Before any data moves, ask promptfoo whether it offers an import or migration path from the self-hosted server to Enterprise SaaS or Enterprise On-Prem. The public material reviewed here does not describe migration tooling, so treat it as unconfirmed. Ask whether stored results, sharing settings, team roles and SSO mappings carry over, and which items must be recreated by hand. The output is a written answer that sets which later steps are copy operations and which are rebuilds.
Export or recreate configs in the target
Move each config and red team dataset into the target environment, using whichever path the vendor confirms. For the SaaS tier, the target is the vendor-managed workspace. For On-Prem, the target is the instance in your cloud account, with the dedicated runner deployed inside your network perimeter. Check that each file loads and that each target points to an endpoint your environment can reach. Done means every inventoried config loads in the target with changes limited to endpoint and credential values.
Rebuild teams, roles and SSO
Recreate teams, access control, custom roles and SSO settings in the target, because the self-hosted server has no RBAC or built-in authentication. Map each inventoried user to a team and role, and confirm with the identity team which identity provider group feeds which role. Review the access list with the data owner before anyone signs in. The output is a signed access matrix that matches the old inventory, with no shared accounts left in the target.
Validate scans against the same targets
Run the same configs against the same model endpoints in the old and new environments, then compare pass and fail results, error output and report contents. Differences in model versions, provider keys or network routes can change results, so record them before comparing. For On-Prem, check the runner logs to confirm scans execute inside your network perimeter. Done means the new results match the old within a variance you have documented, and any gap has a recorded cause.
Cut over CI pipelines
Point pipeline jobs at the new endpoint, credentials and runner. Start with a non-blocking stage so early failures do not stop releases. Keep the old server available in parallel until the new gate has run successfully on several real pull requests, and record those run identifiers. Update pipeline variables and secrets so no job still sends traffic to the old server. The output is a pipeline run history showing the new gate in use and the old job removed from the release path.
Retire the old server store
After the new environment passes validation and CI has moved over, export an archive of the old SQLite database and configs, then stop the self-hosted server. Store the archive under the retention rules your compliance team has set, and confirm who may restore it. Remove stored provider keys and user accounts from the old host before decommissioning it. Done means the old server is stopped, the archive has a named owner, and the migration inventory is closed.
Questions buyers ask before choosing SaaS or On-Prem
What drives the cost of promptfoo Enterprise On-Prem?
The cost comes from two sources: the promptfoo subscription and the work to run the deployment in your own environment. The promptfoo pricing page lists On-Premise at custom pricing, so the subscription is quoted by promptfoo, not published. The main drivers on your side are the cloud accounts and compute the runner and platform need, the number of teams and users, the volume of scans you plan to run, and the staff time to operate upgrades and access reviews. Ask promptfoo for a quote that separates the license, deployment support and any recurring operations costs, and ask what a deployment engineer covers and what your team still owns.
How long does an on-prem promptfoo deployment take?
No duration is published in the sources for this comparison, so confirm the timeline with promptfoo in writing. The main drivers are the cloud provider and account structure you use, how quickly network paths, DNS and certificates are approved, whether the dedicated runner needs egress to the model providers you test, and how long identity integration takes. Teams with existing landing zones and an identity provider ready for SSO usually move faster than teams that must design network segmentation first. Ask for milestones tied to your environment, not a generic estimate.
What does an on-prem deployment need from our cloud and identity teams?
Your cloud team owns the account, the network placement of the platform and the runner, the private connectivity to model endpoints, storage, backups and the logging you need for audit. Your identity team owns the SSO configuration, group mappings that feed the teams-based access control, and the process for provisioning and removing users. Both teams should review which outbound destinations the runner needs, since scans execute inside your network perimeter. Agree these responsibilities in the written scope so that nobody assumes the other team handles patching or access reviews.
Can our team run promptfoo On-Prem without outside help?
It depends on your staff's experience with Kubernetes or container platforms, cloud networking and secure configuration, and on how much of the operating load you want to keep in-house. promptfoo's On-Premise tier includes an assigned deployment engineer, so confirm exactly what that engineer does during setup and after go-live. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms in the client's own infrastructure, and offers ongoing support as a retainer. Whichever route you take, write down who performs upgrades, backups and restore tests before you sign.
Does On-Prem remove the need for SSO?
No. On-Prem changes where the platform runs and where scans execute, but the sources here list SSO as an Enterprise feature that applies across the Enterprise tiers, and the self-hosted server has no built-in authentication or SSO. You still need to connect the platform to your identity provider, define groups and roles, and review access on a schedule. Confirm with promptfoo which identity protocols are supported in the On-Prem build and how role mappings are managed. Treat identity integration as its own workstream in the scope rather than a side effect of deployment.
Is the free self-hosted promptfoo server enough for production?
For a single team running evaluations and red team checks locally or in CI, the free tools may be enough. The self-hosted promptfoo app stores data in a local SQLite database that cannot be shared across replicas, has no RBAC, no horizontal scaling and no built-in authentication or SSO, and the documentation says it is not recommended for production. Teams that need shared results, access control, continuous monitoring or a centralized guardrail dashboard should compare the Enterprise tiers. The Community edition covers all evaluation features and red teaming with 10k probes per month, with community support.
What should we get in writing before signing an On-Prem engagement?
Ask for a written scope that names the deliverables, the environments covered, the responsibilities of each party, the upgrade and support model, and the acceptance criteria. Include the runner network requirements, the identity integration approach, the backup and restore expectations and any compliance evidence you need to collect. If DeployOpen is involved in implementation, its engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Compare each proposal against the same list so that cost and effort are comparable.
How a DeployOpen engagement scopes a self-hosted promptfoo deployment
DeployOpen plans, implements, integrates, hardens, backs up and supports self-hosted platforms inside your own cloud account, data center or air-gapped network, and that is the boundary a scoping conversation starts from. For promptfoo Enterprise On-Prem, the vendor describes the product as deployed in the customer's own environment on any major cloud provider, with a dedicated runner that executes scans inside the customer's network perimeter. Before any work starts, the written scope should name which cloud or network the platform lands in, where the runner sits relative to the model endpoints it will test, how it reaches your identity provider, and who holds administrative credentials. Most engagements are fixed-scope, so deliverables, environment prerequisites and acceptance checks should be agreed in writing before implementation begins. Ask for the scope to list each of these as a numbered deliverable.
The vendor's deployment engineer is part of the On-Prem offer, as the promptfoo pricing page describes it, and DeployOpen's role sits alongside that rather than replacing it. DeployOpen is not a promptfoo partner, reseller or certified provider unless the vendor says so in a supplied fact, so confirm directly with promptfoo which responsibilities the vendor engineer covers, which fall to your team and which DeployOpen would take on. Ask the vendor to confirm in writing how the deployment engineer's work interacts with your change management, and who owns upgrades to the runner and the platform. Those questions should be settled before you compare quotes, because they determine what a quote actually buys.
Your scope should also cover the work that sits around the product: hardening the host and container images to your baseline, configuring backups and restore tests for the platform's data store, integrating evidence collection for your compliance assessment, and defining the support path after go-live. DeployOpen prepares systems and evidence for assessments but does not issue audit reports or attestations, so the scope should say which artifacts you will hand to your auditor. Cost follows the written scope: one-time items include design, installation, integration and hardening, while recurring items include support, upgrades and any continuous testing retainer. Ask for each line to be priced separately so you can see what recurs.
How DeployOpen delivers and supports self-hosted AI security platforms
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, including promptfoo deployments. We work from a written scope so you can compare the on-premises path against the vendor-run SaaS on facts about your environment, not on assumptions.
How we scope
- Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.
- We map which teams, pipelines and targets need red team scans and where those scans should execute.
- We record network boundaries, identity provider requirements and data residency rules that affect the cloud or on-premises choice.
- Ask us to confirm in writing which promptfoo Enterprise On-Prem features and deployment steps are in scope.
How we build
- We deploy promptfoo Enterprise On-Prem into your own cloud account, data center or air-gapped network where your scope requires it.
- We configure the dedicated runner so scans execute inside your network perimeter, and document the network paths it needs.
- We wire red team configurations into your CI/CD pipelines and connect SSO and team access controls to your identity provider.
- We test the deployment and the scans against the scope before handover, and document any gaps we find.
How we hand over
- You receive architecture notes, configuration documentation and runbooks covering installation, upgrades and access control.
- We document the controls and evidence that support your compliance readiness work, without issuing any audit report or certification.
- We walk your operators through scan execution, monitoring and backup procedures so your team can run the platform.
- Handover acceptance criteria are written into the scope, so both sides agree on what done means.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
- Ask for the retainer terms in writing, including who applies upgrades and how change windows are agreed.
- Support covers the self-hosted deployment in your environment, so confirm the vendor-side support boundary with promptfoo before signing.
- Request a quote based on your written scope, since DeployOpen does not publish a price list.
