Best practices for keeping self-hosted Supabase deployments current when official docker-compose.yml lags behind latest releases

[gezuka77]

Title

Best practices for keeping self-hosted Supabase deployments current when official docker-compose.yml lags behind latest releases

Description

I'm running a self-hosted Supabase deployment and trying to establish the best update strategy. I've noticed that the official docker/docker-compose.yml in this repository often contains older versions compared to the latest releases available on Docker Hub.

Current Situation

• Official docker-compose.yml uses older versions (e.g., postgres:15.8.1.060, gotrue:v2.177.0)
• Docker Hub has newer releases available (e.g., postgres:15.14.1.011, gotrue:v2.180.0)
• Self-hosting documentation recommends following the official docker-compose.yml versions

Questions

1. Version Coordination: Is there a specific reason why the docker-compose.yml versions lag behind the latest Docker Hub releases? Are these older versions the "stable/tested" versions for coordinated deployments?

2. Update Strategy: What's the recommended approach for staying current?

   • Should we stick strictly to docker-compose.yml versions for stability?
   • Is it safe to update individual services to latest versions?
   • How do you handle the coordination between postgres, auth, storage, realtime, etc.?

3. Release Process: Is there a release schedule or notification system for when the official docker-compose.yml gets updated with newer coordinated versions?

4. Testing Matrix: Do you test specific version combinations, and is there a compatibility matrix available for self-hosters who want to stay more current?

5. Automation: For those using tools like Renovate/Dependabot, what's the best practice?

   • Disable automated updates entirely?
   • Allow updates but only for specific services?
   • Follow some other strategy?

Current Approach

I've disabled all automated updates via Renovate and am manually updating based on the official docker-compose.yml, but this means running significantly older versions for extended periods.

Additional Context

• Running production workloads where stability is critical
• Want to balance security updates with deployment reliability
• Using GitLab CI/CD for deployments with health checks
• Managing ~40 other containerized services where individual updates work fine

Would appreciate guidance on the official recommendation for self-hosted update strategies and whether there are plans to improve the update experience for self-hosters.

---

Environment:

• Supabase: Self-hosted via Docker Compose
• Platform: Linux/Docker
• Deployment: Production environment

[Inspirational-sausage-dog]

Yeah, it is very unusual that new versions haven't released on this repo since May because documentation says

For security reasons, we "pin" the versions of each service in the docker-compose file (these versions are updated ~monthly).

If their policy changed, I don't see that is reflected anywhere. At least to my knowledge. An update on current state of self-hosting would be very appreciated.

[aantti]

I've updated the docs a little bit over the last few months, check the following:

• https://supabase.com/docs/guides/self-hosting/docker#updating
• https://github.com/supabase/supabase/blob/master/docker/README.md
• https://github.com/supabase/supabase/blob/master/docker/CHANGELOG.md

[rmarquois]

In the latest documentation, I see that there is a quick start guide for Linux based on new scripts setup.sh and run.sh.
Do you plan to add an update.sh script to keep up to date a self hosted project ?

For now, we have to manually change versions docker-compose.yml. But what's happen if nested directories or other files have changed ?

[aantti]

It is definitely a burden. Let's say this - I'm looking into how to improve the release process. There's quite a bit of suggestions regarding the update process in #39820, but I don't have a good solution yet.

[aantti]

But I'll work on it shortly :)

[rmarquois]

Happy to hear this! Can’t wait to see that. Thanks for you work.