Resource Limits
mipo enforces hard caps on the number of each resource type that can be created. These limits are defense-in-depth: a compromised admin account or a runaway integration cannot fill the database with millions of rows and degrade query performance system-wide. All limits are intentionally generous — they stop runaway creation without constraining legitimate growth. Attempts to create resources beyond the cap return a 409 Conflict response. Plan ahead by monitoring resource counts and raising limits before reaching the ceiling.
Fields & columns
| Name | Description |
|---|---|
MAX_SCANNERS | Maximum registered scanners: 10,000. Each scanner row carries a unique API key and heartbeat state. |
MAX_USERS | Maximum user accounts (local + OIDC combined): 10,000. |
MAX_ROLES | Maximum RBAC roles: 500. Keeping this small prevents role sprawl that makes permission reviews intractable. |
MAX_SCAN_TEMPLATES | Maximum distinct scan templates: 5,000. |
MAX_SCHEDULES | Maximum scheduled scan entries: 5,000. Each schedule wakes the scheduler and fans out jobs, so a large count has real CPU cost. |
MAX_SUBNETS | Maximum subnet scope rows: 50,000. |
MAX_PORT_LISTS | Maximum port lists: 5,000. |
MAX_PORTS_PER_LIST | Maximum ports per port list: 65,535 (the full valid port range). |
MAX_DISCOVERY_SOURCES | Maximum discovery sources: 500. |
MAX_SCANNER_GROUPS | Maximum scanner groups: 1,000. |
MAX_NOTIFICATION_CHANNELS | Maximum notification channels (email, webhook, Slack): 500. Fan-out cost is per channel. |
MAX_NOTIFICATION_POLICIES | Maximum notification policies: 2,000. |
MAX_ALARM_RULES | Maximum alarm rules: 2,000. |
MAX_DASHBOARDS | Maximum dashboards per user: 200. |
MAX_SUBNET_GROUPS | Maximum subnet groups: 2,000. |
MAX_PORT_LIST_GROUPS | Maximum port list groups: 2,000. |
MAX_SCAN_TEMPLATE_GROUPS | Maximum scan template groups: 2,000. |
MAX_PORT_CATALOG_ENTRIES | Maximum port catalog reference rows: 65,535. |
Gotchas
- When a resource creation request is rejected because the cap is reached, the API returns HTTP 409 Conflict. The error message will identify which limit was hit.
- Limits are enforced at the API layer — direct database inserts bypass them. Do not insert rows directly into the database.
- Raising a limit is always safe. Lowering a limit is not safe if existing data already exceeds the new value — coordinate with a migration or warning log before tightening any cap.
- Set monitoring alerts at 80% of each relevant cap so operators can plan to raise limits before reaching the ceiling. The limits are defined in shared/business-rules/resourceLimits.ts.
Related
- Scanners — Scanner count is subject to MAX_SCANNERS
- Rate Limit Hierarchy — Rate limits are a related constraint on scan throughput, not resource count