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 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.
- fal queue_position and logs vs Sume job status, events, usage
fal returns queue_position, runner logs and inference_time. Sume gives status, an events timeline and per-job usage. Which one tells you why a job is slow?
- fal webhook redirect 3xx is never retried: what Sume does instead
fal treats a 3xx from your webhook URL as a permanent failure. Sume does not follow redirects either, but counts a 3xx as a failed attempt, not an end.
- fal webhook ED25519 and JWKS vs Sume's HMAC-SHA256 check
fal signs webhooks with ED25519 keys fetched from a JWKS URL. Sume signs HMAC-SHA256 over timestamp.body with a workspace secret. The two checks, side by side.
Written by Sume