b082e796-c15c-43c8-b3d6-81fc47342308

Hi there rn having the same problem when I change it here tu us-west1 it allways defaults back to metal Beta thing when deploying and giving the same error

Is my error too

my deployment allways worked fine and also after reverting the changes I got the same error so I guess there where some changes on railway side

Exactly

@Brody any idea? I have to make sure any change doesn't break the fact that my app must be using 3.10.11
I saw someone complaining that their django app (mine if Flask) slowed down after switching to V2,
so I want to be sure there will be no impact if that's the thing to do in Settings.

switch the runtime to v2 in the service settings

It won't slow down the app or break it if runtime.txt is set to 3.10.11 ?

apparently the problem is in the meta beta regions

worked for me ty

@Brody additional question: my database service is not in the same PROJECT as the web app service. Are there risks it all breaks when I switch to V2?
Also, please confirm it won't slow down the app or break the 3.10.11 Python configuration.

My app contain PostgreSQL in other chanel, us oregon

runtime has nothing to do with python, and no slow down as long as you are using the private network

OK, so I can safely enable V2 then? No risk?

you would want the database in the same project so you can use the private network, otherwise there could be slowdowns

originally I hadn't "understood" the concept of projects, so that's why the DB was created elsewhere.
Is there a way to attach it to the web app project without breaking the whole thing?

I mean, it's been working fine for more than a year now,
but from I understand if I switch to V2, then it would slow down the whole thing.

you'd want to have the database in the same project, go ahead and do that now

1° how do you "move" the live database to another project?
2° how not to break all the credentials used in the code? (mysql password, etc.)

I've just read you can't move a SERVICE across PROJECTS. I have tons of data in the DB, as I said the app has been live for more than a year,
so I can't juste "move" it like that from one project to another.
What should I do then? @Brody

I see a Backup tab in the MYSQL DB service but apparently you need a PRO plan to get this feature.
Also, I read this "Backups can only be restored into the same project + environment."
So basically I can't use the native Backup feature if I switch to Pro, download the Backup and restore it in an empty MYSQL deployment in the web app's project…

@Brody Could you read the 2 messages above and give me the detailed instructions to:
1° move the DB from project A to B (where the web app is deployed) + instructions on how to update the credentials in the app after all the data tables are live in the new instance of the DB
2° make sure everything goes smoothly when I switch the Web App to V2 to fix the deployment bug
I appreciate your support.

you would need to deploy a database into the correct project and backup and restore it manually.

for credentials you should be using reference variables.

Do you have the code I can use in my terminal to create a backup at one end and restore it at the other end (zipping / unzipping if the data is too large)

you would want to reference mysql's docs -

Ok, I'll study this and also ask GPT4.
Can you confirm nothing will break when switching the web app's runtime to V2? No risk?

i can't promise that, but I can promise if something breaks it would be due to an issue with your application and nothing to do with the runtime

hen, please open your own help thread. Brody is busy helping Fred

Well, it doesn't really answer the question 🙂
The app is running perfectly fine now, the only reason why I need to switch to V2
is that, apparently, I can't push any new update since all new deployments fail due to the recent changes on Railway.

I would rather stick to the current setup, which has been running perfectly for 15 months

the v2 runtime needs to be used going forward, the legacy runtime is legacy for a reason, please work on putting your database in the correct project and connecting to it via the private network

I understand but to be fair, it's kind of unfair that clients has to invest time in their updates with no guarantee that their app won't break because the platform decides to modify their infrastructure. Not the first time I encounter this kind of issue in the IT world but that's unpleasant, to say the least, especially when it happens during the holiday season.

the v2 runtime has been out for a very long time, I'm sorry that you are just switching to it now

I'm forced to because I got a failed deployment out of the blue

and again, I don't see why you would not grandfather existing implementations.

the answer probably being "it's not our policy, sorry"

But now I've got to spend time learning how to migrate a DB and cross fingers this doesn't break my live project that's been up & running for 15 months without a glitch

this will also save you on egress fees from not having to connect to the database publicly!

Well, my expenses are pretty low on that front

I value my Sunday night more than a few dollars 🙂

going to mark this as solved now since you have a clear path forward for a resolution, in the future, please keep an eye on our changelogs so that you know to migrate to new features on weekdays

!s