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!

It happens to my app too, do you have solution?

On the usage screen, we have the section: Railway Metal discount. This includes the percentage of services that use Railway Metal, but it doesn't specify which ones are missing. Would it be possible to add a feature that specifies which services have NOT been migrated to Metal, so we can go directly to them to migrate them? In my case, I checked EVERYTHING, and I still have 86% (sad face), I don't know which one I'm missing (more sad face).

Hey, I'm eligible, yeiiii, but my OCD is asking for that 100%

Hey root101, it's not about the amount or percentage of services on metal but the overall usage on metal. You had some services that were on non-metal in this billing cycle. If your services are all on metal now, expect your metal usage to increase and to be 100% in the next billing cycle as all of your usage are from metal in this case. Either way, your metal usage is >= 80% and therefore the metal discount will be applied regardless.

It all make sense now. thank you

Hello, my postgree db dont have the options to change for the metal Region. are there some options for making it? I noticed that the connection got slower after the railway metal So I would like to try the postgress using the same region. Thanks

Hi, I recently found out my service (already manually set to run on metal) was automatically "upgraded" to metal two days later causing me to lose the state it processed within those two days.

For my project bc643afe-...-7b8efa048980

I made a deploy on Mar 10th 2025 at 6:28AM GMT+1 and explicitly set it to run on Metal (ee63adb).

This deploy had region (us-east4-eqdc4a) which is a Metal deploy. I didn't wish for it to be manually redeployed as I would lose valuable state as the application gets initialized from data in the repo (which would be as at the state from Mar 10th).

[I am aware storing data in the repo is bad, and it was for that reason I put in the effort to ensure my deploy wouldn't get picked up for redployment. I am working on a more persistent state, but as we all know these things take time.]

I only just found out that two days later (Mar 12th 10:11PM GMT+1), a redeploy (e97b9d8) was done (also region us-east4-eqdc4a) causing me to lose all the state between the two deploys.

Are there things I could have done to prevent this, probably. But I thought it was a safe enough assumption to make that the platform wouldn't make such a mistake.

In the end I am at least glad it wasn't a longer duration so the loss is less, but all this message is saying is to respect people's workflows as we can't generalize on things like this.

Hey renatoaugustii, please make sure that you have the metal volumes feature flag enabled. This can be found under https://railway.com/account/feature-flags.

Hi do we have to do anything else other than this to resolve the issue

Hi, I don't know what the difference is between metal and normal instances as I have been trying to check what the difference is(capabilities wise) after migrating my typesense project to metal and it just abruptly crashes.

At the time of this writing, you should be able to freely migrate your volumes across metal regions. Keep in mind that you may have to enable the metal volumes feature flag first, which can be found here: https://railway.com/account/feature-flags.

Hey khabubuphathu, (Railway) metal refers to Railway's own bare-metal servers, as opposed to non-metal, which relies on third-party hardware.

Improved Performance: Services on Railway will run faster. Our new CPUs are more powerful with higher core count and better performance per-core. Volume read/write performance will also be significantly faster as all of our disks are NVMe SSDs, which are faster than the disks we could offer before.

More on Railway metal can be found here: https://docs.railway.com/railway-metal.

Can you provide more details on the abrupt crashes occurring on metal?

Hi, the railway metal for me it was a bad experience. I changed my service to metal servers but it was impossible to get data from prostgree database, simple queries taking a long time, about 45sec to get 15 itens. I did rollback to simple servers without metal, and, perfect, queries fast getting data by a year, spend 30sec or less!

Hey, did you also move your database to metal? This would explain the increased latency due to two different physical locations.

Yes, i moved my data base as well, but the results is too bad.

It's quite possible you are connecting to the database over the public network instead of the private network.

How can I test using private network? Because the link to my database is a direct connection using user and password in my Django app. Can you tell me an article to resolve it?

None of the Railway Metal region options show up for my services. What does that mean? I just get one deployment region. Is this because my app was created from a template maybe?

I have the same experience with a project with PG 16 and Odoo (I already raised a support ticket). Are you also querying from a WSGI Python application?

I'm querying over the internal network and I'm using Metal edge.
Project: 39762d39-8f0e-4230-92f2-1bd77dc2e537
Env: 3d942ca8-6591-4137-8f85-6df584405e6e

after migrating i'm also seeing a lot more service crashes as reported by others here.

services crashes but logs show no error.

If you don't support moving volumes to Metal, why is that the only option that I can choose when creating a new volume and service to use it?

Hi Railway team,

I've been doing more tests with a simple application I have in Railway. https://railway.com/project/7cefec87-18ae-4a4d-a93e-b0b2f8ff0be2

It's a Strapi CMS pointing to a PostgreSQL Database. I am using the Internal Database URL.

I measured the load times of the endpoints required to load a Content Collection in the Strapi Admin panel and those are the results for the same region (EU WEST):

NON METAL

[2025-04-11 20:15:58.350] http: GET /admin/project-type (2 ms) 200

[2025-04-11 20:15:58.470] http: POST /admin/renew-token (4 ms) 200

[2025-04-11 20:15:58.469] http: GET /admin/init (5 ms) 200

[2025-04-11 20:15:58.575] http: GET /admin/telemetry-properties (18 ms) 204

[2025-04-11 20:15:58.768] http: GET /admin/information (17 ms) 200

[2025-04-11 20:15:58.774] http: GET /admin/users/me/permissions (24 ms) 200

[2025-04-11 20:15:58.783] http: GET /admin/users/me (31 ms) 200

[2025-04-11 20:15:58.952] http: GET /i18n/locales (26 ms) 200

[2025-04-11 20:15:59.134] http: GET /content-manager/init (22 ms) 200

[2025-04-11 20:15:59.340] http: GET /content-manager/content-types-settings (56 ms) 200

[2025-04-11 20:15:59.460] http: GET /content-manager/content-types/api::article.article/configuration (26 ms) 200

[2025-04-11 20:15:59.638] http: GET /content-manager/collection-types/api::article.article?page=1&pageSize=10&sort=title:ASC (61 ms) 200

METAL

[2025-04-11 20:35:12.470] http: GET /admin/project-type (6 ms) 200

[2025-04-11 20:35:12.622] http: POST /admin/renew-token (7 ms) 200

[2025-04-11 20:35:12.631] http: GET /admin/init (27 ms) 200

[2025-04-11 20:35:12.796] http: GET /admin/telemetry-properties (67 ms) 204

[2025-04-11 20:35:13.104] http: GET /admin/information (83 ms) 200

[2025-04-11 20:35:13.636] http: GET /content-manager/init (65 ms) 200

[2025-04-11 20:35:14.456] http: GET /content-manager/collection-types/api::article.article?page=1&pageSize=10&sort=title:ASC (175 ms) 200

[2025-04-11 20:35:12.304] http: GET api:api/admin/content-manager/collectionType/api::article.article?page=1&pageSize=10&sort=title:ASC (7

[2025-04-11 20:35:13.177] http: GET /admin/users/me (152 ms) 200

[2025-04-11 20:35:13.897] http: GET /content-manager/content-types-settings (106 ms) 200

[2025-04-11 20:35:14.158] http: GET /content-manager/content-types/api::article.article/configuration (152 ms) 200

----

Same day, same setup, the only thing I changed was moving everything to METAL. As you can see, there is a major performance hit in all requests.

This is something I experienced in another app hosted in Railway too.

I hope that this could help you solve this issue. Please, let me know if you need further information.

me too bro, now I got better (ping ~50ms) when i turn off Metal Edge in Public Networking

I guess their metal edge is crashed then fallback to US region or something. Better turn it off

https://station.railway.com/questions/railway-metal-edge-network-problem-daef9ba1

I got same problem, it add 400ms response time

So railway automatically migrated my service to metal and used a week old commit for some reason for deployment instead of a latest deployed previously, leading to crashes and services being unreachable before we noticed. What the hell?

Even though I have moved all my deployments to metal, its still showing 22%usage on metal only - thus I am inellegible for metal discount.

Hey rahulgoyal203, the metal discount will be applied when >= 80% of your usage originates from metal. Keep in mind that it's not about the percentages of services on metal but rather the overall metal usage (resources used by your services). Moving all of your services to metal will gradually increase your metal usage over time.