# Limits per tier

This page gathers Bastide's limits: those of each tier, grouped by theme, then the platform's, which apply to everyone. Per-tier values are those of the published grid; prices and what is billed beyond them are in [Billing](billing.md).

## Reading these tables

A per-tier limit applies per project unless stated otherwise. « Negotiated » means the value is set in the Sovereign tier's quotation. When a limit is reached, the platform refuses with a code and a sentence naming the limit and its value; it never cuts silently. A storage or minutes limit never stops the service delivered to the visitors of a site already online.

> **Note.** A project starts in Discovery and changes tier through the **Palier** (Tier) screen. Pro opens subject to available capacity; Sovereign is quoted on request and its dedicated node is not served yet.

## Compute

| | Discovery | Standard | Pro | Sovereign |
| --- | --- | --- | --- | --- |
| Production | Sleeps after 15 min | Always warm | Always warm | Dedicated, hot replica |
| Memory per `web` instance | 512 MB | 512 MB | 2 GB | negotiated |
| Guaranteed CPU share | 0.05 vCPU | 0.16 vCPU | 1 vCPU | negotiated |
| Processes (PID cap) | 256 | 512 | 1,024 | negotiated |
| Ephemeral disk `/tmp` | 512 MB | 1 GB | 4 GB | negotiated |
| Services per project | 1 | 10 | 25 | negotiated |
| Instances per service | 1 | 3 | 10 | negotiated |
| Scheduled tasks per project | 5 | 20 | 100 | 500 |
| Custom environments | 0 | 2 | 10 | 10 |

A workload that exceeds its memory is killed by the kernel (`memoire_depassee`); the report gives the observed value and the limit. A `glowsoft.json` declaring more services or scheduled tasks than the tier allows is refused before any build (`declaration_refusee`), naming the cap.

## Database

| | Discovery | Standard | Pro | Sovereign |
| --- | --- | --- | --- | --- |
| Isolation | Shared cluster | Shared cluster | Dedicated PostgreSQL instance | Dedicated instance and node |
| Included database | 1 GB | 8 GB | 50 GB | 250 GB |
| Database branches | 1 | 3 | 25 | 50 |
| PostgreSQL extensions | 20, allow-list | 50, allow-list | Any | Any |
| Connections, client / server | 30 / 3 | 60 / 5 | 200 / 15 | negotiated |
| Statement / idle transaction timeout | 30 s / 60 s | 30 s / 60 s | 300 s / 300 s | 300 s / 300 s |
| Backup | Daily | Hourly over 48 h, then daily | Point-in-time recovery (PITR) to the second | PITR and synchronous replica |
| Backup retention | 7 days | 30 days | 35 days | 90 days |
| Contractual RPO / RTO | 24 h / 4 h | 1 h / 2 h | 5 min / 30 min | 5 min / 30 min |

## Realtime

| | Discovery | Standard | Pro | Sovereign |
| --- | --- | --- | --- | --- |
| Messages per second | 100 | 500 | 2,500 | negotiated |
| Concurrent connections | 200 | 2,000 | 10,000 | negotiated |

## Storage and emails

| | Discovery | Standard | Pro | Sovereign |
| --- | --- | --- | --- | --- |
| Included object storage | 5 GB | 50 GB | 250 GB | 1 TB |
| Maximum file size | 50 MB | 5 GB | 50 GB | project quota |
| Included image transformations per month | 5,000 | 50,000 | 250,000 | 1,000,000 |
| Transactional emails per month | 1,000 | 10,000 | 50,000 | 200,000 |

An upload is refused if it exceeds the type or size allowed by the bucket, the tier's maximum file size or the project's quota; the refusal names which of the three applies. Beyond the included transformations, the image is served as is.

## Network

| | Discovery | Standard | Pro | Sovereign |
| --- | --- | --- | --- | --- |
| Outbound traffic, fair use | 500 GB/month | 2 TB/month | 10 TB/month | 50 TB/month |
| Sustained outbound throughput per project | 20 Mb/s | 50 Mb/s | 200 Mb/s | 500 Mb/s |
| Concurrent outbound connections per container | 256 | 512 | 2,048 | 4,096, negotiated |
| Request budget per project, 10 s burst | 100 req/s | 250 req/s | 1,000 req/s | 2,500 req/s |
| Custom domains per project | 1 | 10 | 100 | 500 |

Outbound throughput is never refused nor truncated: a ten-second burst goes at full speed, then the edge paces sending down to the cap. At 80 % of the burst, the platform emits the `project.egress.threshold` event to the project's endpoints (see [Webhooks](webhooks.md)).

## Build and deployment

| | Discovery | Standard | Pro | Sovereign |
| --- | --- | --- | --- | --- |
| Build minutes per month | 100 | 500 | 2,000 | 10,000 |
| Concurrent builds | 1 | 2 | 5 | negotiated |
| Concurrent previews | 1 | 3 | 25 | 50 |

The minutes allowance is a hard cap: once reached, it refuses further builds until the first of the month (UTC), billing no overage. A build cancelled by a newer push does not count; a failed build does.

## Observability

| | Discovery | Standard | Pro | Sovereign |
| --- | --- | --- | --- | --- |
| Runtime log retention | 7 days | 30 days | 90 days | 365 days |
| Project audit log | 30 days | 12 months | 24 months | 36 months |

## Team, security and support

| | Discovery | Standard | Pro | Sovereign |
| --- | --- | --- | --- | --- |
| Seats | Unlimited | Unlimited | Unlimited | Unlimited |
| Single sign-on and SCIM | — | Included | Included | Included |
| Preview protection, 4 modes | Included | Included | Included | Included |
| Committed availability | 99.5 % | 99.9 % | 99.9 % | 99.95 % |
| Support | Documentation, forum | Ticket, email, 9 am – 6 pm working days | Ticket, email, phone, 8 am – 7 pm working days | Ticket, phone, named contact, 8 am – 8 pm working days |

> **Note.** During the beta, Bastide runs in a single region, in France, and the numeric availability commitment is not in force yet.

## The free project

Each verified person's free project has its own limits, tighter than Discovery:

| Limit | Value |
| --- | --- |
| Sleep | after 15 min without a request |
| Dormancy | after 30 days with neither a visit nor a deployment |
| Database | 500 MB |
| Object storage | 1 GB |
| Build minutes | 100 per month |
| Emails | 100 per month |
| Custom domains | 1 |
| Outbound network | closed by default, opened host by host; no outbound SMTP |
| Sustained CPU | 0.25 core |

## Platform limits

These limits apply to every tier.

### API rate

Each token (or the console session standing in for it) has two limits, over a sliding window:

| Limit | Value | Applies to |
| --- | --- | --- |
| General | 600 calls per 60 s | Every operation |
| Sensitive | 60 calls per 60 s | Writes, and reads that return a secret, on top of the general one |

Every response carries `RateLimit-Limit`, `RateLimit-Remaining`, `RateLimit-Reset` (in seconds) and `RateLimit-Policy`; a refusal returns 429 `rate_limited` with `Retry-After`. Each operation's reference page publishes its limits. Other caps protect specific actions:

| Action | Cap |
| --- | --- |
| Project creations by an agent | 5 per rolling day per tenant (`plafond_de_creations_de_projet`) |
| Sign-in failures | 5 within 15 minutes for an account from one address, then a doubling wait (`trop_de_tentatives`) |
| Personal tokens per account | 50 |
| Active second factors per account | 5 |
| Deployment hooks per project | 20 |
| Projects connected to the same repository within an organisation | 50 |

### Environment variables

An environment holds at most 1,000 variables and 262,144 bytes in total; beyond that, the write is refused (`quota_exceeded`).

### Requests served by the edge

| Parameter | Value | Adjustable | Beyond |
| --- | --- | --- | --- |
| URL length | 16 KB | no | 414 |
| Request headers | 100, 32 KB in total | no | 431 |
| Request body | 100 MB | up to 5 GB (`requests.maxBodyMegabytes`) | 413 |
| Connection to the application | 10 s | no | 502 |
| Application response headers | 15 s | not yet | 504 |
| Full response (guard timeout) | 300 s | 30 to 3,600 s (`requests.timeoutSeconds`) | 504 |
| Long-lived connection (WebSocket, event stream) | 60 min | not yet | connection ends |
| Concurrent connections per source address | 200 | no | connection refused |

Both settings are declared in the repository's `glowsoft.json` (see [Routing](routing.md)).

### Build

A repository's `Dockerfile` is read within bounds: 256 KiB, 4,000 lines, 32 KiB per logical line (`dockerfile_trop_grand`). The image produced targets `linux/amd64`, the fleet's only runtime architecture. A build that runs too long, logs too much or uses too much stops with a code that says so (`build_limite_duree`, `build_limite_journal`, `build_limite_memoire`, `build_limite_disque`); see [Builds](builds.md).

## Coming from Supabase

The known gaps between Bastide and Supabase (1,000 rows per REST response, the pooler's transaction mode, realtime without `postgres_changes`…) are listed and reproduced by a test on the public page <https://bastide.app/limites-supabase>, and repeated in [Migrate from Supabase](from-supabase.md).

See also: [Billing](billing.md), [Builds](builds.md), [Database](database.md), [Storage](storage.md), [Troubleshooting](troubleshooting.md).