What can we expect from choosing a Metal region? Better performance? Any risks?

I notice it's still in Beta, also wondering if there are any tradeoffs to consider?

Yep still in beta but for what it's worth, we have not had any issues since we released the option!

Trade-off would be that the metal region doesn't support services with volumes yet, so if you have a database and app, you would want to keep both on the same non metal region.

my application has been crashing unexpectedly and I find it difficult to switch.

No way to change region of database

I can't change my django server to the us-west1 Oregon region again and this is causing a lot of slowness because I have a DB and a redis in this Oregon region and my django server in us-west2

It appears that deployments using railway.json config file are no longer being respected by metal(beta) changes.

Users can only deploy to a single region. Please create a team to deploy to multiple regions.

I have us-west1 in my railway.json config but it keeps getting changed to us-west2 since I am on the Hobby plan and its trying to force me onto the metal(beta). I do not wish to move over to the metal(beta) yet as I noticed a 200% increase in pricing.

I am growing increasingly concerned about the amount of changes being pushed onto Hobby tier user that are resulting in performance, pricing impact, and added operation cycles to get past deployment failures.

I am having issues with this as well. It seems to be forcing me on to this region, yet my database is in us west oregan. I do not want to use metal. Please help?

I got the same issue

+1 -- seems like my service is forced onto this metal beta region and it's broken my app -- I see an erroneous deploy I did not initiate and I cannot move this service to another region

I also had a very bad experience with this forced migration, just like @henjesus. My application was in one place and my database in another, and requests that used to take less than 1s, now take 3.5 (I'm connecting to the database with the private/internal URL). If I want them to be in the same place I'll be forced to change my plan, for the wrong reason. I think you made a big mistake on this one.

Congratulations, I was forced to switch to the pro plan and it worked. My requests went from 3.5s to 600ms

We are having the same issues (on the Hobby plan) with services being forced to us-west2 and neither manually setting the region to us-west1 nor setting the region in the railway.json is working

All of my services has been impacted with this force migration, DB and instances are in different regions and there is no way to change, requests are taking more than 6s to complete

Same here. My Node server was forced into a different region (us-west2) than my Postgres instance (us-west1), causing huge delays in many of the API responses. I ended up upgrading to the Pro plan. I hope such changes will be notified more carefully going forward. I love using Railway.

I am having issues with this as well. It seems to be forcing me on to the US West (California, USA), yet my database is in us west Jregan!!!. I do not want to use metal. The website's speed has significantly decreased. Please help me

+1. Can't change to the same region as my db, adding 20+ms to every request at least.

This forced update is making our services unusably slow (node app and Redis cache are in different regions), and changing the region of my apps back to non-metal (US West / Oregon, USA) does not work. Please tell us how this can be fixed, we are losing clients over this.

This is literally impossible for the reasons mentioned in my post above. It always changes back to a different (metal/beta) region.

When you upgraded to Pro, how did you manage to migrate your projects/services? Did you have to set up every service again?

Going to close this thread out as it is no longer productive and has gone quite off topic.

Your databases and services are in the same region, just different zones.

The slowness issues can be solved by simply connecting to the databases via the private network.

Connecting to the databases via the public network is the issue here, not the difference in zones.

https://docs.railway.com/guides/private-networking

Hi.

I've re-opened this thread. We've also had a discussion internally about "locking threads". They will now require oncall escalation on the Logistics side.

Now, want to say we're sorry about any problems caused by this.

While we try to keep things "together", I will state that Hobby should be intended for Hobby workloads. We try to be pretty clear about that one in both the name and the pricing page.

However, the latency being 1-2s+ is super weird. This COULD be due to the public networking usage. We tested this for us-west and the latency over the private network was 10-30ms. If you're seeing multi second latency on private networks, please link it here and we will have a look.

Finally, you should be 100% able to "toggle back" your instance to non-metal. If not, please let me know and I will escalate that to product oncall.

Once again, apologies on this.

I keep my personal account on the hobby plan, and can see the ability to redeploy back to US West (Oregon)

Brody just pointed out to me that, while the option exists, clicking the option won't actually set it for the users; they'll simply be forced onto metal

We will roll out a fix for this today

A fix has been rolled out. You should be able to revert away from metal if you're migrated to it.

New service creations will default to metal (if stateless). Until we allow users to deploy databases onto metal (January), we will aim to migrate only projects which don't have dependencies "cross regionally" on the US West servers

Our goal is a seamless compute experience. We've talked a bit about this internally, and have plans to make this more seamless in the future

Thank you for the relatively quick fix and explanation afterward. Everything sounds reasonable.
Initially, I thought that was a strategy to move all the hobby users to Pro. But now it looks like it was an unexpected consequence.
Thanks to the Help station and users who have declared this problem for several days

Peace out!

Thank you Jake. Seems like setting the region back through the GUI works again. However, setting the region back through the railway.json config doesnt seem to work for us yet.

Hey folks, I'm going to close this thread in favor of a new one where Railway Metal isn't "beta" anymore per se.

Please head over to https://help.railway.com/questions/feedback-railway-metal-a41f03a1 to continue the discussion.

And thank you everyone for sharing your feedback here. We now have full documentation (https://docs.railway.com/railway-metal) on what you can expect out of Railway Metal, what's going to happen, and steps you can take if things go awry.

We'll do our best to make this as seamless as possible. In particular, for the increased latency issues, we're going to address it by leaving those services alone:

For services in US West (Oregon), Railway will not move your service to Railway Metal if your service references another service with a volume. This is to prevent any cross-regional networking latency spikes for your service. Refer to this FAQ for more information.

Please let us know in the new thread if you have further questions or concerns