10 months ago
Hello,
All of my services on Railway are currently hosted in the US West (California, USA) region.
After doing some research with ChatGPT, I found out that — since the majority of my traffic comes from Brazil — the US East (Virginia, USA) region would offer lower latency and better performance for my users.
So I’d like to ask:
👉 If I migrate my Railway services from California to Virginia,
will my website actually load faster for users in Brazil?
And also:
What would be the impact of changing the region?
Would I lose anything in the process (data, uptime, configuration, etc.)?
Thanks in advance!
Pinned Solution
10 months ago
Hi ellcleberccj, the migration process for changing your servers' location is very straightforward and a breeze.
- As you have already figured out that most of the traffic comes from Brazil, then out of the available options that Railway provides: EU West (Amsterdam), US East (Virginia), US West (California), and SE Asia (Singapore), Virginia is the closest that you can opt for. And indeed, the closer the actual servers are to the majority of your target audience, the faster they will be able to access the site. It offers low latency or faster response times.
- Changing the region is very easy, as it just re-deploys the instance of the service in the new region (taking care of the other things). You can go to the settings tab of that service to change the DEPLOY REGION, or else you can go to your account settings and choose the default region for all of your future deployments. Just the re-deployment time is the main thing (which frabnjly depends on your project, and may be done in a few seconds).
To counter that small downtime while re-deployment, you can use the TEARDOWN property for the service: https://docs.railway.com/guides/deployment-teardown
If you face any challenge in changing anything, do let me know in this thread. I hope that clears your doubts! If so, then mark it as the solution.
Attachments
8 Replies
10 months ago
Hey there! We've found the following might help you get unblocked faster:
If you find the answer from one of these, please let us know by solving the thread!
10 months ago
Hi ellcleberccj, the migration process for changing your servers' location is very straightforward and a breeze.
- As you have already figured out that most of the traffic comes from Brazil, then out of the available options that Railway provides: EU West (Amsterdam), US East (Virginia), US West (California), and SE Asia (Singapore), Virginia is the closest that you can opt for. And indeed, the closer the actual servers are to the majority of your target audience, the faster they will be able to access the site. It offers low latency or faster response times.
- Changing the region is very easy, as it just re-deploys the instance of the service in the new region (taking care of the other things). You can go to the settings tab of that service to change the DEPLOY REGION, or else you can go to your account settings and choose the default region for all of your future deployments. Just the re-deployment time is the main thing (which frabnjly depends on your project, and may be done in a few seconds).
To counter that small downtime while re-deployment, you can use the TEARDOWN property for the service: https://docs.railway.com/guides/deployment-teardown
If you face any challenge in changing anything, do let me know in this thread. I hope that clears your doubts! If so, then mark it as the solution.
Attachments
clashing
Hi **ellcleberccj,** the migration process for changing your servers' location is very straightforward and a breeze. 1. As you have already figured out that most of the traffic comes from **Brazil,** then out of the available options that Railway provides: EU West (Amsterdam), US East (Virginia), US West (California), and SE Asia (Singapore), **Virginia** is the closest that you can opt for. And **indeed,** the closer the actual servers are to the majority of your target audience, the faster they will be able to access the site. It offers low latency or faster response times. 2. Changing the region is very easy, as it just re-deploys the instance of the service in the new region (taking care of the other things). You can go to the **settings** tab of that service to change the **DEPLOY REGION**, or else you can go to your account settings and choose the **default region** for all of your future deployments. Just the re-deployment time is the main thing (which frabnjly depends on your project, and may be done in a few seconds). To counter that small downtime while re-deployment, you can use the **TEARDOWN** property for the service: <https://docs.railway.com/guides/deployment-teardown>  If you face any challenge in changing anything, do let me know in this thread. I hope that clears your doubts! If so, then mark it as the solution.
10 months ago
ellcleberccj, if this helped you, do mark it as the solution
Any further help is highly appretiated
clashing
**ellcleberccj**, if this helped you, do mark it as the solution Any further help is highly appretiated
10 months ago
Thank you for your response!
Could you please let me know how long the estimated downtime would be when migrating the volume to another server? The volume is around 50GB — would it take a few hours, or less?
ellcleberccj
Thank you for your response! Could you please let me know how long the estimated downtime would be when migrating the volume to another server? The volume is around 50GB — would it take a few hours, or less?
10 months ago
Hey, at least your clients are able to reach your Railway server! Mine are getting a ‘Failed host lookup’ error, and it’s only happening in Brazil. In Canada, it works fine.
ellcleberccj
Thank you for your response! Could you please let me know how long the estimated downtime would be when migrating the volume to another server? The volume is around 50GB — would it take a few hours, or less?
10 months ago
It won't take a huge amount of time! Furthermore, if you would see any issues with that, you can raise a new issue, and the team would connect with you, rather than creating a bounty for that thing.
I hope this clears all your doubts (. ❛ ᴗ ❛.)
clashing
It won't take a huge amount of time! Furthermore, if you would see any issues with that, you can raise a new issue, and the team would connect with you, rather than creating a bounty for that thing. I hope this clears all your doubts (. ❛ ᴗ ❛.)
10 months ago
It should be noted that 50 GB will not take a couple of hours to migrate, and even so, the downtime would not last for the duration of the migration; downtime would be minimal, even for terabytes of data.
Status changed to Awaiting User Response Railway • 10 months ago
brody
It should be noted that 50 GB will not take a couple of hours to migrate, and even so, the downtime would not last for the duration of the migration; downtime would be minimal, even for terabytes of data.
10 months ago
Okay, thanks for rectifying that. And with the downtime being minimal, it's great
Status changed to Awaiting Railway Response Railway • 10 months ago
Status changed to Solved brody • 10 months ago