We built the storage layer
SaaS teams keep reinventing.
Tenantbox is a file storage backend purpose-built for multi-tenant applications. Instead of spending weeks writing isolation logic, quota enforcement, and usage tracking from scratch, you plug Tenantbox into your existing API and move on to building what actually matters.
What is Tenantbox?
Tenantbox is a hosted backend service that handles file storage for applications that serve multiple users or organisations — commonly called multi-tenant apps. Think of tools like Notion, Dropbox, or any SaaS where each customer has their own space: Tenantbox is the piece that stores their files, keeps them separated, and tracks how much storage each one is using.
Rather than uploading files to your own server first, your application asks Tenantbox for a short-lived upload link called a presigned URL. Your user's browser or app then uploads the file directly to Tenantbox's storage — your servers are never in the way. This makes uploads faster and keeps your infrastructure lean.
When the upload finishes, Tenantbox automatically creates a storage namespace for that user (if one doesn't exist yet), records the file, checks it against any quota you've set, and updates their usage total — all without you writing a single line of bookkeeping logic.
Imagine a self-storage facility. Each of your customers gets their own locked unit (tenant namespace). The facility manager (Tenantbox) handles keys, measures how full each unit is, and stops anyone from overfilling their allocated space. You — the business owner — simply tell the manager "let Alice store a box" and they handle everything else. You never need to touch the boxes yourself.
In technical terms: isolated S3-compatible object storage per tenant, with automatic quota enforcement and real-time usage tracking — exposed via two REST endpoints.
The problem every SaaS team hits
The moment your product lets users upload files, you have to solve a surprisingly deep set of problems. Most teams only discover this after they've already shipped version one.
Tenant isolation
If you store all files in one S3 bucket, you need to manually namespace every file path so User A can never read User B's files. One bug in a path-construction function and you have a data breach.
Quota enforcement
Most storage providers charge you — not your users. Without per-tenant limits you can't offer tiered plans, prevent abuse, or bill by storage used. Building this yourself means writing size-check logic on every upload endpoint.
Upload performance
If your server proxies file uploads (receives the file, then re-uploads it to S3), every large file blocks a server thread and doubles your bandwidth bill. Direct-to-storage uploads bypass this entirely.
Usage tracking
To bill customers by storage, know when someone is near their limit, or build a usage dashboard, you need an accurate running tally per tenant. S3 does not provide this natively — you have to compute it yourself.
Tenant lifecycle
When a new user signs up and uploads their first file, something needs to create their storage namespace. When they delete their account, something needs to clean up. This plumbing is boring but breaks in interesting ways.
IAM & permissions
Giving each tenant an S3 bucket (or path with scoped IAM policies) requires AWS expertise. Managing those policies — and rotating credentials safely — is toil that compounds as you grow.
Without Tenantbox
- —Write custom S3 path logic for every upload
- —Build quota-check middleware for every endpoint
- —Maintain a storage_usage table and keep it consistent
- —Debug upload timeouts caused by server proxying
- —Manage IAM policies as tenants are created and deleted
- —Pay egress fees every time a user downloads a file
With Tenantbox
- ✓Two HTTP calls: get URL, PUT file — done
- ✓Quotas checked before the upload even begins
- ✓Usage totals updated automatically on every upload
- ✓Files go directly to storage — your server stays free
- ✓Tenants are created on first upload, deleted on request
- ✓Zero egress fees — globally
How it works — step by step
The entire upload flow is two HTTP calls. Here's what actually happens behind the scenes at each step.
Your backend requests a presigned URL
POST https://api.tenantbox.dev/api/storage/upload/You send a single authenticated POST from your server to Tenantbox. You include the tenant's ID (any string you use to identify your user — an email, UUID, or database ID all work), the filename, and the file's content type (e.g. application/pdf). Tenantbox checks whether this upload would exceed the tenant's storage quota before doing anything else. If the quota would be exceeded, it rejects the request immediately with a clear error — no partial uploads, no silent overages.
Behind the scenes: Tenantbox responds with a presigned URL (a time-limited, pre-authorised upload link) and a file_path that you can store in your database. It also tells you whether this is a new tenant (is_new_tenant: true) so you know a namespace was just auto-created.
Your frontend uploads directly to storage
PUT <presigned_url> + file bytesYour client — the user's browser, mobile app, or CLI tool — sends the file directly to the presigned URL. The file travels straight from the user's device into Tenantbox's S3-compatible storage. Your server is not involved at all. This is what makes uploads fast: there's no middleman to relay bytes through, and no server thread blocked waiting for a large file to land.
Behind the scenes: Presigned URLs expire after a short window (typically 15 minutes), so even if one were leaked it could not be reused indefinitely. The Content-Type sent must match what was requested in step 1.
Tenantbox confirms, tracks, and enforces
GET /api/storage/tenants/{tenant_id}/usage/After the upload completes, Tenantbox records the file against the tenant's namespace, updates their running storage total, and marks the upload as confirmed. From this point on, the file appears in the tenant's file list in the dashboard, is included in usage calculations, and counts toward their quota.
Behind the scenes: You can query usage at any time via the usage endpoint. This gives you the bytes used, file count, and quota limit — everything you need to render a storage used bar in your own UI or trigger a billing event.
Core capabilities, explained
Per-Tenant Isolation
Every user's files live in their own namespace.
When you upload a file for tenant user_123, it is stored under a path prefix that belongs only to them. No other tenant can accidentally access it — not through a bug, not through a misconfigured query. Tenants are created automatically on their first upload; you never need to pre-register them.
Storage Quotas
Set limits per tenant. Tenantbox enforces them.
You can assign a storage limit (in bytes) to any tenant. When they try to upload a file that would push them over the limit, Tenantbox rejects the upload before the file transfer even begins — saving bandwidth and preventing unexpected overages. Unlimited tenants (no quota set) are also supported.
Presigned Upload URLs
Direct uploads. No server proxying.
A presigned URL is a pre-authorised, time-limited link to a specific storage location. Your server generates one via Tenantbox, hands it to the client, and the client uploads directly. This architecture means your servers never buffer large files — improving performance and eliminating a class of timeout bugs.
Real-Time Usage Tracking
Always know how much storage each tenant uses.
Tenantbox maintains an accurate running total of bytes stored and file count for every tenant. You can query this at any time. This makes it straightforward to build a storage usage UI, trigger upgrade prompts, or feed accurate numbers into your billing system.
Built-In Dashboard
Manage everything without building your own admin UI.
The Tenantbox dashboard lets you browse all projects, inspect individual tenants, see their files, download or delete them, and monitor storage usage across the board. It is the same UI your team uses to operate the service day-to-day.
API Key Authentication
Simple, revokable credentials per project.
Every project has its own API key. Your backend includes this key in the Authorization header of every Tenantbox request. Keys can be regenerated at any time — useful if a key is accidentally committed to version control or needs to be rotated as part of a security policy.
Who is Tenantbox built for?
Indie developers & small teams
You're building fast and don't want to become an accidental S3 expert. Tenantbox gives you production-grade multi-tenant storage on day one so you can focus on your product's actual differentiation.
SaaS platforms
Document editors, project management tools, analytics platforms, CRMs — any SaaS where users upload and own files. Tenantbox handles the storage layer so your engineers solve harder problems.
Usage-based billing products
If you charge customers by how much storage they use, Tenantbox's real-time usage API is the source of truth. No manual S3 size calculations, no cron jobs, no stale numbers.
Internal tooling
Teams building internal file management tools — HR document portals, asset libraries, compliance archives — can get isolated, permissioned storage without standing up their own infrastructure.
Common questions
Do I need to change how my frontend works?
Minimally. Instead of uploading to your own server, your client does a PUT to the presigned URL that your server fetches from Tenantbox. Most HTTP clients (fetch, axios, URLSession) support PUT out of the box. The change is typically 5–10 lines.
What is a tenant, exactly?
A tenant is any identity you want to scope storage to. In a typical SaaS it's a user ID or organisation ID from your own database. It can be any string — Tenantbox doesn't care about the format. You pass it in with every upload request.
What happens if a tenant tries to upload more than their quota?
Tenantbox checks the quota before issuing a presigned URL. If the upload would exceed the limit, the request is rejected with an HTTP 4xx error and a clear message. The presigned URL is never generated, so no transfer begins and no partial file is left in storage.
Is there an SDK I need to install?
No. Tenantbox is a REST API — any language or runtime that can make an HTTP request works. There is an optional Python library on GitHub for convenience, but it is not required.
Where is my data stored?
Tenantbox uses S3-compatible object storage. Files are stored in isolated namespaces per tenant. Refer to the API docs or contact support for specific region and data-residency details.
What does "zero egress fees" mean?
Most cloud storage providers (AWS S3, Google Cloud Storage) charge you every time data leaves their network — for example, when a user downloads a file. Tenantbox does not charge egress fees, so serving files to your users has no per-GB transfer cost.
Ready to stop reinventing the wheel?
Free to get started. No credit card required. Two API calls and your files are isolated, quota-enforced, and tracked per tenant — out of the box.