How promptfoo upgrades and support work after go-live
After go-live, this service keeps promptfoo current and keeps the evaluation and red team pipelines that depend on it running. It covers version pinning in CI, Node.js runtime alignment, patching of any self-hosted instance, and support for failures that surface after handover. Teams that run evals and red team scans in CI often find that the release cadence moves faster than their change process, so a tool that worked in March may need attention before the next pipeline run. Several events trigger upgrade work. New promptfoo releases add providers, assertions and red team capabilities, and each release may change configuration behavior or output. The current npm release, 0.124.1, requires Node.js 22.22.0 or newer, so a runtime floor change in a CI image or developer laptop can break the tool before anyone changes promptfoo itself. A self-hosted instance also needs patching for its operating system, container image and Helm chart, and that work is easy to miss when no one owns it. The most common gap is a team with no named owner for upgrades at all. The short answer is that most teams can upgrade a local CLI themselves. The work is a version bump, a run of the existing suite, and a review of changed output. Many teams outsource the self-hosted and pipeline side instead, because it involves container images, database persistence, access controls and CI runners that someone must maintain on a schedule. Before deciding, confirm who will track releases, who approves a version change, and how a failing eval run gets triaged. Ask for the pinned version in each pipeline, the Node.js version each runner uses, and the owner of any shared instance. Those answers determine whether the work stays in-house or moves to a retainer. On vendor context: OpenAI acquired promptfoo, announced on 9 March 2026. The founders state that promptfoo will remain open source and continue to support a diverse range of providers and models. Confirm with your own procurement and legal teams how that acquisition affects any future commercial terms you rely on, and keep the open-source license terms (MIT) in your change review.
What promptfoo upgrade and support work includes
Upgrade and support work for promptfoo covers the CLI, library and CI uses, the Node.js runtime beneath them, and any self-hosted deployment that a team runs for shared evals or red teaming. Each item below is a decision or check that keeps a working eval pipeline stable across frequent releases. Deliverables are agreed in a written scope before work starts.
Version baseline and usage inventory
The work starts by recording which promptfoo version each pipeline uses, whether it runs the CLI, imports the library, or calls the self-hosted app, and which CI jobs, eval configurations and red team runs depend on it. This inventory shows which upgrades touch which pipelines. Ask the team to confirm who owns each pipeline and where its configuration files live before any version changes.
Node.js runtime alignment
The promptfoo 0.124.1 release, published on npm on 8 October 2026, requires Node.js 22.22.0 or newer. The work checks every build agent, container image and developer workstation against that minimum and records where older runtimes remain. Runtime changes often affect other tools on the same host, so confirm with the platform team which runtime versions they already support.
Version pinning and update policy
Pipelines should install an exact promptfoo version rather than a floating range, so eval results stay comparable between runs. The work defines a written update policy: who reviews a new release, how it reaches a test branch first, and how the pinned version changes in CI. Confirm the lockfile and container image tags are included in that policy.
Upgrade rehearsal on an eval suite copy
Before a pinned version moves in production CI, the team runs the upgrade against a copy of the eval suite and red team configurations. The rehearsal compares assertion results, provider calls and report output with the current baseline and lists every difference for review. Confirm that the copy uses non-production provider keys and that any stored results are kept separate from live data.
Self-hosted Docker, Compose and Helm upgrades
Teams that run the promptfoo web app on their own infrastructure upgrade it through Docker, Docker Compose or Kubernetes with Helm. The work covers image tags, configuration changes, rollback steps and the SQLite data volume, which the self-hosting documentation describes as local and not shared across replicas. Confirm the backup of that data before each upgrade and the expected downtime with the users of the instance.
Red team configuration review
Red team configurations change when promptfoo adds plugins, strategies or probe behavior, so the work reviews which plugins and frameworks each configuration uses, including references to the OWASP LLM Top 10, the NIST AI Risk Management Framework and the EU AI Act. The review also checks the monthly probe allowance on the chosen edition. Confirm which framework mappings your compliance team relies on before changing them.
Runbooks and handover
The engagement ends with runbooks that describe how to pin a version, rehearse an upgrade, roll back a self-hosted deployment and rotate provider keys. A handover session walks the internal owners through each runbook and the update policy. Agree in writing which runbooks, diagrams and walkthroughs are delivered and who on your side accepts them.
What drives promptfoo upgrade effort and support load
This table compares the factors that change how much work a promptfoo upgrade takes and how much ongoing support a team will need. Read each row as a driver: the middle column explains why it moves effort, and the last column lists what a client can do to keep it down. The main takeaway is that deployment mode, custom code and the number of environments matter more than the release number itself.
| Driver | Why it moves effort | How to keep it down |
|---|---|---|
| Deployment mode | Local CLI runs in CI, library use, a self-hosted Express app and a Kubernetes Helm chart each have different upgrade paths. The self-hosted app adds a server, a database and a web UI that must be tested after every change. | Standardize on one deployment mode per purpose and document the upgrade steps for each mode the team actually runs. |
| Number of pipelines and eval suites | Every pipeline pins or floats a promptfoo version, and every eval suite must be rerun to confirm that assertions and outputs still match after an upgrade. | Group suites by owner, keep a smoke subset that runs on every upgrade, and retire suites nobody uses. |
| Custom providers and scripts | Custom providers, transforms and scripts that call internal APIs break when promptfoo changes its provider interface or when the internal API changes. These calls are usually the most common source of failed upgrades. | Write a documented provider contract, keep custom code in version control with tests, and limit direct calls to internal APIs to one wrapper module. |
| Gap between current and target version | A large gap means more release notes to review, more deprecated options to replace and more changed defaults to test, including the Node.js minimum for the release. | Upgrade in small steps on a regular cadence instead of waiting for a large catch-up change. |
| Node.js runtime across build agents | Recent releases set a minimum Node.js version (the 0.124.1 release on npm requires Node.js 22.22.0 or newer). Every build agent, container image and developer machine must meet it, and older agents need their runtime changed before promptfoo can run. | Inventory the Node.js version on every agent and image, and pin the runtime in the same change that pins promptfoo. |
| Red team probe use | Red team runs generate probes against the target model. Probe volume determines model API spend and runtime, and any change in plugins, strategies or probe generation can change results that must be compared with earlier runs. | Pin the red team configuration with the promptfoo version, record probe counts per run and confirm the probe allowance for the edition in use. |
| Compliance evidence needs | When runs support an assessment, the team must show which promptfoo version produced each result, the configuration used and the history of changes. Assessors will ask for this record after each upgrade. | Store version, configuration and run output together in version control or an evidence store, and tag each release of the eval setup. |
| Number of environments to promote | Each environment (development, test, staging, production) needs the same version and configuration, so an upgrade is repeated for each one and any drift between them adds work. | Promote one artifact through all environments, keep environment differences in configuration files and check that versions match before each run. |
How a promptfoo upgrade is tested before it reaches CI
The upgrade test starts before anyone changes a version number in CI. Read the release notes for every version between the current release and the target, not only the final one, because a change in an intermediate version can affect assertion behavior, configuration fields or red team plugins that the target release's notes do not explain on their own. The releases page on GitHub is the primary source, and the npm package page shows publication dates. Record which versions you reviewed, which changes affect your configuration, and what you decided about each. That record is what an auditor or a new team member will ask for later.
Next, check the Node.js requirement wherever promptfoo runs. The npm release 0.124.1, published on 8 October 2026, requires Node.js 22.22.0 or newer. Confirm the runtime version in every job that executes promptfoo, including developer machines, CI runners, build agents and the base images used in container builds. Check the version the job actually reports at runtime. A runner can pass the install step and still fail later, so verify the runtime itself. If a target release raises the runtime requirement, schedule the Node.js change as a separate step so that any failure can be traced to one cause.
Run the existing eval suite and red team configuration on a pinned test branch that uses the target version. Pinning matters because a version range in a manifest can resolve to a different package on each install, and a floating container tag can change between the test run and the production run. Pin the exact npm version in the lockfile and the exact image tag in the Dockerfile or deployment manifest, and commit both. The test branch should differ from the production branch only in those pins. If anything else changes, you cannot tell whether a result difference came from promptfoo or from something else.
Compare assertion results against a stored baseline, and make the baseline record more than the scores. Model providers can update model versions, change default parameters or alter behavior under the same model name, so a score change can come from the model side even when promptfoo has not changed at all. The baseline should therefore store the provider and the exact model identifier under test, the promptfoo version, the Node.js version, a hash of the configuration file and the version of the dataset. Investigate every change in assertion outcomes, including red team results, before promoting the new pin. Confirm with each provider how it names and versions the models you use, and promote the pinned version only when every difference is explained and accepted.
How promptfoo upgrades differ by deployment
Developer machines and CI runners install promptfoo from npm, so an upgrade is a package version change. Evals run on the machine that starts them and talk directly with the model provider, so no shared service has to go offline. The main risk is drift, where engineers and pipelines quietly run different versions and produce results that cannot be compared.
- Node.js floor: The current npm release requires Node.js 22.22.0 or newer, so check the runtime on every developer machine and CI image before bumping the package.
- Version pinning: Pin the exact promptfoo version in package manifests and lockfiles so CI results stay reproducible between runs.
- Configuration compatibility: Re-run a representative set of existing configurations and assertions after the change, since configuration files are what teams keep for years.
- Provider and output behavior: Confirm that the provider integrations you rely on behave the same, and that previously stored eval outputs can still be compared against new runs.
Before rolling a new version out, confirm that the Node.js floor, the pinned version and a baseline eval run all match across developer machines and CI.
The self-hosted app is an Express server that serves the web UI and API. Upgrading means replacing the container image and restarting the service, while the SQLite database remains on a mounted volume. Rollback is therefore two steps: returning to the previous image and restoring the database that matches it. Restoring only the image can fail if the stored data was written by a newer version.
- Explicit image tags: Pin an explicit version tag and avoid floating tags such as latest, so every restart runs the version you tested.
- Database backup: Copy the SQLite file from the data volume before each upgrade. Stop the container first or use a backup method that is safe for an active SQLite database.
- Single writer: Confirm that only one container writes to a given database file, since the database cannot be shared across replicas.
- Restore test: Restore a backup into a separate container running the previous image and confirm that the data loads before you rely on it.
- Schema changes: Confirm with the vendor how schema changes are handled between releases and whether a downgrade is supported.
Close the upgrade only after the restore test has passed on a copy of the production data.
A Helm upgrade changes the chart, the image tag and the values together, and Kubernetes then replaces pods according to the rollout strategy. The self-hosted app stores data in a local SQLite database that cannot be shared across replicas, so the replica count and the storage design determine what an upgrade can safely do. Helm can revert release revisions, but it does not revert data written by the newer version.
- Replica count: Confirm that the deployment runs one replica. A second pod would have its own database state, so scaling out is not a simple upgrade step.
- Persistent storage: Verify that the SQLite file sits on a persistent volume that survives pod rescheduling and is not mounted writable by a second pod.
- Rollback limits: Take a snapshot of the volume before the upgrade. A helm rollback restores manifests and images, not the database.
- Chart and image mapping: Record which chart version maps to which promptfoo release, and review the values file alongside the image tag.
- Rollout behavior: Confirm the update strategy with the vendor, since a single replica can mean a short unavailability window during replacement.
Before approving a change, confirm the replica count, the volume snapshot and the rollback steps in a non-production namespace.
Enterprise adds team sharing, teams-based access control and SSO, custom roles, continuous monitoring and priority support with SLAs. On-Premise runs that functionality on the customer's own infrastructure with complete data isolation and a dedicated deployment engineer. The upgrade path in these models depends on contract terms and the vendor's delivery process, and public documentation does not describe either in enough detail to plan from alone.
- Upgrade ownership: Confirm whether the deployment engineer performs the upgrade, the client performs it, or both share the work, and who approves the change window.
- Support terms: Get the response commitments and the scope of priority support in writing, including what happens during an upgrade that fails.
- Artifact delivery: Confirm how new builds reach the environment, how they are verified, and how they are installed in an isolated network.
- Backup and restore responsibility: Confirm who takes backups, how often, and whether the vendor can restore client data if an upgrade goes wrong.
- Identity and access checks: Test SSO sign-in and role assignments after each upgrade, since access control is part of what the upgrade can change.
Ask for the written upgrade procedure, rollback procedure and support terms before the first change is scheduled.
The phases of a promptfoo upgrade or support engagement
The sequence moves a promptfoo installation from an unknown starting point to a pinned, tested, documented state that your team can run and upgrade on its own or with ongoing support. Each phase closes with a named artifact so you can check progress before the next phase begins.
Inventory the current installation and baseline
We record how promptfoo runs today: the CLI, library or CI/CD usage, the self-hosted app if one exists, the Node.js version on each runner or host, the provider configurations in use, and the test suites and red team configurations that depend on them. We also capture a baseline run of each suite so later changes can be compared against known results. The output is an inventory list naming every place promptfoo runs and every suite that depends on it, with the baseline results attached. The phase is done when you have reviewed and confirmed the list.
Set the runtime and version pinning plan
Using the inventory, we define the target promptfoo version, the Node.js runtime it requires, and how each environment will pin both. Recent npm releases require a newer Node.js line than some older CI images provide, so the plan lists which images, hosts or containers need updating first. We also decide where versions are pinned, such as lockfiles, CI configuration and container image tags. The output is a pinned version record that states the promptfoo version, Node.js version, and pin location for each environment. Confirm the target versions against the npm registry and the release notes on GitHub at the time of work.
Rehearse the upgrade on a copy of the suite
We apply the planned versions to a copy of the test suites and CI pipeline, never to the live configuration. Each suite is rerun against the baseline, and any change in results, assertion behavior, provider handling or output format is recorded and investigated. Where red team configurations rely on specific probe behavior or plugin names, we check them explicitly. The output is a rehearsal report listing what passed, what changed, the cause of each change, and the fixes applied. The phase closes when you accept the report or agree on the remaining open items in writing.
Promote to production with rollback steps
We apply the approved versions to production runners, hosts or the self-hosted deployment in a window agreed with your team. Before promotion, we record the currently running versions and configuration so they can be restored. Each environment is verified with a smoke run against the baseline after the change. The rollback steps name the exact pinned versions and commands to revert, and we test them on the copy before promotion where the deployment mode allows. The output is a change log recording each environment, the version before and after, the verification results, and the rollback procedure. The phase closes when the smoke runs match the baseline or the differences are explained.
Hand over the runbook and support hand-off
We write a runbook for your engineers covering how to check the installed versions, how to apply a new release through the pinned record, how to rerun the baseline, how to roll back, and who to contact for each class of problem. If you have a support retainer, the runbook also defines what DeployOpen handles, how requests are raised, and how upgrades are scheduled against new promptfoo releases. We walk your team through the runbook and confirm they can perform a routine upgrade or rollback. The output is the runbook and a closing change log entry. The phase is complete when your named owners have acknowledged the handover in writing.
Which promptfoo upgrade tasks teams keep in-house and which they outsource
This table compares common promptfoo upgrade tasks against who usually owns them, along with the skills each one needs. Read each row as a split between work that depends on domain knowledge and work that depends on platform operations, then check which skills your own team already has. The main takeaway is that assertion upkeep usually stays in-house, while runtime, patching and upgrade rehearsal are the tasks most often handed to a partner when staff are thin.
| Task | Usually owned by | Skills needed | Outsource when |
|---|---|---|---|
| Keeping eval assertions current | In-house eval or ML team | LLM evaluation methods, promptfoo configuration, knowledge of the application's expected outputs | Rarely; a partner can help rewrite suites but the criteria must come from your domain experts |
| Pinning and CI policy | Shared: engineering and platform teams | CI pipeline authoring, package version pinning, lockfile and release review | Pipeline standards are missing or every team pins differently |
| Node.js runtime and build image changes | Platform engineering | Node.js operations, container image builds, dependency management | The image pipeline is undocumented or the Node.js minimum for a release changes faster than the team tracks it |
| Self-hosted server patching and backups | Platform or infrastructure team | Container and Kubernetes operations, database backup and restore, patch management | No one owns the server on call, or backups have never been restored in a test |
| Red team probe planning | Security team | Threat modeling, OWASP LLM Top 10 and NIST AI RMF mapping, red team test design | The security team lacks LLM testing experience or the probe budget needs tuning across many applications |
| Rehearsing upgrades across versions | Often outsourced, with platform team sign-off | Staging environments, regression comparison of eval results, release note review, rollback planning | Internal staff are thin or the same team must also run production applications |
Where promptfoo upgrades usually go wrong
Most promptfoo upgrade problems do not come from the new release itself. They come from environments that drift apart, installs that float without a pin, and state that lives somewhere the upgrade process does not expect. Each card below names one of these failure points and the check that prevents it.
Node.js version drift across environments
promptfoo release 0.124.1, published on 8 October 2026, requires Node.js 22.22.0 or newer. Laptops, CI runners and container images often run different Node.js versions, so an eval that passes locally can fail in the pipeline or break after a base image update. Confirm the Node.js version in every environment against the minimum in the release notes, and pin it in the container image and CI configuration.
Unpinned installs that change results
If CI installs promptfoo without a version pin, a new release can alter eval behavior between two runs with identical configs and no code change. Lock the version in package files and lockfiles, and record the exact promptfoo version in every eval output so a score change can be traced to a tool change or a prompt change.
Assertion and report changes that break consumers
An upgrade can change how assertions are scored or how result files are structured. Dashboards, parsers and gating scripts that read those fields may then fail or misreport pass rates without any error from promptfoo. Before promoting a version, run a fixed reference suite on the old and new releases and diff the output files that downstream tools consume.
SQLite data lost during redeploys
The self-hosted promptfoo app stores data in a local SQLite database that cannot be shared across replicas and is not recommended for production. If the database file sits inside a container without a persistent volume, a redeploy or a Helm upgrade can remove eval history and shared results. Confirm where the file lives, mount persistent storage, and test a restore before the first upgrade.
Provider changes mistaken for tool regressions
A score drop after an upgrade is often caused by the model provider, not promptfoo. A vendor may have updated a model alias, changed a default parameter or retired a version. Before rolling back the tool, rerun the same suite against a pinned model version and record the provider and model identifiers in each run to separate the two causes.
Red team probes spent before the test window
The Community edition includes red teaming with 10k probes per month. Teams that run exploratory scans early in the month can exhaust that allowance before a planned test window, leaving no probes for the scheduled assessment. Agree on a probe budget with the test owner, reserve probes for the planned window, and track consumption weekly against the monthly limit.
What promptfoo support covers after handover
After handover, the choice is between a retainer that keeps the rollout current and a one-off upgrade that your own team runs. A retainer covers upgrades to new promptfoo releases, fixes to CI pipelines that break when the eval or red team configuration changes, and answers to questions about specific eval runs and red team results. A one-off upgrade fits a team that already runs promptfoo in its own pipelines and wants a single, documented move to a newer version with a clear rollback path. Neither option is a substitute for owning the eval suites. The retainer or upgrade scope should name which pipelines, configuration files and environments are included, so the work stays bounded.
Vendor support is a separate question from DeployOpen's services, and the two should not be confused. The promptfoo Community edition is free and includes community support. The promptfoo Enterprise edition adds priority support with SLAs, priced on request. The promptfoo On-Premise option runs the Enterprise functionality on your own infrastructure and includes a dedicated deployment engineer. The edition comparison, including probe limits and team features, is covered elsewhere on this site, so this section only addresses support. Confirm with promptfoo which edition or contract you hold before you rely on any support commitment.
Ask for response expectations in writing before you depend on them. For vendor support, request the response targets that apply to your edition and contract, and confirm whether they are SLAs or best-effort. For DeployOpen work, the written scope should state how requests are logged, who triages them, which hours apply, and how urgent pipeline breaks are escalated. Ask how a release that changes the Node.js requirement is handled. The npm release 0.124.1, published on 8 October 2026, requires Node.js 22.22.0 or newer, so runners and images need that runtime before an upgrade can pass. Agree on who checks that prerequisite and who approves a version change.
Plan for the risks that appear after handover rather than assuming the first deployment stays stable. Frequent releases can change defaults, providers or assertion behavior, so a version that passes today may produce different results next month. Pin the promptfoo version in CI, record the version used for each baseline eval, and keep a red team run history so a regression can be traced to a specific upgrade. A rollback procedure should be tested in a non-production pipeline before it is needed. Decide in advance which team owns the pinned version, who reviews a proposed bump, and what evidence must accompany it.
What the client must provide before an upgrade or support engagement starts
An upgrade or support engagement for promptfoo depends on access, existing artifacts, a set of decisions and named owners that the client supplies up front. Each item below either shortens the first working sprint or, when missing, pushes the start date and leaves risk unassigned.
CI system and repository access
Provide a service identity with read access to the repositories that hold promptfoo configs, eval suites and pipeline definitions, plus write access to a branch where version pins can be proposed. Confirm which CI system runs evals and whether runners can reach the model providers under test. Without this, we can only review configs by copy, and pin changes cannot be tested in the pipeline that matters.
Container registry and host access
Share the registry where promptfoo images are built or mirrored, and access to the self-hosted hosts or Kubernetes cluster that run the web app. Confirm whether Docker Compose or Helm is the deployment method in use. If the registry or cluster is unavailable, upgrade rehearsals run on a stand-in environment, and results may not match production behavior.
Read access to logs and run history
Grant read access to eval run logs, CI job output and application logs from the self-hosted server, including the SQLite database location and its backup status. These records show which releases ran, where failures began and whether a rollback has ever been needed. Without them, the first upgrade plan is built from the documentation alone and cannot show the team's actual failure history.
Current configs and eval suites
Provide the current promptfoo configuration files, test cases, assertions and any shared defaults in version control, with the exact promptfoo version each pipeline uses. Include custom providers and scripts that call internal APIs. Missing custom providers are the most common cause of surprises during a Node.js or promptfoo version change, because they depend on runtime behavior that the upgrade notes may not cover.
Stored baselines and red team reports
Share saved baseline results, red team reports and any exported findings that the team uses to judge regressions. Confirm the format and retention period for each. Without a baseline, an upgrade can change scores or probe results and nobody can say whether the change came from the model, the prompt or promptfoo itself.
Version, Node.js and freeze decisions
Decide the target promptfoo version, the minimum Node.js version the team will run, any change freeze windows and how much rollback is acceptable. The current npm release 0.124.1 requires Node.js 22.22.0 or newer, so the runtime floor must be confirmed before a target is chosen. If these decisions are open at kickoff, the scope and rollback plan cannot be written.
Named owners and approvers
Name a platform engineer who owns the deployment, an eval owner who signs off on assertion results, a security contact for red team findings, and the person who approves promotion to each environment. Without named owners, promotion decisions stall at the first failed eval, and support requests have no accountable contact.
Questions buyers ask about promptfoo upgrades and support
Can we upgrade promptfoo ourselves without a partner?
Yes, for a single local CLI on a developer machine, an upgrade is usually a package version change followed by a run of the existing suite to confirm nothing changed in your results. It gets harder when promptfoo runs as a self-hosted application or when many CI pipelines pin the same version, because one upgrade then touches shared images, configuration, stored data and every team that depends on the output. Ask yourself: who owns the pinned version, who tests it, and who rolls it back if a pipeline breaks. A partner is useful when those answers are unclear or when the upgrade has to be coordinated across environments.
What drives the cost and effort of a promptfoo upgrade?
Effort follows the number of places promptfoo is installed, how many test suites and custom providers depend on it, whether it runs as a self-hosted app with its own database, and how much regression evidence your team needs before approving the change. Custom assertions, scripted providers and red team configurations take more checking than plain prompt tests. Cost has a one-time part (planning, testing, fixing breaking changes) and a recurring part (watching releases, applying updates on a schedule). When requesting a quote, ask for the scope of environments, the test suites included and how regression results will be reviewed.
How long does a promptfoo upgrade take?
Duration is set in the written scope, and it depends on the deployment model, the number of environments and the size of the eval and red team suites that must be re-run and compared. A single developer CLI can be checked quickly, while a self-hosted instance serving several teams needs staging, data checks and a rollback plan. DeployOpen agrees timelines in writing before work starts, so ask for the milestones, the environments covered and the acceptance checks that close the work.
What do we need to provide for an upgrade or support engagement?
Expect to provide access to the environments in scope, the current promptfoo version and configuration files, the Node.js version used by your runners and images, representative eval suites with expected outputs, and a named owner who can approve changes. For a self-hosted deployment you also need the container or Helm setup and a staging copy of the data. Access to the model providers used in tests is needed to re-run suites, and you should confirm how provider API keys are stored and rotated before anyone touches them.
Does the Node.js requirement force us to change our platform?
Not necessarily. The current npm release requires Node.js 22.22.0 or newer, so any runner or container image that uses an older Node.js line must be updated before that release will install. Whether this is a small change or a platform change depends on what your CI images and build agents already run and whether other tools share them. Confirm the Node.js version on every runner and base image, then test the upgrade in one pipeline before changing shared images used by other teams.
Can support cover red team runs as well as evals?
Support can cover the promptfoo red team workflow, including configuration, probe settings, CI runs and interpretation of findings, as long as the scope names it. Red team runs use model API calls and generate results that need careful handling, so scope should state which frameworks are covered, such as the OWASP LLM Top 10, the NIST AI Risk Management Framework or the EU AI Act references in promptfoo's documentation, and who reviews findings. Confirm with the vendor whether your plan's probe allowance and features match the volume you intend to run.
What happens to results history during a self-hosted upgrade?
It depends on how the self-hosted instance stores data. The self-hosted app uses a local SQLite database that cannot be shared across replicas, so results history lives in that database file and must be backed up before any upgrade that changes the application or its schema. Before upgrading, confirm the database location, take a verified backup, run the upgrade against a copy in staging and check that historical runs still open and compare correctly. Ask the vendor for the documented migration steps for your exact version before scheduling the change.
How DeployOpen scopes, delivers and hands over promptfoo upgrades and support
DeployOpen plans and delivers promptfoo upgrades and support as fixed-scope work, with the scope, deliverables and timeline agreed in writing before any change is made. Ongoing support, upgrades and continuous testing are available as a retainer if your team wants a partner to keep the tool current after handover.
How we scope
- Inventory every promptfoo install, including local CLI use, CI/CD jobs and any self-hosted app, with its current version and Node.js runtime.
- Confirm the target promptfoo release and the Node.js version it requires, checked against the npm registry and the GitHub release notes at the time of work.
- Agree in writing which pipelines, eval suites and red team configurations are in scope, and which upgrade windows your change process allows.
How we build
- Pin the promptfoo version and Node.js version in CI configuration and lock files so every pipeline run uses the same tested toolchain.
- Run existing eval and red team suites against the new release in a staging environment and compare results with the current baseline before promotion.
- Document each provider, plugin and framework mapping that changed, such as OWASP LLM Top 10, NIST AI RMF or EU AI Act references, so reviewers can trace the impact.
How we hand over
- Deliver the pinned configuration, upgrade runbook and rollback steps as versioned documentation stored in your repository or change system.
- Walk your platform and security engineers through the upgrade procedure and the test evidence produced for each release.
- Record which model API keys, secrets and provider accounts the pipelines depend on, and confirm ownership and rotation responsibility with your team.
How we support
- Agree the support scope in writing, including which promptfoo versions, pipelines and environments are covered and how requests are logged.
- Review new promptfoo releases on a cadence set in the retainer and propose upgrades with test results and any breaking-change notes.
- Confirm with the vendor which support tier applies to your install, since community support differs from Enterprise priority support with SLAs.
