Media Storage
This page documents the current backend storage behavior at a developer level without exposing secrets.
Storage model
Fangate uses staged processing plus final asset storage.
Important backend concepts:
media_process_diskuploads_final_disk- upload-session staging storage
- Fangate-controlled public/signed access routes
Current behavior
The backend can process media on one disk and store final assets on another.
That matters for:
- upload-session finalization
- preview generation
- production private-S3 access patterns
Mirror-to-final behavior
Uploads are mirrored to the final storage disk, so content ends up available through the expected final-storage path.
This is especially important for:
- older mobile or Flutter upload paths
- sales-link access after purchase
- consistency between preview/source storage and final product availability
Public vs signed access
Client apps should not construct media URLs manually.
Use:
- URLs returned by the backend
- Fangate-controlled access routes for purchased media
- signed/final URLs where the backend provides them
Do not assume:
- raw S3 object URLs are always public
- preview and final source URLs are interchangeable
- storage paths are stable across environments
Upload-session staging
Upload sessions write to staging storage first, then finalize into Fangate's managed asset flow.
This allows:
- resumable uploads
- multipart uploads
- remote imports
- async finalization
Buyer access and sales links
Buyer-visible access should come from Fangate backend logic, not guessed storage paths.
Relevant routes include:
/download/{media}/view/{media}/access-media/{transaction}/{media}
Integrator guidance
- treat all media URLs as opaque
- do not persist assumptions about bucket names or access policies
- do not infer product availability from preview availability alone
- when debugging media issues, compare preview URL behavior, source URL behavior, and product access-route behavior separately