System limits
System limits keep Logto stable and fair for everyone. They are separate from billing.
TL;DR
- Dev tenants: fixed caps (hard limits)
- Pro tenants: starting caps (soft limits). We can raise them for legitimate usage.
- Enterprise tenants: configurable, defined in the contract
On the pricing page, unlimited means no preset billing cap under fair use. To protect platform stability, we apply initial guardrails (like entity caps and rate limits) that can be increased for legitimate workloads.
Types of limits
System resource and entity caps
Maximum counts for objects such as applications, roles, organizations, connectors, webhooks, and certain usage-based system resources such as access token issuance.
Rate limit
Request-level protection applied per tenant.
Default: 200 requests per 10 seconds per tenant (token-bucket). This is roughly 20 RPS sustained, with short bursts allowed up to the bucket capacity.
If your traffic is legitimate and consistently exceeds this, we can evaluate an override.
What happens when you hit a limit
When a guardrail is triggered, requests may fail with an error such as:
- HTTP 429 (rate limit)
- HTTP 4xx with a limit-related message (entity cap or feature guardrail)
This does not delete data. It only blocks the operation that exceeded the limit.
How to request a limit increase
If you hit a limit and your use case is real, contact us. For Pro and Enterprise, we can usually raise limits quickly.
Please include:
- tenant ID (or tenant domain)
- which limit you hit (feature name + the number you need)
- (for RPS requests) expected traffic: average RPS, peak RPS, burst pattern
- affected endpoints (e.g., sign-in, token, JWKS, userinfo, Management API)
- timeframe (when you need the increase)
Tenant-level limit protection
Dev tenants
Dev tenants are intended for development and testing.
Dev tenant limits are hard limits, sized for development workloads. If you need a production-like environment, you can convert the tenant to Pro.
Dev tenants also follow a separate data retention policy.
| Feature | Entity limit |
|---|---|
| Access token cap (monthly) | 50k per mo |
| Applications | |
| Total applications | 100 |
| Machine-to-machine apps | 100 |
| Third-party apps | 100 |
| API resources | |
| Resource count | 100 |
| User authentication | |
| Social connector | 100 |
| Enterprise SSO | 100 |
| User management | |
| User roles | 100 |
| Machine-to-machine roles | 100 |
| Permission per role | 100 |
| Organizations | |
| Organization count | 5,000 |
| Users per organization | 100k |
| Organization user roles | 1,000 |
| Organization machine-to-machine roles | 100 |
| Organization permissions | 1,000 |
| Developers and platform | |
| Webhooks | 10 |
| Audit log retention | 14 days |
| Custom domains | 2 |
| Tenant members | 20 |
Pro tenants
Pro tenants come with higher caps. The caps below are initial guardrails, and can be increased for legitimate workloads (including higher rate limits).
If you need more, see: How to request a limit increase.
| Feature | Entity limit |
|---|---|
| Access token cap (monthly) | 10M per mo |
| Applications | |
| Total applications | 100 |
| Machine-to-machine apps | 100 |
| OIDC/OAuth 3rd party apps | 100 |
| SAML apps | 100 |
| API resources | |
| Resource count | 1,000 |
| Permission per resource | 1,000 |
| User authentication | |
| Social connectors | 100 |
| Enterprise SSO | 100 |
| User management | |
| User roles | 1,000 |
| Machine-to-machine roles | 100 |
| Organizations | |
| Organization count | 100k |
| Users per organization | 100k |
| Organization user roles | 1,000 |
| Organization machine-to-machine roles | 100 |
| Organization permissions | 1,000 |
| Developers and platform | |
| Webhooks | 10 |
| Audit log retention | 14 days |
| Custom domains | 10 |
| Tenant members | 100 |
Enterprise tenants
Enterprise limits and features are customizable and defined in the contract. Contact us for details.