Why NeMo Guardrails upgrades need regression testing before they ship
Yes, an upgrade across NeMo Guardrails 0.x releases needs a test-first process. Teams can handle it in-house if they already run regression suites for their LLM application, and many bring in a partner when they lack that test harness or cannot spare engineers to build one. The reason is simple: a 0.x version number signals that the project is still evolving, and the release notes for each version are where behavior changes are recorded. A rail that blocked a request under one version may pass it under the next, or the reverse.
The library is licensed under Apache 2.0 and developed in the NVIDIA-NeMo/Guardrails repository on GitHub, so every release, changelog entry and issue thread is public. That openness helps, but it also means the reader owns the job of reading them. Before planning any upgrade, pull the release notes for every version between your current pin and your target, and list each change that touches input rails, output rails, dialog rails, retrieval rails, execution rails, or the Colang parser and runtime your configuration depends on.
Upgrades are usually triggered by one of four things: a security fix, support for a newer Python version (the library currently supports Python 3.10 through 3.13), a new safety or moderation model that your team wants to use, or a bug fix that affects a rail you rely on. Each trigger carries a different urgency. A security fix may justify a faster schedule, while a new model may be optional. In every case the decision should be made against a written list of which rails, configurations and actions your application uses, so the regression tests cover what matters in production.
The v0.24.1 release, dated 16 September 2026 on the project's GitHub releases page, is a reference point for this guide, not a recommendation to pin that version. Confirm the current release notes and the latest version before you scope the work, because the version you plan to move to may have changed by the time you read this. Check the notes for breaking changes to configuration files, Python actions, and the handling of Colang 1.0 and 2.0 files, since those are the changes most likely to alter rail behavior without an obvious error.
Plan for the upgrade as a change to a safety control, not a dependency bump. Keep a baseline of how the current version handles a fixed set of benign and adversarial prompts, rerun that set on a staging copy of the new version, and review every difference in decisions before the release reaches users. Record who signs off on those differences. Teams that skip this step usually discover behavior changes from user reports or from blocked legitimate traffic after deployment.
What a NeMo Guardrails upgrade and support engagement includes
A NeMo Guardrails upgrade touches more than the library version: the config.yml, Colang files, Python actions and model providers all have to agree with the new release. The cards below follow the work in order, from inventory through production support, and the deliverables at the end are what the client keeps. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Current-state inventory
Before anything changes, we record what the deployment actually contains: the config.yml settings, every Colang file and which Colang version it uses, the Python actions and their dependencies, and each LLM or safety-model provider the rails call. Which rail types are active and which models they depend on determine how much of the system an upgrade can affect. Confirm with your team that the inventory matches what runs in production, not only what is in the repository.
Release-note and changelog review
We read the changelog and release notes for every version between your current pin and the target, looking for changes to rail behavior, Colang parsing, action interfaces and supported Python versions. NeMo Guardrails 0.x releases can change behavior, so this step identifies which of your flows and actions are exposed. The review output is a short list of affected areas that the upgrade plan and regression suite then address.
Upgrade plan
The plan sets the target version, the order of changes, the rollback point and the test gates each stage must pass. It also decides whether any Colang 1.0 configurations need conversion first, and it records which dependencies move together, such as the library and the LLM framework integration if your deployment uses it. Ask for the plan to be reviewed and signed off by your engineering owner before environment work begins.
Environment upgrades
We apply the planned change in development, staging and production order, using the same pinned dependency set in each environment. Checks cover the Python runtime, the server or Docker image if you run the guardrails server, and the secrets and provider endpoints each environment uses. Each environment is verified before the next one is touched, so a failure stays contained to the stage where it appeared.
Regression suite build and run
We build a regression suite that exercises each active rail type against representative inputs, including blocked and allowed cases for input, dialog, retrieval, execution and output rails. The suite runs before and after the upgrade so that any change in rail decisions is visible and reviewed rather than discovered in production. Ask who owns the expected outputs and how disagreements about them are resolved.
Production support after cutover
After cutover we monitor the deployment for the agreed support period, triage issues involving rails, providers or actions, and make fixes within the written scope. Support can be a one-time window or an ongoing retainer, depending on what you agree. Confirm the response expectations, escalation contacts and the boundary between support work and new feature requests before signing.
Handover deliverables
The engagement ends with an upgrade record, updated pinned dependencies, the regression suite, a runbook for operating and rolling back the deployment, and handover notes covering open risks. Your team should own these artifacts after the engagement closes, so ask that they live in your repository and that the runbook is tested by someone other than the author before handover is accepted.
What makes a NeMo Guardrails upgrade cost more or less
This table lists the factors that change how much regression testing, configuration work and evidence collection an upgrade needs, with the reason each one matters and how to keep it contained. Read each row against your own configuration, since the same upgrade can be small for one deployment and large for another.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Number of rails enabled | Each enabled input, dialog, retrieval, execution or output rail is a path whose behavior can shift between 0.x releases, so every enabled rail adds test cases to rerun. | Enable only the rails the risk assessment requires, and document which rail covers which threat so regression scope stays tied to real controls. |
| Custom Python actions | Actions called from rails are code your team owns, and API changes in the library can break them even when Colang files look unchanged. | Keep actions small and well tested, pin their dependencies, and maintain a list of which actions each rail calls. |
| Colang 1.0 versus 2.0 configurations | Colang 1.0 is the default, and configurations written for it may need conversion before a version or syntax change can be tested. Converted files still need manual review. | Settle the Colang version before the upgrade starts, and treat any conversion with nemoguardrails convert as a separate, reviewed change. |
| Number of LLM and safety-model providers | Each provider or safety model used by a rail has its own client settings, credentials and response formats, so a library change can affect several integrations at once. | Limit providers to those with a clear purpose, and record the model names and versions each rail calls. |
| LangChain use via the opt-in environment variable | LangChain integration is enabled only when NEMOGUARDRAILS_LLM_FRAMEWORK is set to langchain, so an upgrade must also cover that dependency chain when the variable is set. | Confirm whether the variable is set in each environment and test with the same setting used in production. |
| Number of environments | Each environment such as development, staging and production needs its own test run and configuration check, and drift between them makes failures harder to trace. | Keep environment settings in version control, and promote the same tested artifact through each environment. |
| Number of configurations served | A server that loads several configurations multiplies the regression suite, because each configuration can exercise different rails and models. | Group configurations that share rails, and run one shared suite plus targeted tests for each configuration. |
| Compliance evidence requirements | Assessors may ask for test results, change records and approval trails for each upgrade. The evidence needed depends on the framework your organization is assessed against. | Ask your assessor and auditor which records they expect, and set up test reports and change tickets in the upgrade process from the start. |
How a NeMo Guardrails upgrade runs from inventory to handover
The sequence turns an upgrade of NeMo Guardrails into a documented, tested change with a known behavior baseline, a rehearsed rollback, and a defined support window after cutover. Each phase closes with a written output that the next phase depends on.
Inventory the current deployment and capture a baseline
We record the installed nemoguardrails version, the deployment form (Python library, guardrails server, Docker image or the NeMo Guardrails microservice), the config.yml files, Colang files, custom Python actions, LLM and safety-model endpoints, and the configuration of any LangChain integration. We then capture sample conversations and the current responses, including which rails fire and which requests are blocked. The output is a baseline inventory and a set of recorded outputs that the upgrade will be measured against. It is done when your team has signed off that the inventory matches what runs in production.
Assess the release notes against the target version
We read the release notes and changelog for every version between your current release and the target, and we mark the changes that can alter rail behavior, configuration syntax, action interfaces or dependencies. Releases in the 0.x series can change behavior, so each item is classified as no effect, needs test, or needs code or configuration change. The output is a written assessment that names the target version and lists each change that touches your deployment. It is done when every item has a classification and an owner.
Check dependencies and Python compatibility
We confirm that the target release supports the Python interpreter in use. NeMo Guardrails supports Python 3.10, 3.11, 3.12 and 3.13, so any runtime outside that range must be upgraded first. We then resolve the dependency tree in a clean environment, check pinned packages for conflicts with the LLM client libraries, and confirm the Docker base image if containers are used. The output is a locked dependency manifest and a list of any runtime changes the platform team must make. It is done when a clean install succeeds in a build environment that matches production.
Build the regression suite for the rails
We turn the baseline conversations into a regression suite that covers each rail type in use: input, dialog, retrieval, execution and output rails. The suite includes expected allowed responses, expected blocks, and the jailbreak and injection cases your risk owner requires. Where a rail depends on a model call, we record which model and version the test uses so results can be compared. The output is a versioned test set with pass criteria and a runner your team can rerun. It is done when the suite passes against the current production version, which confirms the tests reflect today's behavior.
Upgrade staging and run the regression suite
We install the target version in a staging environment that mirrors production configuration, secrets handling and network paths to the LLM and safety-model endpoints. We then run the regression suite, load test the path your traffic uses, and record every difference from the baseline. Latency and model-call counts are recorded alongside responses because a change in rail logic can alter both. The output is a test report listing passes, failures and differences. It is done when every failure is either fixed or accepted in writing by the rails owner.
Review behavior differences with the rails owner
We walk the rails owner through each difference that the regression run exposed, with the input, the old response, the new response and the rail that produced it. The owner decides whether the change is an improvement, an accepted trade-off or a defect to fix before cutover. Where configurations need migration work, such as Colang syntax changes, we document the edits and flag any that need manual review. The output is a signed-off difference register and an updated configuration set. It is done when no open item remains without a decision.
Cut over to production with a tested rollback
We schedule the production change with your change process, deploy the approved version and configuration, and run the post-deployment smoke tests from the regression suite. The rollback plan is written before the change: it names the previous image or package, the previous configuration, and the steps and owner to restore them. We rehearse the rollback in staging so the steps are known to work. The output is a production change record with smoke test results and a confirmed rollback path. It is done when the smoke tests pass and monitoring shows the expected block and allow rates.
Hand over and run the post-upgrade support window
After cutover we monitor the logs for blocked and allowed requests, compare them against the baseline, and investigate anomalies with your team. We deliver the updated runbook, the regression suite, the difference register and the configuration record, and we walk your operators through them. Any support period after cutover is agreed in writing before work starts, and its scope and end point are stated in that agreement. The output is a handover pack and a closed support log. It is done when your team confirms it can run the suite and the rollback without us.
How regression testing catches rail behavior changes before production
A NeMo Guardrails upgrade can leave every configuration loading cleanly and still change what the rails do. The config.yml file, Colang files and Python actions may parse without error while an input moderation rail blocks a message it used to pass, a dialog flow takes a different branch, a retrieval rail filters out chunks it previously kept, or an execution rail behaves differently when a custom action returns an unexpected value. Load success tells you the configuration is valid. It does not tell you the guardrails still enforce the policy you approved. Regression testing is the only reliable way to find these shifts before users do.
Build the test set per rail type rather than as one general suite. The five rail types in NeMo Guardrails are input rails, dialog rails, retrieval rails for RAG chunks, execution rails for custom actions and tools, and output rails, and each fails in its own way. For each one, write a fixed set of conversations that cover the cases your policy cares about: messages that must be blocked, messages that must pass, borderline requests, and multi-turn flows that exercise a dialog path. Record the expected outcome for every turn, including the rail that fired, the response returned and any action invoked. Store the set in version control next to the configuration so every change to rails and every upgrade is tested against the same baseline.
Run the identical set twice, once on the currently deployed version and once on the target version, using the same configuration folder, the same model endpoints and the same action code. Keep everything constant except the library version so that differences can be attributed to the upgrade. Export the results and review the diffs by rail type. Treat each changed outcome as one of three things: an intended improvement that you should document and accept, an unintended regression that blocks the upgrade, or a test that is no longer accurate and needs updating. Review the Colang 2 migration separately if your target involves a Colang change, because that work is covered on its own page and should not be mixed into a version-only comparison. Confirm the target release details in the NVIDIA-NeMo/Guardrails releases page before you pin a version, and confirm supported Python versions for your runtime.
Model-based checks need different handling because their outputs can vary between runs even on an unchanged version. Self-check input and output moderation, fact-checking, hallucination detection, and jailbreak and injection detection depend on model judgments, so an exact string match will produce false failures. Instead, assert on the decision and on a score or threshold you have set for each check, and run each conversation several times to observe the spread of results. Where a single case flips between runs, record the variance as a finding rather than forcing a pass. Add a sampled human review of a fixed proportion of these outcomes, and agree in advance on the sample size and who reviews. Ask your implementation partner and internal owners to document which thresholds were chosen and why, since changing a threshold during an upgrade is itself a behavior change that must appear in the diff.
Which NeMo Guardrails upgrade tasks teams keep in-house and which they outsource
This table compares each recurring upgrade and support task for NeMo Guardrails with the usual owner, in-house or outsourced, and the skills the work requires. Read it as a checklist: tasks marked in-house are the ones most teams can absorb, and tasks marked outsourced are where a partner adds the most leverage during a release change. Teams with a Python platform owner and a test automation engineer can often keep most of this work in-house, and the rows below show where a partner still adds value.
| Task | Usually in-house or outsourced | Skills required |
|---|---|---|
| Owning rail policy and expected refusals | In-house. Product and risk owners set what must be blocked, and this decision should never leave the organization. | Product or risk ownership, Colang or config.yml familiarity, domain knowledge of prohibited content |
| Approving behavior diffs | In-house. The owner signs off on changed refusals and answers after each upgrade. | Review discipline, understanding of guardrail intent, ability to judge changed model-driven outputs |
| Python dependency management | In-house for most teams. A partner can help where the pinned stack is complex. | Python packaging, virtual environments, supported Python version checks (3.10 to 3.13) |
| Building the regression suite | Often in-house, with partner help on coverage. Gaps usually appear in jailbreak and injection cases. | Test automation, prompt test design, adversarial input knowledge, CI integration |
| Running staging upgrades | Shared. The internal team runs the upgrade, and a partner can run it when staging capacity or time is limited. | Deployment automation, container or server operations, release tooling |
| Production change windows | In-house. The organization controls its own change calendar and rollback approval. | Change management, rollback planning, on-call coordination |
| Incident response for blocked or leaked responses | Often outsourced in part. A partner adds forensic review of rail traces and fast triage when the cause is unclear. | Log analysis, LLM application debugging, security incident handling |
| Monitoring of guardrail latency | In-house. Latency is measured against the organization's own traffic and model calls. | Observability tooling, metrics design, capacity planning for added safety-model calls |
What usually breaks during NeMo Guardrails upgrades and how to prevent it
NeMo Guardrails configurations depend on the library version, the model behind each rail, and the custom code that runs alongside it. Most upgrade problems come from one of these moving without the others being tested, so the cards below pair each failure with the check that catches it before production.
Unpinned dependencies pull in new releases
If the nemoguardrails package is installed with a loose version range, a rebuild can pick up a newer release without anyone approving it. Pin the exact version in your lock file and in the container image, and make every change to that pin a reviewed change. Check the release for your Python version (3.10 to 3.13 are supported) before you raise the pin, since the runtime and the library move together.
Behavior changes that pass validation
A configuration can load cleanly and still refuse different requests after an upgrade, because the library changed how a rail evaluates input or output. Schema validation will not catch this. Read the release notes for 0.x versions for behavior changes, not only for new features, and treat any changed default as a reason to rerun your refusal test cases.
Drift between dev, staging and production
Teams often edit config.yml, Colang files or Python actions directly on a server, so production stops matching the reviewed repository. Keep all configurations in version control, deploy them from the same artifact through each environment, and compare the deployed files against the tagged commit as part of each release. Environment-specific values such as endpoints should come from settings, not from edited files.
Model and safety-model changes in the same window
When a library upgrade and a change to the underlying LLM or a safety model happen together, a regression cannot be attributed to either one. Schedule them separately. Record the model name and version used by each self-check, moderation and topic safety rail, and test the library upgrade against the current models before changing any of them.
Custom actions broken by API changes
Python actions and execution rails call into your own code and sometimes into framework interfaces, and those signatures can change between releases. Give each custom action its own unit tests, and run them against the new version in a clean environment. Confirm the rail still triggers the action with the arguments it expects, not only that the action imports.
No tested rollback path
Without a documented way back, a failed upgrade turns into an outage while the team debugs. Keep the previous image and configuration artifact available, record which configuration version each running server uses, and rehearse the rollback in staging. Confirm that a rollback also restores the model and safety-model settings that were in effect before the upgrade.
Regression suites that test only happy paths
Test sets built from ordinary questions confirm that allowed traffic still passes, but they miss the cases guardrails exist for. Include blocked prompts, jailbreak and injection attempts, off-topic requests, and retrieval chunks that should be filtered. Log the expected outcome for each case so a changed refusal shows up as a failed test rather than a surprise in production.
What NeMo Guardrails support costs after go-live
After go-live, the cost of a NeMo Guardrails deployment is mostly recurring, and it is easy to underestimate because the library itself is free under the Apache 2.0 license. The license covers the software, not the running system. Budget owners should separate the one-time upgrade and regression work from the ongoing cost of keeping rails healthy in production, then ask a partner to price each line separately so the two are not blended into one number.
The first recurring line is compute. If you run the library inside your own service, the guardrails add work to every request path, and if you run the guardrails server or the NeMo Guardrails microservice, you pay for the container hosting, scaling headroom and the Kubernetes and Helm operations that come with it. The second line is model calls. Self-check input and output moderation, fact-checking, hallucination detection and the content safety and topic safety models each can call an LLM or a safety model on every request, so the per-request count of those calls is a direct driver of spend. Confirm with your platform team which rails are active on each route, because a rail added for one use case often runs on all traffic.
The third line is people. Someone must watch blocked-request logs, tune thresholds, review false positives with product owners and respond when a rail misbehaves. Those hours sit on your internal on-call and review rota, and they recur for as long as the application runs. Regression suite maintenance is a related recurring cost: test prompts, expected dialog outcomes and Colang flows need updating when business rules change, and that work is needed even in quiet months. Ask who owns those tests and whether the suite is kept in your repository.
Upgrades form a separate, periodic cost. NeMo Guardrails releases move quickly, and the project is still on 0.x versions, where behavior can change between releases. Each upgrade cycle carries a one-time cost to review release notes, run the regression suite against the new version, and fix rails that changed behavior. Retainer-based support spreads some of this across the year, covering triage, patch review and upgrade cycles on an agreed cadence. A retainer does not remove internal review, because someone on your side still signs off on behavior changes that affect users.
When requesting a quote, ask for these items in writing: the scope of support hours and what falls outside them, response expectations agreed in writing with severity definitions, the upgrade cadence and how many version moves per year are included, and who owns the regression test suite after handover. DeployOpen does not publish a price list, and quotes follow from the written scope, so the clearer the scope in your request, the more directly the quote maps to the cost drivers above. Confirm current release details against the NVIDIA-NeMo/Guardrails release notes before you set an upgrade cadence.
How NeMo Guardrails upgrades differ by deployment model
When NeMo Guardrails runs as a Python library inside your application, the upgrade is a dependency change that travels through your normal release process. The rails execute in the same process as the application, so a new package version changes application behavior as soon as the service restarts on the new build. Your lockfile and release notes define what you actually run.
- Pin the exact version: Record the nemoguardrails version and the Python interpreter. Supported interpreters are 3.10, 3.11, 3.12 and 3.13.
- Validate configurations: Load every config.yml, Colang file and Python action against the target version before any traffic reaches it.
- Replay prompts: Run your approved prompt set through old and new versions and compare allow, block and modify outcomes.
- Check model calls: Confirm that the self-check, moderation and safety-model calls still resolve with the same credentials and endpoints.
The client provides the test prompt corpus, the approved baseline outcomes, the application's build environment and an owner for the release. Review the lockfile diff and the release notes for every 0.x version between your current and target versions before merging.
When NeMo Guardrails runs as a guardrails server or from a Docker image in front of your LLM, the upgrade changes the image that serves traffic, not just a library in an application. The server loads a folder of configurations at startup, so a new version can change how those files are interpreted. Calling services see the HTTP API as their contract, which makes response handling the first thing to test.
- Rebuild from a pinned version: Build a new image from the Dockerfile with an explicit version tag, and keep the previous tag available for rollback.
- Confirm configuration loading: Start the new image against the same configuration folder and check for load errors and warnings.
- Test the HTTP contract: Verify request and response shapes, error codes and timeouts for every calling service.
- Compare outcomes: Replay approved requests against the old and new images and review every difference in block or modify decisions.
The client provides container registry access, the configuration folder under version control, a list of calling services with their owners, and a staging endpoint that matches production routing. Server setup and multi-configuration management are covered in the server deployment topic, and endpoint protection is covered in the security hardening topic.
The NVIDIA NeMo Guardrails microservice is a production container built on the same configuration model and deployed on Kubernetes with Helm. An upgrade typically changes the image tag, the chart and the values file together, so the change set is larger than a library bump. Teams should treat chart values as part of the configuration under test, not as a deployment detail.
- Diff the chart and values: Compare the chart version and default values between releases, then reconcile your overrides against them.
- Confirm image and chart pairing: Check the release notes to see whether the chart and image versions must move together. Confirm this with NVIDIA for your release.
- Run a staging rollout: Deploy to a non-production namespace with production-like policies, resource limits and secrets.
- Check readiness and rollback: Test health probes, rolling update behavior and a Helm rollback to the previous revision.
The client provides cluster access, staging namespaces, the values files used in each environment, registry credentials for the microservice image and the monitoring stack that will observe the release. Confirm the access terms for the microservice image with NVIDIA before planning the upgrade window.
LangChain integration in NeMo Guardrails is opt-in. It is enabled by setting the NEMOGUARDRAILS_LLM_FRAMEWORK environment variable to langchain. An upgrade can change behavior in two ways: the version of NeMo Guardrails, and whether the flag is set and where. Both must be tested, because a missing or inconsistent flag changes which code path handles LLM calls.
- Record the flag state: Document where NEMOGUARDRAILS_LLM_FRAMEWORK is set, including every replica, container, job and developer environment.
- Test both states: Run the regression suite with the flag enabled and disabled where your configuration depends on either path.
- Pin LangChain separately: Treat the LangChain package as its own dependency with its own version pin, and confirm compatibility with the target NeMo Guardrails release.
- Review model wiring: Verify that model providers, parameters and callbacks behave the same after the upgrade.
The client provides the LangChain versions in use, the deployment manifests or scripts that set the variable, and a list of environments where it must match. Confirm the supported LangChain range for your target release against the NeMo Guardrails documentation before scheduling the change.
In air-gapped or restricted networks, an upgrade depends on what you can bring inside the boundary. Python packages, container images, Helm charts and model artifacts must all be obtained outside, verified and transferred through your approved process. Model access is often the hardest part, because the self-check, fact-checking, hallucination and safety-model features may call models that must be available locally.
- Mirror dependencies: Stage the nemoguardrails package, its transitive dependencies and the required container images in an internal mirror or registry.
- Stage model artifacts: Confirm which safety and checking models your configuration calls and make sure each one is available offline, with its license reviewed.
- Install on a clean host: Build the environment from the internal mirror only, with no outbound access, and confirm it starts.
- Run the regression suite offline: Execute the full test set inside the isolated network, including any model calls that previously used external endpoints.
The client provides an internal package mirror, a container registry, approved transfer media and process, model artifacts and a test environment that matches production network restrictions. Confirm with your security team how release artifacts are verified before they enter the boundary, and allow time for the transfer approval process in the upgrade plan.
How much effort and cost does a NeMo Guardrails upgrade involve?
How long does a NeMo Guardrails upgrade take?
The duration depends on how far the upgrade moves and how much of your configuration it touches. NeMo Guardrails 0.x releases can change behavior, so the number of rails, Colang files, Python actions and model-based checks in use drives the work more than the version number alone. Your installed version and the target release, such as v0.24.1 (released 16 September 2026), set the size of the gap to review. Before accepting any timeline, ask for an inventory of rails and a regression run plan. Read the release notes on the project's GitHub releases page to see which behavior changes apply to your configuration.
Can our own team upgrade NeMo Guardrails without a partner?
Yes, if your team can own the testing. The library is Apache 2.0 licensed, so you can upgrade it in your own environment without asking permission. The hard part is proving that each rail still blocks, allows and routes the way it did before. Teams that have clear test cases for every input rail, output rail and dialog flow, a staging environment that mirrors production, and an engineer who understands Colang can usually run the upgrade in-house. Teams without that test coverage tend to find out about regressions from users, which is the main reason to bring in outside help.
What does an upgrade need from our team?
The upgrade needs access and time from people who know the guardrails. Config access means the repository holding config.yml, Colang files and Python actions. Sample traffic means representative prompts and responses, including blocked requests, so the regression suite reflects real use. Rail owners are the people who can confirm what each rail should do, such as which topics are off limits or which retrieval chunks must be filtered. A staging environment should run the same model providers, safety-model settings and server or library setup as production. Missing any of these usually adds time because the team has to reconstruct intended behavior during testing.
How is regression testing handled for model-based rails?
Model-based rails need tests that accept some variation in output while still catching behavior changes. NeMo Guardrails includes self-check moderation, fact-checking, hallucination detection, content safety and topic safety models, and jailbreak or injection detection. A regression suite should pin the inputs and expected decisions for each rail, then record which model versions and safety-model calls were used. Where a check depends on an LLM judgment, define pass criteria as thresholds or labeled examples rather than exact text matches. Expect to rerun the suite after any change to the underlying model, not only after a NeMo Guardrails version change.
Can a partner take over NeMo Guardrails support?
A partner can take over support for the platform if the handover covers the configuration, the tests and the operating runbook. DeployOpen plans, implements, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and ongoing support is available as a retainer. The handover normally needs a written inventory of rails and actions, the regression suite with its expected results, access to logs for blocked requests, and a named owner on your side for decisions about intended behavior. Support scope should state who responds to incidents, who approves changes to rails and how upgrades are scheduled.
Is a NeMo Guardrails upgrade offered as fixed scope?
Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. For an upgrade, the scope usually names the current and target versions, the rails and actions in use, the test cases to be written or extended, the staging and production steps, and the documentation handed over at the end. Changes found during testing that fall outside that scope are typically handled as a separate written change. Ask for the list of excluded items, such as new rails, Colang migration or microservice work, so the boundary is clear before signing.
What does the Apache 2.0 license mean for upgrade rights?
The Apache 2.0 license lets you use, modify and redistribute the NeMo Guardrails library, including upgrading it inside your own environment, subject to its license terms. It does not decide how much effort an upgrade takes or who is responsible for behavior changes. The license covers the code, while NVIDIA also offers a separate NeMo Guardrails microservice, a production container image deployed on Kubernetes with Helm, that is built on the same configuration model. Confirm with your legal team which license terms apply to any container image or model you deploy alongside the library, and check the license text in the project repository.
What should we ask for in a NeMo Guardrails upgrade quote?
Ask for a quote that follows from a written scope and separates one-time work from recurring work. One-time items usually include the current-state inventory, the upgrade plan, test case writing, staging validation, production cutover and handover documentation. Recurring items include support, scheduled upgrades and continuous testing if you choose a retainer. Ask which versions are in scope, how many rails and custom actions are covered, what sample traffic and environment access you must provide, and how model-based checks are tested. Ask who pays for model or safety-model calls during testing, and request the exclusions in writing. DeployOpen does not publish a price list, so the quote is the basis for comparison.
How DeployOpen scopes, delivers and supports NeMo Guardrails upgrades
DeployOpen plans and delivers NeMo Guardrails upgrades inside your own infrastructure, starting from a written scope that names the releases, configurations and rails in play. Each upgrade is tested against your existing rails before cutover, and the work ends with documentation and handover so your team can run guardrails in production.
How we scope
- Inventory current NeMo Guardrails version, Python runtime, config.yml files, Colang files and custom actions.
- Identify which Colang version each configuration uses and whether a migration is part of the upgrade.
- Agree in writing which rails, release targets, environments and test cases are covered before work starts.
How we build
- Pin the target nemoguardrails release and rebuild the environment, checking supported Python versions first.
- Build a regression suite covering input, dialog, retrieval, execution and output rails against recorded prompts.
- Compare blocked, allowed and rewritten responses between old and new versions and review every behavior change.
How we hand over
- Deliver a written change record listing each behavior difference, the fix applied and the tests that verify it.
- Document the upgrade procedure, rollback steps and configuration changes for your platform team to repeat.
- Walk through the regression suite and runbook with the engineers who will own guardrails after the engagement.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope upgrade closes.
- Re-run the regression suite when new NeMo Guardrails releases are published, so changes are reviewed before adoption.
- Confirm with your team which deployment model, library or microservice, your support terms should cover.
