Hello Railway Support,
gunomion
FREEOP

2 hours ago

Our trial has expired and our PostgreSQL service is currently offline.

We still see the existing PostgreSQL volume attached to the service, but there are no active deployments and no backups listed.

Before upgrading or redeploying, we would like to confirm:

  1. Is the data on the existing volume still preserved?
  2. Can we safely recover or export the database after upgrading to the Hobby plan?
  3. Is there any risk of losing the existing volume data during redeployment?

We want to preserve our existing PostgreSQL data and avoid creating a new, empty database.

Thank you.

Awaiting User Response

3 Replies

Railway
BOT

2 hours ago

Yes, the data is still there. Both of your Postgres volumes are still attached to their Postgres services, in a ready state, and still hold data (roughly 109 MB and 120 MB used). The services are offline only because their deployments were stopped when the trial ended.

When you subscribe to Hobby, we automatically redeploy the deployments that were stopped. Those are new deployments of your existing Postgres services, and they mount the volumes that are already attached. Subscribing does not create a new, empty database or swap the volume. Once Postgres is running again you can connect to it and export the database as usual. Automatic recovery covers deployments stopped within the last 30 days. After that, you would redeploy the service yourself, and it would still use the attached volume.

Recovery is not limited to Postgres. It covers the stopped services across the workspace's projects, so your app services will start too. Any migrations in their pre-deploy or start commands will run as part of that.


Status changed to Awaiting User Response Railway • about 2 hours ago


Railway

Yes, the data is still there. Both of your Postgres volumes are still attached to their Postgres services, in a ready state, and still hold data (roughly 109 MB and 120 MB used). The services are offline only because their deployments were stopped when the trial ended. When you subscribe to Hobby, we automatically redeploy the deployments that were stopped. Those are new deployments of your existing Postgres services, and they mount the volumes that are already attached. Subscribing does not create a new, empty database or swap the volume. Once Postgres is running again you can connect to it and export the database as usual. Automatic recovery covers deployments stopped within the last 30 days. After that, you would redeploy the service yourself, and it would still use the attached volume. Recovery is not limited to Postgres. It covers the stopped services across the workspace's projects, so your app services will start too. Any migrations in their pre-deploy or start commands will run as part of that.

gunomion
FREEOP

2 hours ago

Thank you for the information.

Before subscribing to the Hobby plan, could a human support agent please confirm that our existing PostgreSQL volumes and data will be preserved when the services are redeployed?

We also want to confirm whether automatic redeployment could run any startup commands or migrations that might modify our existing database.

We have no backups listed, so preserving the existing data is very important to us.

Thank you.


Status changed to Awaiting Railway Response Railway • about 2 hours ago


2 hours ago

We checked both Postgres volumes again just now. Each one is still attached to its Postgres service, in a ready state, and holds data (about 109 MB and 120 MB). When you subscribe to Hobby, the stopped deployments are redeployed as new deployments of those same services, and each one mounts the volume that is already attached. Subscribing does not create a new, empty database, swap the volume, or restore a backup. After you click "Deploy with Hobby", nothing activates until you submit the subscription form. Once the subscription is active, recovery starts on its own, and you can't choose to skip it or pick only some services.

These are normal redeployments, so whatever your services are configured to run will run. We don't see a pre-deploy command on your three app services. Two of them do have start commands that run your own Python scripts, and those services connect to Postgres through DATABASE_URL. If those scripts, or your app's startup code, run migrations or write to the database, that will happen when the services start. We can't tell from here what your code does, so please check those scripts before you subscribe. The Postgres services themselves just start Postgres on the existing data.

To keep the app services from touching the database while you take an export, you can temporarily remove or change their DATABASE_URL variables before you subscribe. Bring Postgres up, export it, then put the variables back.


Status changed to Awaiting User Response brody • about 2 hours ago


Welcome!

Sign in to your Railway account to join the conversation.

Loading...