Exports & Delivery
Exports package project album results into named ZIP archives. Archive creation and external delivery use persistent database task rows and separate background workers, so they continue independently of the browser and the generation queue.
Creating an Archive
From a project's final-results tab:
- Select specific items, or leave the selection empty to target the full album.
- Enter a package name.
- Choose the raw or optimized asset version where the modality supports both.
- For a project that makes images — an image project, a ComfyUI project with image output, or a Civitai image project — optionally open the watermark screen.
- Queue the export and follow it on Exports.
The server verifies project ownership and resolves the selected album records. Before creating a task it estimates the ZIP size from the chosen asset versions and checks the user's storage quota.
Watermarking is restricted to projects that make images; the server refuses a watermarked export of a video, text or audio album. When enabled with non-empty text, each selected image is processed and stored in the ZIP as JPEG, stood upright first if the photo carries an EXIF orientation.
Export Task Lifecycle
| State | Meaning |
|---|---|
pending | Waiting for an export worker |
processing | Files are being read, processed, and appended to the archive |
completed | ZIP uploaded to the export bucket |
failed | Task stopped with an error |
Workers claim tasks in the database, heartbeat while processing, and can reclaim abandoned work after a stale claim. Progress records the number of album items appended.
The list of items a task archives is stored apart from its status and read only by the worker that claims it, so the Exports page, its status polls and the MCP export tools stay small however large an export is. That list is dropped once the task completes or fails.
The final archive is stored in S3_EXPORT_BUCKET, separate from project/library objects in S3_BUCKET. Its size counts toward the user's archive quota category.
Raw and Optimized Versions
When optimized is selected, the worker prefers the item's optimized object and falls back to the original if no optimized version exists. Raw uses the original output object.
Thumbnails are previews and are not the source of a normal archive. Filename metadata is sanitized for the ZIP, and duplicate entry names are disambiguated.
The Exports Page
The global page lists exports across projects and shows:
- Queue/archiving progress.
- Completed size and a download action.
- Failure messages.
- Active drive or storefront release progress, and the upload history of each export.
- Delete, drive release, and sell actions when eligible.
Download URLs are presigned when the task is read and expire after 24 hours. Reload the page to obtain a new URL; the archive itself is not deleted merely because a link expires.
Deleting an export removes both its database task and its export-bucket object. It does not delete the source album items.
Project Bundles
An album export packages results. A project bundle packages the project itself — its settings, workflow, album metadata, and every media file those reference — into one portable ZIP that can be imported back later, or into a different Remix Studio installation.
Export one from the Projects page: open a project card's menu and choose Export Project. The bundle is built by the same export worker and appears on the Exports page marked Project Bundle, so it can be downloaded, released to a drive, or sold like any other archive.
Bundle Layout
| Path | Contents |
|---|---|
project.json | Manifest: format version, project settings, workflow items, album items |
media/… | One entry per referenced storage object (originals, optimized, thumbnails) |
Every storage key inside the manifest is rewritten to its media/… path, so the archive is self-contained and carries nothing about the exporting installation's bucket layout. Files referenced more than once — a library image pinned in the workflow that is also an album item's context — are stored once and referenced by both.
Bundles carry finished work, not generation history: queued and completed job rows are not included. A media file that has gone missing from storage is skipped, and the manifest is trimmed to match.
Importing
On the Projects page, use the import button in the header (top right) to open Project Bundles at /projects/import, then pick a bundle (or drop a .zip onto the panel). The archive is streamed straight into the export bucket, then a background worker unpacks it:
- Reads and validates
project.json, rejecting archives that are not project bundles or were written by a newer format version. - Checks the unpacked media against the storage quota before writing anything.
- Creates a new project — the source project's id is never reused, so importing a bundle beside its original is safe.
- Uploads each referenced media file into the new project's storage prefix and rewrites every reference to the new key.
- Writes the workflow and album rows.
Progress is shown per file on the import page, and the finished entry links straight to the imported project. Import tasks use the same claim/heartbeat/reap machinery as exports, so an interrupted worker's task is retried. The uploaded ZIP is deleted once the import finishes, whether it succeeded or failed.
Imported album items stand alone — they keep their prompt, settings, and media, but not a link back to the job that produced them.
Bundle uploads are a single request body. If a reverse proxy sits in front of the app, its request-size limit (for example nginx's client_max_body_size) has to allow the largest bundle you intend to import.
Image Watermark Settings
The watermark screen previews the first selected image and configures text, position, padding, font size, opacity, and color. Settings are stored per user and are saved when the export starts.
The selected scope and raw/optimized choice are carried into the watermark screen. Watermarking creates processed bytes for the archive; it does not overwrite the album originals.
To watermark one image without building an archive, use the stamp button on its album or library card. See Watermarking a Single Image.
Drive Releases
Drives are connected on the Releases page — a sub-page of Exports at /exports/releases, reachable from the link in the Exports header. Release history sits beside it at /exports/history. Google Drive and OneDrive are supported, and you can connect as many accounts as you like — several Google Drives side by side is fine.
A completed export can then be released to any of them. When more than one drive is connected, the upload action asks which one to use; with a single drive it goes straight there.
The delivery worker:
- Loads the completed ZIP from the export bucket.
- Refreshes the connection's credentials when needed (and marks the connection expired if that fails, so the UI can prompt for a reconnect).
- Streams the archive to the provider in resumable chunks and records transferred/total bytes.
- Stores the returned external ID/URL on completion and writes a release-history row.
Removing a connection deletes its stored credentials. It does not remove files already uploaded to that drive.
Every drive authorizes over OAuth, so Remix Studio only ever holds a revocable, scoped token — never an account password.
MEGA was removed
MEGA used to be offered as a third drive. It has no OAuth API: connecting an account meant storing its password, because MEGA derives the account's master key from it on every sign-in. That is an unscoped, unrevocable, full-account secret, so MEGA support was dropped and existing connections (and the passwords behind them) are deleted on upgrade. Past MEGA releases remain visible in Release History.
Storefront Releases
When a supported storefront is connected, a completed archive can become a digital product. Product publishing uses the same delivery-task infrastructure but adds product metadata, cover processing, file upload, and publish phases.
See Selling Exports.
Failure and Recovery
Export and delivery tasks store attempts, claim/heartbeat state, and error text. Worker loops can reclaim stale tasks after a process interruption. A failed task remains visible for diagnosis; create a new export or delivery after correcting the underlying storage, credential, or remote-service problem.
Source album files must remain available until export processing completes. Deleting source objects while a task is running can cause the archive to fail.
Related
- Storage — two buckets, quota accounting, and endpoints.
- Projects & Albums — selecting source results.
- Selling Exports — Gumroad product publishing.