Your MySQL data does not appear to be lost. The MySQL service still exists in your production environment, and its persistent volume (mounted at /var/lib/mysql) is still attached to it, in a ready state, and holding data. Only the service's deployments were removed. The service and its volume were not deleted.

Your workspace currently has no active plan, so nothing is running right now. Leaving the MySQL service and its volume as they are keeps that original data where it is.

Thank you for confirming that the MySQL service and its persistent volume are still present and holding data.

I still need help recovering access to my original production database.

My workspace currently has no active plan, and I want to avoid any action that could erase or overwrite the existing data.

Could you please explain the safest way to restore or temporarily reactivate the existing MySQL service and its attached volume, so I can export my original database before making any changes?

Please confirm whether reactivating the service or upgrading my plan would preserve the existing volume and its data.

Thank you.

Your MySQL service is stopped right now because your workspace has no active plan. Choosing a plan does not change or remove the volume, and nothing on our side restarts the service by itself. To get it running again, pick a plan first: Hobby from your billing page, or Free from the Plans page under "Downgrade to Free". Hobby is the better fit for a MySQL database. On Free, services have to run with App Sleeping and get only 0.5 GB of RAM.

After that, redeploy the existing MySQL service. A redeploy mounts the same attached volume at /var/lib/mysql, so the data on it stays where it is. The docs describe volumes as storage that keeps a database's data across rebuilds of the container. Once MySQL is running, you can export the database using that service's connection variables.

To keep the data safe until you have the export, do not delete the MySQL service or its volume, do not detach the volume, and do not add a new volume to that service. Each service can have only one volume.

Before I confirm the downgrade to Free, could you please confirm that this plan change will preserve my existing MySQL service and its persistent volume, including all data stored in /var/lib/mysql?

I want to make sure the original database data will remain intact when I downgrade and redeploy the existing MySQL service.

Thank you.

Yes. Switching your workspace to Free changes the plan only. It does not delete, detach, resize, or modify volumes. Your MySQL service still exists in production with its volume attached at /var/lib/mysql, in a ready state and holding data.

When you redeploy the existing MySQL service after the plan change, it mounts that same volume. Before you have your export, avoid deleting the service or the volume, detaching it, or attaching a different volume to that service.

Hello Railway Support,

My MySQL service is on the Free plan. Serverless (App Sleeping) is enabled in Settings, and the setting saves automatically, but every deployment still fails with this error:

Free plan deployments must be serverless. Please go to your service settings and turn on the serverless flag.

The service uses the Docker image mysql:9. The original persistent volume is still attached to the service and contains important production data that I need to recover.

I have checked the Serverless setting and tried to investigate the deployment options, but I cannot find “Deploy latest commit” in the command palette.

Could you please check the service configuration and help me deploy the existing MySQL service or provide a safe way to export the attached volume data without deleting or recreating the service or volume?

Thank you.

We checked the MySQL service: Serverless is saved as enabled. Serverless only takes effect when a new deployment creates a new container, so the Redeploy button on an older deployment can keep hitting this error.

Your MySQL service runs from the mysql:9 image, not a repository, so the command palette won't show "Deploy latest commit". Open the MySQL service, press Ctrl+K (Cmd+K on Mac), and choose Redeploy source image. This starts a fresh deployment that mounts the same attached volume. Redeploying does not delete, reset, or roll back the data on that volume.

One more thing to know before it starts: the service's start command sets --innodb-buffer-pool-size=1G, but on the Free plan each replica gets about 0.5 GB of memory. If MySQL fails to start after the redeploy, that setting is the first thing to check.

Hello Railway Support,

I need help recovering access to my original MySQL production database in project poetic-friendship, environment production, service MySQL DB.

The MySQL service has an attached persistent volume mounted at /var/lib/mysql. The deployment starts successfully and logs show ready for connections on port 3306, but the service later enters Sleeping.

MySQL Workbench fails with:

Lost connection to MySQL server at 'reading initial communication packet', system error: 0

The public TCP port accepts connections, but I cannot establish a MySQL session or export the database.

This database contains original data that I need to recover. Please do not delete, recreate, detach, or reset the service or its volume.

Could you investigate the MySQL runtime and TCP proxy, and help me safely regain access so I can export the data?

Thank you.

We haven't established what's causing this yet. The community can help investigate your setup.

That's exactly what the Railway community is good at, so we'd like to open your thread as a community bounty. Railway pays a bounty to the community member who solves it, and threads like this usually get picked up quickly.

Opening it makes this entire thread public, including everything already posted. Nothing becomes public until you decide. Use the buttons below.

• Open to the community - Before you click, take a moment to edit or remove anything you'd rather not share. The thread becomes publicly visible right away.
• Keep it private and close the thread - Nothing becomes public and the thread closes.

Try restarting the container by clicking on the 3 dots next to the active deployment and select restart.

Thanks for your suggestion. I checked the three-dot menu next to the deployment, but I only see “Redeploy” and “Remove”. There is no “Restart” option in my Railway interface.

Is there another safe way to restart the MySQL container without deleting or detaching the persistent volume containing my original database data?

Try redeploying it then.