[Storage] How to handle/bust Supabase's CDN cache for public URLs of replaced files with same name

[bennettdams]

Update: I created a feature request for this.

---

Maybe I'm missing something, but I would like to ask for your solutions for the following problem:

I would like to e.g. save avatar images in the storage.
In a perfect world, the image file name is the user ID, which makes it easy to handle the access rights for PUT/POST/DELETE requests.

In my app, a user can upload an image, which is uploaded to the storage via the Supabase client like so:

await supabaseServer.storage
    .from("...")
    .upload("user-id-123.jpg", avatarFileParsed, {
      upsert: true,
      contentType: 'image/jpg',
    })

This works fine.
Now, I use the image's public URL for Next.js' image component, which also "caches" the image locally, but this is out of the scope of this question.

Looking at the response of a request for a storage image's public URL shows that it is cached via Cloudflare. It also has the cache control set for that (e.g. maxage).
This means that even though a new image has been uploaded to the Supabase storage, the CDN still uses the old image and therefore the image you receive for a public URL is also the old one - the app therefore shows the old image, even if a user clears his browser cache.

Some thoughts:

• Can one somehow use the cacheControl parameter of the upload function to bust the (CDN) cache?
• Can one maybe use URL params (at the end of a public URL) to trick the app to not use the cached version?
• Is there another way to bust the (CDN) cache?

What are your solutions to this problem?

---

My solution to circumvent this problem right now is to create a random ID for the filename on every upload and save that ID for each user in the database. That way, the CDN cannot kick in, but this is obviously far from perfect, if not only for the additional code I had to write.

[GaryAustin1]

2nd seems most common. The Supabase UI uses it the storage tab to view files.
?bust=Date.now() or similar.

Edit: But if you use that for general image access it means you have no cacheing of images at all.

[bennettdams]

Good to know. The problem with that is that you will always miss the cache with that approach:

So this works great for the use case of e.g. Supabase's dashboard, but in a real-world app, where you don't know whether the cache should be fresh or not, I deliberately want to hit the cache if possible. It's not like you can bust the cache with the URL params "once" after a user uploads a new image - you'd need to always use the URL params and therefore will always miss the cache.

[GaryAustin1]

Yeah, you don’t want to use it certainly for accessing other peoples avatars. You could limit it to just the current user, or just if they replaced their avatar, for the current session or even with updated date stored with user info and only use it for update + cache time and then normal url after. Basically if their profile was updated in past hour bust their image (and if you generate url once at start or change (versus in the image call) then it will cache for that session.

[bennettdams]

Ye, I think being able to do that programmatically via Supabase could be a nice feature request for that use case, because we as developers know exactly when busting the cache would be necessary. Edit: Created a feature request: https://github.com/supabase/supabase/issues/5740

[rahul3v]

Well, In that case you can store something as update_time under your DB, (as we prefer to do, when we update anything...right !)
and use that as a reference under any image url <Image_url>?t=<update_time>, that will reduce a lot many hits, and also able to use cached file

[bennettdams]

Yes, I already have such update_time in my DB already, never thought to use it the way you described though! I think this is an easier approach to the one I described above with a random ID that changes for every update.

If I had to start from scratch, I would probably rather use your proposal instead of mine. Nevertheless, I think it would be better to have this functionality (bust the cache programmatically when needed) still would be better to be part of Supabase, so one does not need to always pull through this information in its own code.

[rahul3v]

Yup, it will save you huge bandwidth and cost :)

[FileSoft-us]

Well, In that case you can store something as update_time under your DB, (as we prefer to do, when we update anything...right !) and use that as a reference under any image url <Image_url>?t=<update_time>, that will reduce a lot many hits, and also able to use cached file

thanks it's the best solution to use ?t=<updated_at> from DB and nice for realtime subscribtion

[leblancmeneses]

For those in angular:
[ngStyle]="{'background-image': 'url(' + (data.media.image | supaStoragePath | cacheBust:data.media) + ')'}"

import { Pipe, PipeTransform } from '@angular/core';

@Pipe({
  name: 'cacheBust',
  pure: true,
  standalone: true
})
export class CacheBustPipe implements PipeTransform {
  transform(url: string, entity: Partial<{created_at: string | null, updated_at: string | null}>): string {
    if (!entity || !url) {
      return url || '';
    }

    return `${url}${url.includes('?')? '&':'?'}t=${entity.updated_at ? new Date(entity.updated_at).getTime() : entity.created_at?new Date(entity.created_at).getTime() : 0}`;
  }
}

[yndotdev]

I also store my file name as the user's uuid. At the end of the filename, I've appended "?updated", like so:${user_id}.jpeg?updated, and it always returns the latest image. Hope this helps?