fal media lasts 7 days by default; Sume URLs do not expire
fal keeps generated media on its CDN for at least 7 days and lets you set a lifecycle per request. Sume media.sume.com URLs do not expire. What to store.
How long does fal keep generated images and video?
At least 7 days by default. fal's FAQ says generated media files (images, videos, audio) are stored on the fal CDN and are available for at least 7 days by default, and that you can control the retention per request with the X-Fal-Object-Lifecycle-Preference header. Sume's generated media URLs on media.sume.com are documented as not expiring.
That difference matters less than it looks if you copy files on completion, and more than it looks if a render sits in a database row for a month.
What else does the fal FAQ say about access?
Media URLs returned by fal are publicly accessible by default: anyone with the URL can fetch the file until it expires. Files are hosted under v3b.fal.media. You can restrict access with ACLs so files are private to your account, shared with specific users, or hidden. The page does not state how long request payloads are retained, and it advises downloading anything you need beyond the default window.
I am not going to guess at fal behavior beyond those lines. If you rely on a lifecycle value or an ACL, read the header documentation on fal's own site before shipping.
What does Sume do with result URLs?
Completed Sume jobs return artifacts with a url on media.sume.com, per Jobs and results. The run receipt page says those URLs are durable, do not expire, and are public to anyone holding the URL. Sume documents no per-request lifecycle header and no ACL mode for them in those pages.
So Sume trades configurability for permanence. You cannot shorten a lifetime to reduce exposure, and you cannot privatize a file in place. If you need either, store a copy in your own bucket and serve that.
Compared
Read the cells as "what the vendor page says", not as a ranking.
| Question | fal | Sume |
|---|---|---|
| Default lifetime | At least 7 days on the CDN | URLs do not expire |
| Per-request control | X-Fal-Object-Lifecycle-Preference header | None documented |
| Default access | Public to anyone with the URL | Public to anyone with the URL |
| Access restriction | ACLs: private, shared or hidden | Proxy or copy the file yourself |
| Request payload retention | Not stated on the FAQ | Not covered here |
How should a pipeline handle either?
Pick the rule that works for the shorter lifetime and apply it to both providers, so a switch does not change your behavior.
- On completion, copy the artifact to your storage and keep your own URL as the source of truth.
- Store the vendor job id next to it for support and billing lookups.
- Never put a vendor media URL in a long-lived email or a CMS field if the vendor documents an expiry.
- Decide per customer whether a public URL is acceptable; public-by-default is true on both pages.
Sources
Related posts
More in Comparisons
- fal proxy with x-fal-target-url vs keeping a Sume key on your server
fal documents an 8-step proxy that reads x-fal-target-url and adds a Key header. Sume has no browser SDK: you proxy your own route. A minimal comparison.
- fal's hint pins a runner; Sume has no runner choice
fal's queue submit takes a hint that routes to the runner used before. Sume hides providers and runners. What to do when you need affinity.
- fal queue has no size limit: what Sume does instead (queue_full)
fal's queue docs say there is no queue size limit and requests are never dropped. Sume caps accepted jobs per plan and returns 429 queue_full. What that means.
- fal low priority and start_timeout vs Sume queue-first admission
fal queues accept a low priority and a start_timeout that 504s. Sume has neither: it queues by plan and rejects with queue_full. What to do when work must wait.
Written by Sume