---
title: "Integrity Service Operations"
description: "Operational expectations for Integrity Service in customer deployments."
source: "Guardian Platform"
---
Integrity Service should be monitored as part of the full Guardian Platform deployment. It supports user-facing lineage, manifest, certificate, and credential-status workflows.

## Required Configuration Areas

- Auth Service integration when authentication is enabled.
- Platform database connection for durable records.
- Blob storage provider for stored artifacts.
- Signing keys, which Integrity Service does not hold itself: through Auth Service, it signs declaration and review statements with the caller's key, and certificates and status-list credentials with the platform key, so Auth Service key management must be healthy.

Supported blob storage providers include Azure Blob Storage, AWS S3, Google Cloud Storage, and local filesystem storage for non-production use.

## Configuration Reference

Integrity Service reads layered JSON config files, chosen by `RUST_ENVIRONMENT`, then applies environment variable overrides. The chart sets these for you; the reference below is for reading a rendered deployment or running the service directly.

| `RUST_ENVIRONMENT`     | Files merged, in order                                   |
| ---------------------- | -------------------------------------------------------- |
| `production` (default) | `config.base.json`, `config.json`                        |
| `staging`              | `config.base.json`, `config.json`, `config.staging.json` |
| `development`          | the staging files, then `config.development.json`        |
| any other name         | `config.base.json`, `config.<name>.json`                 |

Any variable named `INTEGRITY_APP__<path>` overrides a config key, with `__` separating nested keys: `INTEGRITY_APP__db__password` sets `db.password`.

| Key                 | Values                                                                                                                                    |
| ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| `port`              | `3050`                                                                                                                                    |
| `auth.type`         | `auth_service` (with `auth.url`) or `no_auth`                                                                                             |
| `blob_store.type`   | `azure_blob` (`account`, `key`, `container`), `aws_s3` (`region`, `bucket`, `folder`), `gcs` (`bucket`, `folder`), or `local_fs` (`path`) |
| `db.*`              | `user`, `password`, `host`, `db_name`, `port`, `ssl_mode`, `ssl_root_cert`                                                                |
| `logging.log_level` | Log levels per target; `RUST_LOG` overrides them                                                                                          |

AWS S3 reads `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` or the default credential chain, and Google Cloud Storage reads Application Default Credentials (`GOOGLE_APPLICATION_CREDENTIALS`). Logs are exported over OTLP when a standard `OTEL_*` exporter variable such as `OTEL_EXPORTER_OTLP_ENDPOINT` is set; `OTEL_LOGS_EXPORTER=none` turns export off.

## Operational Checks

- Service health.
- Connectivity to Auth Service when authentication is enabled.
- Database and blob storage availability.
- Signing and credential-status workflow health.
- Guardian lineage and credential views after deployment or upgrade.

The health endpoint reports that the process is running; it does not check the database or blob storage:

```bash
curl https://guardian.example.com/integrityService/health/v1
```

```json
{
  "status": "healthy",
  "service": "integrity-service",
  "timestamp": "2026-10-16T12:00:00Z",
  "version": "1.2.1",
  "uptime_seconds": 3600
}
```

## Backup and Restore

Back up Integrity Service data with the rest of the Guardian Platform. Restore database records, blob storage, secrets, and platform configuration together so lineage and credential workflows remain consistent.

## Related

- [Integrity Service Troubleshooting](./troubleshooting.mdx) — first-line checks when lineage, certificates, or blob storage fail
- [Key Configuration](../auth-service/key-configuration.mdx) — the Auth Service signing keys certificates depend on
- [Backup and Restore](../deployment/backup-and-restore.mdx) — the integrity database and rootstore backups, and the restore order
- [Chart Values](../deployment/chart-values.mdx) — where the blob storage provider is set in values.yaml
- [Observability](../deployment/observability.mdx) — platform-wide signals to monitor