Migrating to 0.11.0 - Guardrails AI

Summary

Guardrails 0.11.0 changes how validators are installed and begins the sunset of Guardrails-hosted remote inference. Nothing breaks the moment you upgrade — the guardrails hub CLI and the guardrails.hub import shim keep working during the deprecation window — but you should migrate to the patterns below. The final cutoff for the retired registry and the hosted inference endpoints is August 6, 2026.

Validators now install from PyPI

guardrails hub install and the private validator registry are being retired (final cutoff August 6, 2026). Validators are now standard PyPI packages named guardrails-ai-<name>, installed with pip or uv:

- guardrails hub install hub://guardrails/detect_pii
+ pip install guardrails-ai-detect-pii

Update imports to the guardrails_ai namespace. The registered validator name is unchanged, so Guard().use(...) and any RAIL format="guardrails/..." keep working — only the import path changes:

- from guardrails.hub import DetectPII
+ from guardrails_ai.detect_pii import DetectPII

No guardrails configure / API key is required to install validators anymore — they are public packages published on PyPI under the guardrails-ai- prefix.

`guardrails create` and the template registry are being retired

The guardrails create CLI command and the hub:template://… template registry are being retired on the same August 6, 2026 cutoff. To create a Guard, install the validator(s) you need from PyPI and define the Guard yourself in config.py:

pip install guardrails-ai-gibberish-text

# config.py
from guardrails import Guard
from guardrails_ai.gibberish_text import GibberishText

guard = Guard(name="gibberish_guard").use(GibberishText(on_fail="exception"))

Guardrails-hosted remote inference is being discontinued

Some validators could run their ML models on Guardrails’ hosted inference servers. Those servers are shut down on August 6, 2026. Switch to one of:

Run the model locally — pass use_local=True when constructing the validator:
guard = Guard().use(DetectPII(use_local=True))
Host your own endpoint and point the validator at it via validation_endpoint=.... See Remote Validation Inference.

Guardrails Server (`guardrails-api`)

The Guardrails Server picks up two changes from the hub retirement.

Docker and CI builds no longer need `GUARDRAILS_TOKEN`

Because validators are now public PyPI packages, Dockerfiles and CI pipelines can drop the GUARDRAILS_TOKEN build arg / secret and the guardrails configure step. Replace guardrails hub install hub://guardrails/<name> with a plain pip install:

- RUN --mount=type=secret,id=GUARDRAILS_TOKEN,env=GUARDRAILS_TOKEN \
-     guardrails configure --enable-metrics --enable-remote-inferencing --token $GUARDRAILS_TOKEN
- RUN guardrails hub install hub://guardrails/detect_pii
+ RUN pip install guardrails-ai-detect-pii

PostgreSQL backend: import validators in `config.py` for registration

If you run the server against a PostgreSQL database, guards live in the database and are not seeded from config.py. Validators are now standard PyPI packages, and their classes only register with the Guardrails process when their module is imported. In in-memory mode this happens naturally because config.py imports each validator to build a Guard. In DB mode you must now import each validator explicitly in config.py so it is registered and can be referenced by guards created via the API:

# config.py — DB mode
from guardrails_ai.detect_pii import DetectPII  # noqa: F401 — imported for validator registration
from guardrails_ai.competitor_check import CompetitorCheck  # noqa: F401

​Summary

​Validators now install from PyPI

​guardrails create and the template registry are being retired

​Guardrails-hosted remote inference is being discontinued

​Guardrails Server (guardrails-api)

​Docker and CI builds no longer need GUARDRAILS_TOKEN

​PostgreSQL backend: import validators in config.py for registration