GPU support is a MUST have for me. Railway is great for prototyping, but I need GPU otherwise I'm moving to fly.io

Hello !

Issue that I have on Railway metal : https://help.railway.com/questions/deploy-crashed-ff9aaa0e

Otherwise this seems to be good !

Update: we are working on adding (back) Static IPs within the month while also getting the migration flow polished. Expect an update from us here.

Hello, I can't delete a project (i.e. can't click Delete) - anything to do with the upgrade? Thanks.

Hello,

You would need to type out the full message that the prompt asks you to.

My bad....what a noob:) Thanks so much! Cheers!

Hi Brody, another question...I made an n8n workflow and when I copied the chat URL and pasted on a chrome browser, I got attached message. I asked / checked around but don't seem to find a solution. Appreciate your help. Thanks in advance. Cheers!

I'm sorry but we cannot provide assistance for 3rd party software on these forums, especially not in this thread given the subject, you would want to get in contact with N8N's community for help with N8N.

Noted with thanks.

Hi, i'm enjoying Metal and don't seem to be having any issues. The docs mention "Stateful Metal is available starting March 2025" - do we have a rough estimate on when in March? Keen to move my DB and Redis services over to the same region as my API/APPs... Thank you

EDIT: Nevermind - it's there now

Hello. I am trying to move my existing services to Metal, but why don't I see Metal as an option for many of my services? I think it is particularly for services with a volume. Is there a way for me to create a service with a volume on the new Metal?

Hello,

We don't support moving volumes to Metal yet.

In my case:

• API Service & Frontend in Asia Metal

• Database in Asia

  the connection is super slow. Any idea?

Is Postgres going to be available in Metal? Currently I can't create a Postgres database anywhere but US. I'd want to create a Web Service in EU Metal with a Postgres database within the same region.

it's the same also for mongodb, the only available choice is US Oregon (GCP), i'd like to deploy it in EU Amsterdam

We don't yet support migrating services with volumes to Metal.

.

that was about creating a new one, when you create a new mongodb service you cannot get to choose where to deploy it. Then this thread that was closed with a wrong information should be updated https://station.railway.com/questions/will-mongo-db-be-deployable-on-the-eu-dat-395ff426#kd26

We have moved over one application to Metal since yesterday, and I've seen quite some reports from uptimeRobot since that that service was down. Something we rarely experience without Metal.

Or is this unrelated?

Had reports of intermittent "not found" errors for my Strapi application on metal. I had to switch back to resolve the issue. Thoughts?

That was due to a recent incident, not related to Metal, just perfect timing for you to switch back at the same time the incident was resolved -

https://status.railway.com/cm84of0kc0087s34nizyw8iy5

Thanks for the reply, I'll switch back to Metal then!

I’m curious if you provide some insight in this Railway. The difference in uptime is remarkable. But maybe there are other factors at play?

hi, just changed to METAL but it is slower than normal, could this be fix

the network too slow I'd say...

Hello!!

According to the Railway Metal documentation, starting today, March 14, 2025, all new deployments with volumes for Trial and Hobby plan users should be running on Railway Metal by default.

My question is: can we now manually migrate existing projects with volumes to Railway Metal regions, or is this transition only for new deployments?

I’d appreciate any insights from the Railway team or other users who have already tested this transition. Thanks in advance!

I have a problem with estimating the percentage of capacity on Metal. In my project all servers and databases are transferred to Metal, but still - Railway Metal discount displays that I have only 64% of servers on Metal, but I have all 100% translated, what could be the problem?

The metal discount will be applied if >= 80% of your usage is on metal, not the amount of services. This means that in the current billing period, 64% of the usage is from metal, while 36% of it is from GCP.

If Metal refers to setting up our own servers, why isn't there a 50% discount on RAM and CPU usage, or why isn't it made completely free? Think of it as if we have purchased a server—why isn't there a standard payment option?

I am not sure if I understand your question correctly, but Railway metal refers to Railway's own hardware. Railway charges you based on your usage and you only pay for what your applications use. Railway running its own hardware isn't free, but it allows Railway to have more control over some aspects of the pricing, which is why the pricing for egress and disk have been reduced by 50% and 40% respectively. While the pricing of the CPU usage hasn't changed, the CPUs on Railway metal are more powerful with higher core count and better performance per-core, meaning that your services will run faster.

I have all services that are deployed on Railway using the Metal New location in California

While this may be true now, what I meant is that from the start of the current billing period until now, a portion of your services were on GCP and therefore didn't count towards the metal usage in your total usage. Again, it's not about the amount of services, but the usage on metal.

Since all of your services are on metal now, expect your metal usage to increase over time.

This has already been asked above, but my colleague did not receive a proper answer. How can I start a Postgres service under the Hobby plan in the EU region? The changelog mentioned "Hobby Metal Volumes," but I don't see such an option.

You can now migrate non metal services with a volume (such as a Postgres database) to any metal region. As for creating a new Postgres database in the EU metal region with the hobby plan, you can just deploy it from the dashboard and depending on the scenario, do the following:

• If the newly deployed Postgres database is in a non metal region, you can migrate it to the EU metal region under Settings > Regions.

• If the newly deployed Postgres database is in a different metal region, you will have to delete the attached volume first, change the Postgres database's region to the EU metal region under Settings > Regions, apply the changes, reattach the volume (mount path /var/lib/postgresql/data) and finally apply the changes again. This is because metal to metal volume migrations are not available yet.

You may have to enable the metal volumes feature flag first under https://railway.com/account/feature-flags

Hi, i just tried with mongodb, i was able to delete the attached volume and change the mongodb region to EU. But as soon as i try to attach a new volume (i cannot choose where to deploy it) it automatically change back the region of mongodb to US (non metal)

Hey massalinux, have you enabled the metal volumes feature flag under https://railway.com/account/feature-flags? Also, you should be able to just migrate your mongodb from non-metal to metal, deleting the volume is not required in this case.

Hi, I'm really happy with Railway and EU Metal so far, thanks. I did have one question though about whether any data is available on server / electricity carbon emissions for EU Metal, compared with AWS or Google Cloud? Hoping it's also low carbon... Thanks

Thank you for detailed answer, turning on the feature flag solved the problem.

Yes now it works, in fact the flag was not enabled, but i was pretty sure in the past days the flags were different (like a generic optin into new feature). I had to delete the "default" volume and create and attach a new one though because was failing during deployment.

if it helps here the screenshot

Do we have hope for Static Inbound IPs in the short term? Thanks

Hi Railway Team,

I recently migrated my Spring Boot 3 backend and PostgreSQL (with volume) to Singapore Metal, but I'm facing performance issues. The DB/Volumes on Metal is slower than on Singapore Non-Metal, and I'm getting connection timeouts like "Connection closed." I suspect it might be due to virtual threads opening too many connections—but it something that doesn't/never happen in Non-Metal. I also suspect that the backend, DB, and volume seem separated even though they're all on Metal.

I've had to roll back because of the latency issue. *sorry, I can't attach any logs since they were all lost during the migration haha.

Any help would be appreciated!

Thanks

Experiencing the same latency with a service we have just moved to Railway in Amsterdam.

Using PostgreSQL on Metal is noticeably slower than using PostgreSQL on non-Metal.

This is a staging project so we tried to recreated the whole project on Metal and Non-Metal to do the comparison.

We would like to know whether this is an identified issue you are currently working in.

Thanks

Same issue as above, for the new metal EU-West Amsterdam region. All my services and volumes are running in the same region. Previously (on non-metal, oregon), adding a product to the cart (MedusaJS) took around 1.5 to 2 seconds — now it takes 30 seconds.

I'm experiencing a similar performance issue. My Next.js frontend, connected to PostgreSQL/Volumes on Metal, is slower compared to Singapore Non-Metal.
Navigation used to be super fast on the frontend, but now it's got a one-to-two-second delay.

So that we have something to look into, can y'all link to your projects that are slower? specifying the environment and affected services would be very helpful here.

Here's my project. Let me know if the URL alone is sufficient, or if you need anything else. I guess it has to do with backend, connected to Postgres, and a slow bucket. The "Estimated usage" is also very high compared to what I was paying before.

Here is mine. As I commented previously, this is a Staging environment project. We don't want to migrate some of our other projects until we find that we don't suffer from performance problems.

This is mine
Production environment:
I've migrated all the apps to Metal. Next.js communicates with Directus (using PostGIS) within the internal Railway network. While the frontend (non-Metal) responded much faster, the Metal version is slower, and the issue is still unclear.

Railway automatically switched some services to Metal; please do not do that! These services are connected to other services that use volumes and don't have the option to go to metal.
Also, the rollback feature is not working correctly. My services were on Amsterdam (Not metal), but after using the rollback button, they were placed in the US (not metal).

W.r.t to the reported performance issues, we are looking into the reports. We will update you all on what we see.

You claim that Metal will be faster than older servers. What is this based on? Have you measured the response time for the same location? According to what test data is it faster?

For volumes, we've measured IOPS and write throughput benchmarks for metal.

For services, we've also measured multicore CPU going off various tests (using compression as the benchmark)

We'll have a look into the reports here

If you're hosting your application on non-metal, and your database on metal, you will indeed suffer from latency

You need to move everything over to metal (so that they're in the same datacenter), and then run this test

It would be help if people could provide a comparison between applications/environments

One on metal, one not on metal. And ideally with benchmarks through an endpoint that can be tested

(We will look into this regardless BUT, the above is super helpful as we look to track this down)

Here's a very simple benchmarking project I just put up that does 10k random writes

First attachment is metal, second is cloud. So, metals definitely faster (and we'll tune it to make it even faster during the beta)

If you have any counter examples plz would love to see them.

Just checked your project; you're making requests to the public network. You need to use the private network. Bonus; you'll save a bunch on egress!

The reason your requests are blowing up is because you're taking a request from the metal boxes, to the GCP edge network, and back to the metal boxes

Thanks for pointing that out. I'll adjust things on my end and get back to you.

Hi @Jake,

Sorry for the delayed response

Below is the benchmark comparison between the two environments:

1. Backend (Singapore Non-Metal) with Postgres (Singapore Non-Metal)

   • The left screenshot represents this setup.

   • The service processing speed is around 15 seconds per operation, with each thread opening a connection to the database.

2. Backend (Singapore Metal) with Postgres (Singapore Metal)

   • The right screenshot represents this setup.

   • The average processing speed is around 40 seconds per operation—about 2.5 times slower than the Non-Metal setup.

Additionally, I observed a request timeout in one of the threads (a 30-second timeout while waiting for a new connection).
For both benchmarks, I used HikariCP with a connection pool size of 10.

I hope this detailed comparison helps in tracking down the issue.

Thank you for the benchmarks here, this is very helpful, Jake might want additional information, but for now, can you tell me if both of these tests were done with the communications done exclusively via the private network?

I'm very sure Brody that I'm using a private internal network
for example: jdbc:postgresql://<my-postgres-name-xxx>.railway.internal:5432/railway

I have a hunch that my backend in Singapore (Metal) and my Postgres (Metal) "might" not be on the same connection

Static IPs are now live!