ed9d81eb-a192-462c-8cf6-bf7778244e57

Railway is absolutely fitted for production, so no need to worry <:SmileFluent:865334941150871592>
At first glance it looks correctly set up, but here's a few things to account for:

Database
I notice you have a database with a volume attached, it looks like you deployed the pre-set MySQL database Railway provides
It's already set up to store data persistently and should be ready for production use unless you changed any configurations you shouldn't have (like volume mount location)

Best Practices
best practice in this case would be to ensure you're connecting to your database over the private network
(referenced in the MYSQL_PRIVATE_URL variable in your MySQL service)

connecting to your database through that ensures you're using the private network which is faster and doesn't subject your services to egress fees

Services
Your services don't have volumes attached, volumes are what's used to store data persistently, if all your services only use your database to store persistent data then you should be good. Although if your services are supposed to store data or files persistently in their file directory then you may need a volume there as well

For example if one of your services allow for image uploads and store them in /images then you may need a volume mounted to /app/images, doing this will ensure any files in the /images directory are stored persistently and will exist across all deployments

Railway is absolutely fitted for production, so no need to worry <:SmileFluent:865334941150871592>

I'm amazed you can tell that they are following all the best practices[1] from just a screenshot of their project canvas

1 - reference variables, using private networking, production web servers, etc etc

My answer was specific to the question of persistent data storage, I didn't consider cost-optimization; I'll append best practices to such answers in the future though

but do we really know they have their volume mounted to the correct location?

Piyush, best practice in this case would be to ensure you're connecting to your database over the private network (referenced in the MYSQL_PRIVATE_URL variable in your MySQL service, connecting to your database through that ensures you're using the private network which is faster and doesn't subject your services to egress fees

Your database will store data persistently regardless but it's very recommended to use the private network

Looks like they deployed MySQL via the Databases tab so it should automatically be on the right location unless they changed the volume mount location themselves but accounting for all edge case scenarios is unrealistic <:whyy2:820544722572673045>

but okay fine i see your point, I'll update my answer to be more specific <:sheriousbro:1232625099237228554>

it is unrealistic yes, but you can't make promises saying a users data will always be safe, because a users data is at the whims of the user

yea fair enough

Yeah I used the railway template for Mysql and concluding from your answer I guess I am good to go right?

I will try the private network thing

as long as you're following all the best practices, you are good to go

To use private url should I create a new variable named MYSQL_PRIVATE_HOST and assign host value to it form MYSQL_PRIVATE_URL because I require host seperately

always use reference variables -

MYSQL_PRIVATE_HOST=${{MySQL.RAILWAY_PRIVATE_DOMAIN}}