Template:

https://railway.com/deploy/5ArOQi?referralCode=Hwex-j&utmmedium=integration&utmsource=template&utm_campaign=generic

What are the specific services that you need to redeploy after DB is healthy?

Realtime, auth, and storage I believe. Lemme do a fresh deploy

I was correct. Supabase Storage, Supabase Realtime, and Supabase Auth have all failed, while Postgres was still building

Project ID 4e1a46ae-9c26-4da7-bc14-48294574dfc7

Im fairly sure that services connected to other services via environment variables wait for the first service to deploy before deploying themselves.

I'm genuinely curious as to what is lacking in the pre-existing supabase template that warrants a new supabase template?

This template includes everything other than analytics. Storage, imag transformation, a nextJS frontend app with all the auth features built in, edge functions. Not only that but I've made the repo structure what I call a "local-first" monorepo. every service points to a directory within the repo, such that when you add app logic (email templates, edge functions, DB migrations) it triggers a rebuild.

This is the best local dev experience for Supabase I've ever come across

I invite you to deploy my template and offer some advice ! That's why I started this thread lol

The issue with the previous template, other than not implementing the entire framework, was that many of the services point to docker images. I still use the official images obviously, but I do it by using the "build" context feature in docker composer yml. Every service has a directory, with a Dockerfile inside that uses the Supabase official image as a base.

Please check it out on GitHub. Anyway, yeah I'd really like to solve the deployment order

IIRC they did that because not everything was possible to deploy, some stuff required shared volumes.

The storage service and image proxy share a volume when they use the file system mode. I included MinIO in the template and they point to it to read and write objects

Sounds good

I also included the ability to edit transactional email templates out of the box, which has been a notorious problem most people pull their hair out over and not even Supabase's hosted platform makes that experience nice

So what's a path forward here? Are you able to check what happened in the infra provisioner that built the project from the template? Inspect my configuration of ENV vars? Why would services be building before the services they depend on?

I've deployed the template again, and having the same issue.

These services reference ${{Postgres.RAILWAY_PRIVATE_DOMAIN}} in their own ENV vars, and yet they build and deploy first. I think I'm out of options without any "insider tips" into how the infra provisioner determines what order to build services in.

This is a blocker for the publishing of my template, would really appreciate a direct look at this or some insider knowledge from an engineer who knows what the system is doing. Thanks for all your hard work!

If two services reference each other then they will start to deploy at the same time (but they would also finish at different times), this is the only thing I can think of as to why your deployment order is out of whack.

These services reference Postgres, but it doesn't reference them. Really a curious situation…

Yes it does.

${{Kong.JWT_EXPIRY}} & ${{Kong.JWT_SECRET}}

1. Kong isn't the service that's crashing.

2. I just moved the 4 remaining variables into Postgres so it no longert references a single other service. Let's see what happens

Things are looking good, Postgres building first and everything waiting

1. Not sure the relevance of that, you had Postgres referencing Kong

2. Postgres was only referencing 2 variables from Kong

Oh right, postgres only needs those 2 JWT_ vars. I moved the ANON_KEY and SERVICE KEY over to Postgres because then the only 3 vars a user needs to manually set live on the same service and go together mentally.

Curious as to why Postgres needs JWT stuff?

There's a JWT extension used for Supabase auth. signing JWTs for users' access tokens, looking at whether a session has expired

Things like that

And it looks like we got a successful deploy! Woohoo!!

I believe that what was happening before, is that even though Storage/Auth/Realtime all were supposed to wait for Postgres, there was another dependency chain that was given precedence for arbitrary reasons: Postgres waited for Kong which waited for Storage/Auth/Realtime. Just bad luck

In my opinion, the build order for services could be made more configurable and deterministic. But we did it! To really have a service deploy first, try and have it depend on no others if possible

About to test ejecting. Fingers crossed!

🤞

And the new fork has a little hash at the end so I can fork my own repo. Love it 🙂

I intend to build many products of my own on top of this template and it requires ejecting every time

Sounds good!

I think we can close this thread, thanks for your time and all your hard work 🙂

!s