Guardrails Configuration Store#

A guardrail configuration specifies information such as the models, model endpoints, and the checks to apply to input and output. In each Guardrails inference request, you can specify the configuration by providing the configuration ID.

The configuration store is a database that contains the guardrail configurations you create. The microservice uses the store for storing the guardrail configurations.

The NeMo Guardrails microservice supports three storage backends for the guardrail configuration store.

PostgreSQL Database: This is the default option.
External PostgreSQL Database: This is an option for an existing database infrastructure and is recommended for production deployments.
NFS Storage: This is an option for file-based storage requirements.

Each option provides different benefits and trade-offs in terms of scalability, reliability, and ease of management.

Set Up PostgreSQL for Guardrails Configuration Store#

While deploying the service on Kubernetes, you can either use the default PostgreSQL or configure an external production-grade PostgreSQL. To learn more about setting up PostgreSQL for the NeMo microservices in general, refer to PostgreSQL.

Option 1: Default PostgreSQL#

The default PostgreSQL is automatically provisioned and managed by the Helm chart. The NeMo Microservices Helm Chart uses the Bitnami PostgreSQL chart to deploy a PostgreSQL database.

guardrails:
  postgresql:
    enabled: true

Option 2: External PostgreSQL (Recommended for Production)#

Use an external PostgreSQL database for production deployments, especially when you need high availability, have an existing database infrastructure, or need to meet compliance requirements.

guardrails:
  postgresql:
    enabled: false
  externalDatabase:
    host: <your-host-name>
    port: <your-port>
    database: guardrails_api
    user: guardrails_api
    existingSecret: <your-guardrails-db-creds-secret-name>
    existingSecretPasswordKey: <your-password-key>

The following pages provide more information on additional configurations that you might need to configure for the external PostgreSQL database.

Option 3: NFS Storage (Alternative to Database)#

Use NFS storage when you need file-based persistence or cannot use PostgreSQL. This option stores configurations as files in a shared filesystem. The following is the default configuration in the values.yaml file:

guardrails:
  configStore:
    nfs:
      enabled: false
      path: "/path/to/nfs/share"
      server: "nfs-server.example.com"
      mountPath: "/config-store"
      storageClass: "standard"
  env:
    CONFIG_STORE_PATH: "/app/services/guardrails/config-store"

Make sure the configStore.nfs.path key references the root of the configuration store directory–which is the directory containing subfolders for each individual guardrail configuration.

Environment Variable Configuration#

Configure the configuration store path and related settings through environment variables. The following are the default values in the values.yaml file:

guardrails:
  env:
    CONFIG_STORE_PATH: "/app/services/guardrails/config-store"
    DEMO: "True"
    DEFAULT_CONFIG_ID: self-check

Demo Configurations#

The NeMo Guardrails microservice includes a default guardrails configuration store pre-populated with three configurations.

When you start the microservice with the DEMO environment variable set to True, which is the default value, the guardrails configuration store is initialized with the following three configurations.

default: This is an empty guardrail configuration, useful for testing the connectivity to the LLM.
self-check: This is a demo guardrail configuration using a simple self-check input rail. For more details, check out the Self Check Input section in the NeMo Guardrails toolkit documentation.
abc: This configures the ABC Bot in the NeMo Guardrails toolkit. The bot answers questions about the ABC company employee handbook.

The microservice adds a separate directory for each configuration to the locally accessible directory for the configuration store. For the demo configurations, the layout is as follows:

/config-store
├── abc
│   ├── rails
│   │   └── disallowed.co
│   ├── kb
│   │   └── employee-handbook.md
│   ├── prompts.yml
│   └── config.yml
├── default
│   └── config.yml
└── self-check
    └── config.yml

With the default DEFAULT_CONFIG_ID set to self-check, the NeMo Guardrails microservice uses the self-check configuration.