Configuration Overview
Pixee is configurable at three levels: a PIXEE.yaml file in each repository for developer-controlled behavior, organization-wide settings in the Pixee dashboard for security team policies, and AI settings for tuning triage and remediation behavior. Most teams run Pixee with zero configuration on day one and customize as they scale. This section covers every configuration surface.
Configuration Philosophy
Pixee works out of the box. The default settings enable Triage Automation and Remediation Automation for all supported languages and vulnerability types across your connected repositories. No PIXEE.yaml file, no dashboard toggles, no AI tuning required to start receiving pull requests with validated fixes.
Configuration exists for when defaults are not enough. Maybe your team wants to exclude a test directory, batch PRs into weekly review cycles, or route Slack notifications to a security channel. Pixee's configuration model is designed around progressive customization: start with zero config, then layer on settings as you understand your team's needs.
Two principles guide the model:
- Developer agency. PIXEE.yaml lives in the repository root, version-controlled alongside your code. Developers own the behavior of Pixee in their repos the same way they own
.eslintrcordependabot.yml. - Security team governance. Organization-wide settings in the Pixee dashboard let security leads enforce policy across all repositories without touching individual repos.
Configuration Layers
Pixee settings operate across three layers. When a setting is defined at multiple layers, the more specific layer takes precedence.
| Layer | Scope | Who Controls | Mechanism |
|---|---|---|---|
| Repository | Single repo | Developers | PIXEE.yaml in repo root |
| Organization | All repos | Security team | Pixee dashboard |
| AI Settings | Analysis behavior | Security team | Pixee dashboard |
Precedence: Repository-level PIXEE.yaml settings override organization defaults where applicable. Organization-level policies may restrict which PIXEE.yaml overrides are honored, giving security teams guardrails over developer-controlled configuration.
If a PIXEE.yaml file is invalid or contains syntax errors, Pixee falls back to organization defaults and logs a warning. No analysis is skipped.
Quick Reference: What Goes Where
Use this table to jump to the right page for your configuration task.
| I want to... | Go to |
|---|---|
| Exclude specific files or directories from analysis | PIXEE.yaml Reference |
| Ignore specific findings or CWE categories | PIXEE.yaml Reference |
| Enable or disable specific fix types | PIXEE.yaml Reference |
| Customize PR formatting (labels, title prefix) | PIXEE.yaml Reference |
| Add or remove repositories from monitoring | Repository Management |
| Organize repos by team or business unit | Repository Management |
| Set scan schedules or switch to on-demand analysis | Operations |
| Route notifications to Slack or email | Notifications |
| Set up webhook integrations for custom workflows | Notifications |
| Manage team member access and roles | Users & Access |
| Configure SSO with your identity provider | Users & Access |
| Tune AI triage sensitivity | AI Settings |
| Control which finding categories get AI-powered fixes | AI Settings |
| Configure reporting exports or dashboards | Reporting |
| Export data for compliance audits | Reporting |
Getting Started with Configuration
If you just installed Pixee, the recommended approach is:
- Week one: run with defaults. Let Pixee analyze your repositories and open PRs with its default settings. Review the fixes, check the triage results, and get a feel for the baseline behavior.
- Week two: customize per-repo behavior. Add a PIXEE.yaml file to repositories that need specific exclusions, ignored findings, or PR formatting preferences. See PIXEE.yaml Reference for common recipes.
- Ongoing: tune organization settings. As you scale to more repositories, use the Pixee dashboard to set organization-wide policies for scheduling, notifications, and AI behavior.
Enterprise self-hosted deployments have additional configuration surfaces for infrastructure (LLM providers, authentication, observability) managed through the admin console or Helm values. See Enterprise > Deployment Options for details.