Your trial has expired and the workspace currently has no active plan. Subscribing to Hobby ($5/month, which includes $5 of usage) from your billing page is how you get services running again. Per our docs, once the underlying billing issue is resolved, Railway automatically redeploys stopped services as long as it happens within 30 days of them being stopped; after that window, you redeploy manually from each deployment's menu. Volumes attached to services are not removed when deployments are stopped.

Thank you for the automated response.

The general guidance is helpful, but the activation scope of “Deploy with Hobby” for this existing expired-trial workspace is still unclear.

Could a Railway team member please clarify:

• whether activating Hobby can be separated from automatically deploying or restarting existing services;
• which existing services would be affected;
• whether normal pre-deploy commands or migrations would run; and
• whether the existing PostgreSQL service would reuse/remount its existing volume.

I am only requesting clarification.

Please do not make any plan, billing, deployment, restart, migration, restore, database, or volume changes on my behalf.

Thank you.

Thank you for the automated response.

The general guidance is helpful, but the activation scope of “Deploy with Hobby” for this existing expired-trial workspace is still unclear.

Could a Railway team member please clarify:

• whether activating Hobby can be separated from automatically deploying or restarting existing services;
• which existing services would be affected;
• whether normal pre-deploy commands or migrations would run; and
• whether the existing PostgreSQL service would reuse/remount its existing volume.

I am only requesting clarification.

Please do not make any plan, billing, deployment, restart, migration, restore, database, or volume changes on my behalf.

Thank you.

“Deploy with Hobby” on the Plans page opens the subscription form; that first click does not activate the plan or start services. Activation happens when you submit “Subscribe to Hobby Plan” and payment succeeds.

Once Hobby becomes active, Railway automatically attempts to redeploy the deployments it previously stopped for the workspace’s billing/trial issue. This can span projects and environments in that workspace, rather than just the service you have open. Deleted services are excluded. The automatic-recovery window is 30 days; after that, redeployment is manual.

There is no option in this subscription flow to activate Hobby while skipping that automatic recovery, and no separate per-service deployment confirmation after activation.

For PostgreSQL, recovery creates a new deployment of the existing service. If its existing volume is still attached and available, that volume is mounted again; this does not create a replacement database or restore a backup.

These are normal redeployments: configured pre-deploy commands run before the application starts, so migrations configured there can run. Migrations in your application’s startup command can also run when it starts.

The sequence is therefore: open the subscription form → confirm subscription/payment → Hobby becomes active → eligible stopped deployments are redeployed.

Thank you for the clarification.

I have one remaining question about Railway’s automatic recovery after a billing/trial issue is resolved.

When Railway automatically redeploys an affected service, which configuration source does that recovery use: the stopped deployment’s saved configuration, the current service/environment configuration at the time of activation, or another source?

If this differs by setting, could you clarify how it applies to pre-deploy commands, start commands, and cron configuration?

Also, if the current service configuration is changed before Hobby activation, would those changes be used by the automatic recovery, or would the recovery still use the previously stopped deployment’s configuration?

I am only requesting clarification. Please do not make any plan, billing, deployment, restart, migration, restore, database, volume, or configuration changes on my behalf.

Thank you.

As Brody noted, recovery creates a new deployment of the existing service. A new deployment reads the current service and environment configuration at the time it runs, not a frozen snapshot from the stopped deployment. This applies uniformly to pre-deploy commands, start commands, and cron schedules. If you edit any of those settings in the dashboard before activating Hobby, the recovery deployment will use the updated values.