The first app gets a storage bucket. So does the second, because copying the setup is quicker than sharing it. By the fourth app you have four buckets, four sets of credentials, four upload routes, and the same logo stored in all of them, slightly different in each.
This guide looks at why that happens, three ways to share one library between apps instead, and the habits that keep a shared library tidy whichever way you go.
Why every app ends up with its own bucket
A bucket per app is the path of least resistance. Each project is set up on its own, and isolating them feels safe. The costs show up later:
- Setup repeats. Every app needs storage, access rules, an upload route and a way to list what's there.
- Files drift. Something two apps need gets copied, then one copy is updated and the other isn't.
- Nobody has the full picture. Finding a file means remembering which app uploaded it.
Option 1: one bucket, a prefix per app
Keep a single bucket with a folder-like prefix for each app (app-a/, app-b/) and a shared prefix for common files.
This removes the duplicate buckets, but the rest of the work stays with you. You write access rules so each app's credentials reach only its own prefix and the shared one. You still have no way to search beyond listing names, so you end up keeping a database table of what's stored where, and keeping it in sync with the bucket.
Option 2: build a small file service
Put an internal service in front of storage: one upload endpoint, one database table of files with their tags, one search endpoint. Every app talks to the service instead of the bucket.
This is the most flexible option, and it's how a lot of teams end up. It's also a project: authentication for each app, uploads, duplicate handling, thumbnails or previews, a way to browse files, and the upkeep of all of it.
Option 3: a hosted file library
Use a service that already does option 2. Stow (usestow.com) is one: each app gets its own key, every upload is stored once and described, and every app on the account can search the whole library.
What that looks like in practice:
- A key per app. Add each app on the Apps page and give it its own key. Revoke one without touching the rest.
- Folders that sort themselves. Each app uploads into a folder named after it. Give an app a subfolder tag, like
show, and its uploads taggedshow:Serialland in aSerialfolder inside its own. - Shared across the account. Any app's key can search and read every file on the account, so a file uploaded once can be used everywhere.
- Stored once. Identical bytes are recognized by their content hash, so two apps uploading the same file get one stored copy.
The trade-offs: files are limited to 25 MB each, and every app on an account sees the whole library. Apps that must never share files belong in separate accounts.
Finding a shared file by name
When several apps rely on the same file, give it a lookup key at upload, then search for that key from anywhere:
# The app that owns the banner uploads it with a key
curl -X POST https://api.usestow.com/v1/assets \
-H "Authorization: Bearer $MARKETING_SITE_KEY" \
-F file=@banner.png \
-F 'metadata={"key": "hero-banner", "tags": ["brand"]}'
# Any other app on the account finds it by that key
curl -X POST https://api.usestow.com/v1/assets/search \
-H "Authorization: Bearer $APP_KEY" \
-H "Content-Type: application/json" \
-d '{"key": "hero-banner"}'
Habits that keep a shared library tidy
Whichever option you choose, a few habits make the difference between a shared library and a shared mess.
Agree on tags early. A handful of key:value tags used everywhere beats a hundred one-off tags. For example source: (which app or job made it), project:, and one tag for what the file is about, like ticker: or episode:.
Keep links stable. Apps will store links in their own databases. A link that changes when a file is renamed or moved breaks every one of them. Stow's links depend only on a file's contents, so moving a file between folders never changes its link.
Decide public or private at upload. Shared libraries tend to mix files meant for a website with files that should never leave your apps. Make the choice per file, on purpose. Public vs private file links covers how to decide.
Give each app its own key. Shared credentials make it impossible to tell which app uploaded what, or to switch one off.
Store duplicates once. Content hashing turns "did we already upload this?" into a lookup instead of a guess.
For the full setup on one page, see One library for several apps, or the Apps and Folders sections of the docs.