Caps and rate limits
Understand upload limits, request body limits, API rate limits, page sizes, and why bounded reads matter.
Why limits exist
Limits keep a self-host install predictable. Without them, one upload, invite loop, setup check loop, or large relation picker could overwhelm the app or database.
These are product-level guards. Your host, proxy, database, and storage provider may also have their own limits on top of these.
Deployment covers host and proxy configuration; Media and files covers the storage behavior behind the upload limits.
Upload limits
| Area | Limit |
|---|---|
| Avatar image | 5 MB |
| Media image | 10 MB per image |
| File library file | 25 MB per file |
| Media batch | 10 images |
| File batch | 10 files |
| Media multipart API body | 60 MB when that API path is used |
| File multipart API body | 130 MB when that API path is used |
| Profile update JSON | 16 KB |
Primary media and file bytes upload through signed Supabase or S3-compatible URLs, while BaseBuddy APIs prepare, complete, and record metadata. If users see upload failures before BaseBuddy returns an error, check the provider limit, browser/direct-upload path, and any reverse proxy request body limit that applies to BaseBuddy API requests.
Common rate limits
| Area | Limit |
|---|---|
| Project creation | 5 requests per 30 minutes |
| Setup checks | 20 requests per minute |
| Profile updates | 10 PATCH requests per minute |
| Content save | 60 requests per minute |
| Publish, unpublish, archive | 20 requests per minute |
| Mapping save | 10 requests per minute |
| Media/file write actions | 20 requests per minute |
| Media/file move actions | 30 requests per minute |
| Member and invite writes | 20 requests per minute |
| Project address changes | 5 requests per 10 minutes |
| Public invite accept | 20 POST requests per minute |
Edit-session heartbeats allow 120 requests per minute, and edit-session acquire/release allow 60 per minute. Media/file browse GET requests use bounded reads but do not use the same fixed-window limiter. The built-in limiter is process-local; multi-process production deployments need host-level or shared rate limiting if strict cross-instance limits matter.
When a request is rate limited, wait for the retry period before trying again. If this happens often in production, add a shared host-level rate limit so multiple app processes enforce the same policy.
Use How to read BaseBuddy logs when you need to distinguish app-side rate limits from host or proxy errors.
Runtime page sizes
BaseBuddy uses bounded reads for normal runtime work.
| Area | Expected behavior |
|---|---|
| Project members | Bounded pages, not full member table scans |
| Relation options | Search and selected-ID hydration instead of full option loads |
| Media/files | Page-plus-one reads and folder-bounded listing |
| Post lists | Bounded pages, cursor/projection paths for large tables |
| Table catalogs | Cached catalog reads with manual refresh |
Relation controls are tied to the mapping shape. Mapping fields and relations explains why selected values hydrate separately from the searchable option set.
What to tune outside BaseBuddy
Tune your database indexes, connection pooling, request body limits, and storage bucket policies for your own traffic.
BaseBuddy won't automatically create indexes on your content tables. Review recommendations, test them, and apply them yourself when they match your app's needs.
If a save fails after a body-size, origin, or proxy change, use How to fix save failures before changing the mapping.