> For the complete documentation index, see [llms.txt](https://docs.nullify.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nullify.ai/configuration/configuration-general.md).

# General Configuration

## Overview

Once installed, Nullify immediately starts assessing pull requests and creating findings for new risks. The defaults get most teams moving quickly, and you tailor behaviour from the Nullify dashboard (with an equivalent admin API for automation). Configuration no longer lives in a checked-in file — every setting is managed centrally per tenant.

## Where settings live

| Setting                                       | Dashboard                     | API                                                  |
| --------------------------------------------- | ----------------------------- | ---------------------------------------------------- |
| CI / PR gate (fail build, enable PR reviews)  | **Configure → Pull Requests** | `PUT /admin/pr-gate-settings`                        |
| Ticket creation thresholds (per finding type) | **Configure → Ticketing**     | `POST /admin/ticketing/settings/{findingType}`       |
| SLA policies                                  | **Configure → Ticketing**     | `POST /admin/sla`                                    |
| Notification destinations + event filters     | **Configure → Connectors**    | `PUT /admin/integrations/notifications`              |
| Ignore / allowlist a finding                  | Per-finding in the dashboard  | `POST /{service}/.../findings/{findingId}/allowlist` |

### Pull request gate

Control whether the Nullify check can fail CI when a pull request introduces a new finding, the priority threshold that fails it, and whether Nullify may submit an approving review. These live on **Configure → Pull Requests** (`PUT /admin/pr-gate-settings`).

`PUT /admin/pr-gate-settings` fields:

* `enabled` — fail the Nullify check when the PR introduces a finding at or above the threshold.
* `min_priority` — the lowest priority that fails the check. Accepts `URGENT` or `IMPORTANT` only.
* `allow_approving_reviews` — allow Nullify to submit an approving review on a pull request that has no blocking findings (off by default).
* `allow_request_changes_reviews` — allow Nullify to submit a request-changes review when it has a blocking security concern (off by default).

See [Pull Request Configuration](/configuration/configuration-pull-requests.md) for the full behaviour of each setting.

### Ticketing thresholds and SLAs

Ticket auto-creation is **off by default** for every finding type until you enable it per type from **Configure → Ticketing** (`POST /admin/ticketing/settings/{findingType}`). Once enabled, a ticket is created when a finding meets both the configured severity and priority thresholds.

Default thresholds once enabled:

* Priority default: **IMPORTANT** (and Nullify never auto-creates tickets below IMPORTANT, regardless of the threshold).
* Severity default: no floor.

SLA policies (time-to-remediate targets per priority) are set with `POST /admin/sla`. Valid priority labels are `URGENT`, `IMPORTANT`, `MEDIUM`, `INFORMATIONAL`, `LOW`, `NEGLIGIBLE`, `FALSE_POSITIVE`, and `UNKNOWN`.

### Notifications

Notification destinations and the events that trigger them are managed from **Configure → Connectors** (`PUT /admin/integrations/notifications`). Nullify supports three destination types, each pairable with an event filter:

* **Slack** and **Microsoft Teams** — post escalations and updates to a channel or DM.
* **Email** — deliver notifications to an address.
* **Outbound webhook** — POST notification events to an HTTPS endpoint you control.

### Allowlisting findings

There is no file-based or static ignore list. Suppress a finding per-finding from the dashboard or via the service allowlist endpoint, e.g. `POST /sast/findings/{findingId}/allowlist`. See the per-service configuration pages for the exact paths.

## Autofix pull request limits

Autofix volume is fixed platform behaviour and is not configurable:

* **3** open Nullify pull requests per repository at a time.
* **5** new pull requests per remediation plan.

Issue dashboards are generated automatically from finding counts; there is no toggle to enable them.

## Document ingestion (Memory Vault)

Nullify automatically ingests organisational documents committed to your platform's private configuration repository into the Memory Vault. Depending on your platform this repository is:

* GitHub: `.github-private`
* Bitbucket: `.nullify`
* Azure DevOps: `.azure-private`

The repository should remain private and accessible to the Nullify app. On every push, eligible files are uploaded to the vault and fed to the onboarding agent to build organisational context (security posture, escalation matrices, compliance controls) that informs vulnerability prioritisation.

Eligible file types:

* Markdown (`.md`)
* PDF (`.pdf`)
* Plain text (`.txt`)
* Structured data: JSON (`.json`), CSV (`.csv`)
* Images: PNG, JPG/JPEG, GIF, SVG, WEBP, BMP, TIFF

Skipped at the repository root (to avoid boilerplate noise): `README.md`, `package.json`, `package-lock.json`, `tsconfig.json`. The same filenames inside subdirectories are ingested normally.

Useful examples to commit: security architecture diagrams, on-call escalation matrices, GDPR/SOC 2 attestations, vendor risk assessments, incident response runbooks, access review exports. Files can also be uploaded interactively from the onboarding UI — both paths feed the same vault.