> 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 targets + event filters          | **Configure → Notifications** | `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 approve a pull request when it has no blocking findings.

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

### Ticketing thresholds and SLAs

Ticket creation is driven per finding type from **Configure → Ticketing** (`POST /admin/ticketing/settings/{findingType}`). A ticket is created when a finding meets both the configured severity and priority thresholds.

Default thresholds:

* Severity default: **MEDIUM**
* Priority default: **IMPORTANT**

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 targets and the events that trigger them are managed from **Configure → Notifications** (`PUT /admin/integrations/notifications`).

### 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: `.bitbucket-private`
* 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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.nullify.ai/configuration/configuration-general.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.