Where Your Files Live

Where your uploaded and generated files live: S3-compatible storage isolated per workspace by bucket. Most users configure nothing; self-hosters set server env

What you'll learn

  • Where your uploaded and generated files actually live, and how workspaces stay isolated.
  • Why most users don't configure storage at all today.
  • What self-hosters set, and what's still on the roadmap.

The concept: S3-compatible object storage, isolated by bucket

When you upload an image to a content piece, or the Graphics Generator produces one, the file has to live somewhere. m18t doesn't keep media on the app server — it uses S3-compatible object storage. Each workspace gets its own isolated bucket. That bucket boundary is how one workspace's files stay separate from another's.

Here's the honest state of things, and it differs from AI or CMS keys: storage credentials are not in the Vault today. Unlike OpenAI or Strapi tokens — which you bring per brand and store encrypted — storage is configured once at the server-environment level. Per-workspace bring-your-own storage (S3 / R2 / GCS) is on the roadmap, not shipped. Until it lands, isolation is enforced by the per-workspace bucket name, not by per-workspace credentials.

If you're on a hosted/managed m18t (most beta users)

You don't configure storage at all. The server already has S3 credentials in its environment. The first time you upload a file or generate an image, m18t uses those credentials to create your workspace bucket and writes there. Nothing is required on your end — there's no storage connection to add in the Vault or the Connections page.

If you're self-hosting m18t

You set the storage target through environment variables on the m18t server, not through any in-app screen. In your m18t server environment (e.g. its .env file), point at your MinIO (or other S3-compatible) instance:

S3_ENDPOINT="http://localhost:9000"
S3_REGION="us-east-1"
S3_ACCESS_KEY="your_minio_access_key"
S3_SECRET_KEY="your_minio_secret_key"

Restart the server process. m18t uses these administrative credentials to create workspace buckets as workspaces upload or generate files. Because this is a server-level setting, it applies across the whole instance — there is no per-workspace or per-brand storage override in the UI yet.

What the Storage page in Studio actually does

If you open the storage area under Configuration (/studio/config/storage), you'll find a page titled Export Your Data, not a storage connection manager. Its one action is Download database snapshot — a consistent export of your workspace database as a standard database file you can keep as a personal backup.

The page itself states the rest plainly: storage BYOK (S3 / R2 / GCS) is on the roadmap, and when it ships, this page is where a fuller storage manager (scheduled backups, integrity checks, per-asset control) will live. For now, the export is what's here.

FAQ

Where do I paste my S3 / MinIO keys in the app? Nowhere, today. Storage isn't a Vault connection yet. Hosted users need nothing; self-hosters set server environment variables. Per-workspace storage BYOK is roadmap.

Are my files isolated from other workspaces? Yes — each workspace writes to its own isolated bucket. Isolation is at the bucket level. (Per-workspace credentials are the roadmap addition, not the isolation itself.)

My uploads or generated images are failing. On hosted m18t, that's a server-side issue — contact support. On self-hosted, check your S3_* environment variables and that your MinIO instance is reachable from the m18t server, then restart.

Can I use AWS S3, Cloudflare R2, or GCS instead of MinIO? The storage layer is S3-compatible, so an S3-compatible endpoint can work for self-hosters via the same env vars. Formal per-workspace BYOK across S3/R2/GCS is the roadmap item.

How do I back up my data right now? Use Download database snapshot on the Export Your Data page to grab your workspace database. Media lives in your bucket separately.

What's next

Was this article helpful?