The Asset Library

Some files belong to _you_, not to a single project. Your logo. A set of reference screenshots. Brand photography. A welcome video. You don't want to dig them out of your downloads folder every time you start a new build. That's what the asset library is for: an account-wide shelf where you upload a file once and reach for it from any project and any prompt.

You'll find it at Dashboard → Assets.

What it is (and what it isn't)

The asset library is account-scoped. Upload your logo while building one app and it's right there when you build the next, with no re-uploading. The agent can pull a library asset into a build, embed it in the app, and reference it across many prompts.

It is easy to confuse with two other things, so here's the clean split:

The distinction with File Uploads & Storage is the one people miss most often. Supabase Storage holds files that the _people who download your app_ upload at runtime - their profile photo, their receipt scan. The asset library holds files that _you_, the builder, bring to the build itself. One is your users' content; the other is your raw material.

And unlike an image attachment, which rides along with a single message and is then forgotten, a library asset is persistent and shared. If a file should become part of the app, it's an asset. If you're just showing the agent something to talk about, it's an attachment.

Folders and organisation

A flat pile of files gets unmanageable fast. Group assets into folders - one per brand, one per app, one for reference shots, whatever fits how you work. Drag an asset between folders to move it, and rename folders as your projects grow.

The library view shows each asset as a thumbnail with its name, type, and size, so you can recognise the right file at a glance rather than guessing from a filename.

Bulk selection and management

Once you've accumulated a few dozen assets, doing things one at a time gets old. Select multiple assets at once and act on the whole set: move the selection into a folder, download it, or delete it. Bulk selection is the fast way to tidy up after a project wraps or to pull a batch of brand imagery into a new folder.

The detail panel: how each asset is used

Click a single asset to open its detail panel. Alongside the preview and metadata (filename, type, size, dimensions, when it was uploaded) the panel shows you how the asset is being used: how many prompts it has been attached to and when it was last attached, which project the upload came from, and who uploaded it. This is your safety check before you delete something. An asset that looks idle might be one you attached to a prompt last week, so a glance at the usage line is worth it before you remove a file.

Uploading and downloading

Uploading is drag-and-drop or click-to-pick, the same as the in-build asset picker. Drop a file (or a whole folder) into the library and it's immediately available to every project in the account. A large batch uploads progressively, and you can cancel a run that's still in flight.

Downloading works for a single file or for a whole selection - a multi-asset download comes back as a ZIP, so you can pull your entire brand folder back to your machine in one go.

Who can change what

On a solo plan you are the only person in the account, so you have full control. On Business, the library is curated by the owner so that a team seat can't delete the company logo:

• You, the account owner, manage the library: upload, rename, move between folders, and delete (one at a time or in bulk).
• Team seats get a read-only view. They can browse the library, attach any asset to a prompt, and download files - but they cannot rename, move, or delete anything.

How assets are referenced in a build

When the agent uses a library asset, it embeds the asset in the app so the file becomes part of the build - the splash video, the header logo, the body font. You can point the agent at a specific asset right from the composer:

_"Use [logo-dark.svg] in the header on every screen, and [Inter-Variable.ttf] as the body font app-wide."_

The chip removes any ambiguity about which file you meant, even if you have ten similarly named ones. See Attaching files for the full picker walkthrough.

Uploaded assets use authenticated Appsanic delivery URLs, not public or signed Storage links. Appsanic checks current account access each time bytes are requested, so removing or suspending a team seat also stops that login's asset access. Generated source references deterministic paths under assets/appsanic/; preview, ZIP export, GitHub push, verification, and publish copy the authorized bytes into those paths so standalone outputs do not depend on an Appsanic session.

Under the hood (for engineers)

• Assets live in Supabase Storage keyed by account, with access scoped to that account's logins. Metadata (filename, MIME type, size, mime-family) lives in an account-keyed table, deduplicated by content hash - upload the same file twice and it reuses one stored copy.
• Read/write is enforced by Row Level Security: team seats resolve to read-only, while the account owner gets write. Storage policies back this up at the object level, so a read-only login can't mutate the bucket even by calling the API directly.
• References in the Appsanic preview resolve through an authenticated, no-store delivery route. The URL is an object locator, not a bearer credential, and access is re-checked per request.
• The detail panel's usage view counts how many prompts each asset was explicitly attached to, with the last-attached timestamp, the origin project, and the uploader resolved alongside it.
• Multi-file downloads are streamed as a ZIP assembled server-side so the browser never holds every file in memory at once.

Next

Read Navigation Patterns for choosing the right way to move between screens. Or, for the structured way to hand the agent your logo, fonts, and colours once, see Brand Kits.