Give Your Users Storage Without Becoming a Storage Company
Four platforms, one API. Each partner's users get isolated storage without anyone managing regions or accounts.
Every platform eventually needs to offer storage. You either build storage into your product, or tell your users to go set it up somewhere else. But the hard part isn't the storage — it's the multi-tenancy.
Building multi-tenant storage on top of S3 means creating separate AWS accounts per tenant (or managing IAM policies that would make a bureaucrat weep), dealing with per-account bucket limits, choosing regions for each customer, configuring cross-region replication, and managing the billing for all of it.
You wanted to add a storage feature. Now you're operating a storage company.
The Tigris Partner Integration API is how four platforms solved this without building their own storage layer.
The AWS multi-tenancy tax
"Just use S3" sounds simple until you're building for multiple tenants.
AWS gives you a few options for multi-tenant storage. You can use a bucket-per-tenant model, which provides strong isolation but hits practical limits as you scale — managing thousands of buckets across accounts gets unwieldy fast. You can use a shared bucket with prefix-based isolation, which means writing and maintaining IAM policies that correctly scope access for every tenant. Or you can use S3 Access Points, which is AWS's answer to the complexity of the first two options, and it comes with its own set of quotas and configuration overhead.
All of these approaches share the same fundamental problem: you're assembling multi-tenancy from primitives that weren't designed for it. S3 was built to store objects for a single account. Everything multi-tenant is bolted on through IAM, bucket policies, and organizational units. Each layer adds configuration, each configuration adds failure modes.
Then there's the region question. S3 buckets live in a single region. If you want high availability or have users in more than one region, you need Cross-Region Replication. That means configuring replication rules, paying for transfer between regions, monitoring replication lag, and handling the inevitable edge cases where an object hasn't replicated yet. Want multi-region access? That's another feature with its own limits (100 Multi-Region Access Points per account, 17 regions max per access point).
And all of this is per AWS account. If you want strong tenant isolation, AWS recommends separate accounts per tenant, which means you're now managing an AWS Organization with hundreds or thousands of member accounts, each with their own billing, their own quotas, their own IAM boundaries.
That's CloudFormation templates (or, let's be honest, Terraform), IAM role trust policies, billing aggregation scripts, and quota increase tickets — all before a single user uploads a file.
How the Partner Integration API works
Instead of giving you storage primitives to assemble, the Partner Integration API treats tenant management as a first-class concept.
Tigris assigns you a Provider identity. Under that provider, you create Organizations, one per tenant. Each organization is a complete isolation boundary with its own buckets, users, access keys, and usage tracking. Organizations can't see each other's data, can't access each other's buckets, and are billed independently.
Provisioning a new tenant is one API call. That call creates the organization, sets up an initial bucket, and returns credentials, all atomically. You can specify storage class and quota limits, or just let it run with defaults. When a tenant leaves, one deactivation call revokes all access immediately while preserving data for compliance.
POST /v1/providers/{provider_id}/orgs/{org_id}
No IAM role chaining, no account vending machines.
No region selection, no bucket limits
Tigris is globally distributed by design. Objects are stored near where they're written and cached near where they're read. There's no region picker because there doesn't need to be one. Your user in Frankfurt and your user in Virginia both get low-latency access without you configuring anything.
There are no per-account bucket limits. You'll never file a support ticket to increase your quota or create a second account because you ran out of buckets.
Your brand, not ours
The standard Tigris endpoint looks like
https://your-bucket.t3.storage.dev/object.txt, but partners can bring their
own domains. Your users interact with endpoints that look like they're part of
your platform. Credentials are scoped to their organization. From your user's
perspective, this is your storage product.
It's S3-compatible, so your users can use whatever S3 SDK they already know. Authentication uses HMAC-based request signing, aligned with S3 SigV4. This wasn't arbitrary: it keeps the entire ecosystem consistent. Partners and their users authenticate with the same signing model that every S3 tool already supports.
Usage and billing per tenant
Tigris provides usage data per organization with daily granularity. You pull the numbers, apply your own pricing, and bill your customers however you want. No need to reverse-engineer a consolidated bill to figure out which tenant used what.
GET /v1/providers/{provider_id}/orgs/{org_id}/usage?starting_on=2026-03-01&ending_before=2026-03-04
How platforms are using it
Here's how four partners built storage into their products using the Partner Integration API. Each had a different need, and none of them wanted to build and maintain their own storage infrastructure to do it.
Railway
Railway is an all-in-one cloud platform for deploying apps, databases, and services. When their users asked for object storage, Railway didn't build their own. They used the Partner Integration API to ship Storage Buckets as a native platform feature.
Railway Buckets are private, S3-compatible, and scoped per environment. When you duplicate an environment or spin up a PR preview, you get a separate bucket with isolated credentials. You won't accidentally overwrite production data from a staging deployment.
Railway ran head-to-head benchmarks against other object storage providers and found Tigris was twice as fast in their architecture. They didn't sacrifice performance for the flexibility of automatic global distribution and easy tenant isolation.
The whole feature went from concept to production in two weeks. Users see Railway branding, Railway pricing ($0.015/GB-month, free egress, free API operations), and Railway credentials. Under the hood, it's Tigris running on bare metal. The user doesn't know, and they don't need to. (Until they read this blog post.)
Agentuity
Agentuity is a platform for building and deploying AI agents. Agent workloads are unpredictable — an agent might write thousands of files in a session, pull down massive datasets, snapshot its entire state, and then spin down. You can't pre-provision storage for workloads when you don't know what you'll need until the agent starts working.
Agentuity uses the Partner Integration API to give each customer their own isolated storage environment. Through that integration, they run five storage layers: agent persistent storage (via TigrisFS-mounted filesystems), deployment artifact storage, a global CDN, on-demand customer buckets, and sandbox snapshots. Agents can provision storage for themselves without human intervention.
Because it's S3-compatible, Agentuity treats the same service as a filesystem, a CDN origin, a snapshot store, and a per-agent scratchpad. Five uses, one integration.
Why did we choose Tigris as partners? We think it's the agentic future. More so than the legacy cloud.
Basic Memory
Basic Memory is a knowledge management tool that lets you build persistent knowledge through conversations with LLMs like Claude. It turns conversations into local Markdown files and builds knowledge graphs from the relationships between them.
Basic Memory uses the Partner Integration API to provide storage for users' knowledge bases: the files, embeddings, and artifacts that accumulate as users work. The partner integration means each user's data is completely isolated, and Basic Memory can offer storage as a native part of their product without managing infrastructure.
Fly.io
Fly.io was the first Tigris partner. Their users deploy
applications to a global edge network, and those applications need somewhere to
put files. Tigris runs on Fly's infrastructure, so the integration is tight:
users create and manage Tigris buckets through flyctl, and all the S3
configuration gets injected into their apps automatically.
A Fly.io user doesn't think about Tigris as a separate service. They run
fly storage create, get a bucket, and start using it. The storage is globally
distributed across Fly's regions, so objects are fast everywhere their app runs.
They don't pick a region. They don't configure replication. They don't pay
egress.
Getting started
Three steps:
- Read the architecture guide — understand how providers, organizations, and buckets map to your tenancy model.
- Get your credentials — email help@tigrisdata.com for a Provider ID and signing key.
- Start provisioning — create organizations for your tenants, generate access keys, and integrate billing. Your users authenticate with standard S3 SigV4 signing, so existing tools and SDKs work without modification.
The Partner Integration API started with Fly.io and was incrementally shaped by real production use cases as more partners came on. It wasn't designed in a vacuum. That's why Railway went from concept to production in two weeks: the API had already matured through years of real usage.
The Partner Integration API lets you offer S3-compatible object storage to your users with one API call. No regions. No bucket limits. No AWS account gymnastics.