hello,

can you please make sure all your services are in the same non-metal region

as for meilisearch, seems like it got a bit greedy

Hey Brody! Thanks for checking in. 🙂
Amazing, changing the regions fixed the roundtrip delay ⚡

How do I ensure my services are in the same region? This project was launched from a template, and by default the the services was not on same non-metal region.

Could you elaborate a little on the meilisearch greediness? I am using a standard docker image, I never had issues with it before today (but havent tested it in about 10 days). I have been using the :latest - but I have also tested getmeili/meilisearch:v1.11.3 - which I know didn't cause problems just a few weeks ago, and this image also crashes now (after some time, length seems a bit random).

New hobby deploys will buy default go to metal, this isn't something configurable at the moment.

oom_killed = out of memory killed, aka it used more than the allowed 8gb and was shut down

Aha, okay! I see all the docker services (postgres, minio, meiliseach, redis) are all deployed in Oregon (non-metal), while all the git services are deployed on the new inhouse metal servers. 🤔 I received quite a few emails from people asking me why their webshop is slow - so for now I will tell them to manually change the regions. Do you know if there are any plans for changes to this, so manual steps wont to required?

phew 8 gb of memory use 🤢 that's very odd. it should not use that much

I will ticket a thing that says "don't deploy to metal if template contains services with volumes"

metal doesn't support volumes yet hence the services with volumes still being on gcp

you are using the private network for all interservice communications right?

OK! It's exciting with the metal servers. Will there be any metal servers in the EU? (GDPR compliance attractiveness)

No, not everything is private network yet unfortunately - but this is on my list of things I want to imrove. There's a internal connection between the postgres database and the backend. But redis, is currently over public, same goes for the api between the storefront app and the backend service - because the backend also hosts a dashboard web app - but I do have an idea for how to solve this, it's just work that I havent gotten to yet

why is redis public?

and yes hobby will get an EU and Asia region, though I'd have to say that if GDPR mattered, that's probably not a hobby project anymore?

No that's unrelated… just went through a whole proces trying to figure out if supabaser was GDPR compliant and had to involve 3rd party specialist, who ended up concluding that they weren't. And I saw that there recently was released a self managed supabase template here, on Railway, so that could be one way of running it for customers in EU that needs GDPR compliance - if Railways metal server do not share user data outside of the EU ✌️

Regarding redis, that's simply just because I havent had the time yet. switching to the private url broke the app, but I know there's some documentation somwhere gonig over exatcly how to use redis within the internalt network

this documentation?

ticket just created btw!

Yep that's the one!

Hello @rpuls - sorry for the long wait, but this has been fixed, if a template has volumes, all services will deploy to the same GCP region

No worries! I created a little screen recording guide, how to manually set same regions. And I did notice some days later that deployments were automatically on same region. ✌️thanks for following up though 😊

we only just made this change today

Really 🤔? I had deploys for… 2~ weeks where all services were same regions

yep just today

!s