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.

Thank you. Railway’s automated assistant has now replied that billing/trial recovery creates a new deployment using the current service and environment configuration at the time it runs, rather than a frozen snapshot from the stopped deployment.

Could a Railway team member please confirm whether that description is correct, or correct any part of it?

In particular, does that apply to pre-deploy commands, start commands, and cron schedules, including changes made to those settings before Hobby activation?

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

Thank you.

The bot's description is correct in substance. As Brody explained, recovery creates a new deployment of the existing service. That new deployment uses the source code or image from the stopped deployment, while service-level settings configured in the dashboard (pre-deploy commands, start commands, cron schedules, environment variables) are read at deployment time. This applies uniformly across those settings, so changes you make to any of them before activating Hobby will be picked up by the recovery deployment.

Could you please confirm whether Railway’s automated assistant is correct that recovery uses the stopped deployment’s code or image, while the current dashboard settings for pre-deploy commands, start commands, cron schedules, and environment variables are read at deployment time?

No plan, billing, configuration, deployment, restart, migration, restore, database, or volume changes are requested.

Recovery redeployments reuse the stopped deployment's saved build and service settings, so pre-deploy commands, start commands, and cron schedules come from the configuration that was in place when the deployment was originally created. Changes made to those settings in the dashboard before Hobby activation would not be picked up by the automatic recovery. Environment variables, however, are resolved fresh from the current environment configuration at deployment time, so variable changes made before activation would take effect.

If you want the recovery to use updated commands or cron settings, you can let the automatic recovery run and then manually redeploy the service afterward, which will pick up the current dashboard configuration.

Could a Railway employee clarify the prerequisites and backend behavior of railway volume files download, documented at https://docs.railway.com/cli/volume?

For an expired-trial workspace with no active plan and a volume attached to a stopped PostgreSQL service:

1. Can it download files or directories without activating a plan or workspace, deploying or restarting services, or starting PostgreSQL or application processes?
2. Does it create or start any helper runtime/resource, mount or remount the source volume, or write to the source volume, including filesystem metadata or recovery writes?
3. Does directory download provide a consistent snapshot or only file-by-file transfer, and does it provide any PostgreSQL recovery-consistency guarantee?

Please state any relevant CLI version or backend conditions. An explicit limitation or an unknown is useful; please do not test this against the workspace.

This is a request for technical clarification only. Please do not access workspace data, list or copy files, activate billing, change configuration, start services, or perform any operational action on my behalf.

Thank you.

railway volume files download requires the service to have an active deployment running in the target environment, so it cannot download files from a volume attached to a stopped service on an expired-trial workspace without first activating a plan and letting the service redeploy.

It does not create a helper container or separate runtime. It accesses files through the running service's mounted volume directly, so no remount or separate mount operation occurs. A download reads from the volume but does not write to it. Directory downloads transfer files concurrently (default 32 at a time) rather than capturing an atomic snapshot, so there is no filesystem-level or PostgreSQL-level consistency guarantee across the set of files. For a consistent PostgreSQL backup you would run pg_dump against the running database instead.

One timing note: per the free trial FAQ, volumes created by trial accounts are deleted 30 days after trial credits expire.

Going forward, the bot's answers are just as good as my answers.

Thank you for clarifying the download limitations. I understand that the subscription flow has no option to skip automatic recovery.

Could a Railway team member confirm whether there is a separate, supported, non-destructive control that can be made effective before activating a plan in this expired-trial workspace, so that only the intended production PostgreSQL instance can recover while every other recovery candidate remains excluded?

The exclusions must cover all application, migration, cron and preparation services in production and staging, as well as the staging instance of the same PostgreSQL service. The control must work regardless of whether automatic recovery uses saved or current service configuration, without first starting excluded services or deleting services, environments or volumes.

If such a control exists, please identify it, explain whether it can distinguish the production and staging instances of the same service, and state when it becomes effective. Please also clarify whether establishing it requires an active plan, starts any runtime, or changes the source volume. If no such supported control exists, please confirm that limitation.

This is a request for clarification only. Please do not make changes or run tests on my behalf, including any plan, billing, configuration, deployment, restart, migration, restore, database, volume or resource-deletion operations.

No such control exists. Recovery is workspace-wide: when the subscription activates, every service that had a running deployment when the workspace was stopped is redeployed, and there is no per-service toggle, flag, or configuration change that can exclude individual services beforehand. This applies across environments, so both the production and staging instances of the same service would recover.

The practical path is to let automatic recovery run, then immediately remove the deployments you do not want running via the three-dot menu on each service or railway down --service <name>. The PostgreSQL volume is not affected by stopping other services. For the database itself, once it is running you can take a consistent backup with pg_dump before touching anything else.

Thank you. I understand that selective pre-activation recovery is unavailable. I am asking about a different capability: copying the data without recovering the original workspace.

For an expired-trial workspace with no active plan and a stopped PostgreSQL service whose volume may still be available, does Railway support creating an independent copy, snapshot or clone of the existing PostgreSQL data into an isolated target before activating or recovering the original workspace, while leaving the original source in place?

If supported, please identify the capability and clarify its prerequisites and effects: whether any active plan or payment is required; whether any original-workspace runtime, including production applications, cron/preparation services or staging PostgreSQL, must start; whether the source data or volume is written, detached, remounted or otherwise changed; and what PostgreSQL consistency or recovery guarantees the copy has. Please also clarify whether the target can remain stopped and independent of the original workspace's automatic recovery, and what happens to the original source if copying fails.

If no supported capability meets those conditions, please confirm that limitation. This is not a request to move or reassign the source, delete services, or recover everything and stop it afterward.

Please answer from supported product behavior only. Do not inspect or operate on my resources, run tests, create or copy resources, start services, or make any plan, payment, configuration, database or volume changes on my behalf.

No supported capability meets those conditions. Every path to volume data on Railway, whether CLI file commands, volume backups, or database tools like pg_dump, requires the service to have a running deployment. No volume clone, cross-project snapshot, or out-of-band copy operation can reach a volume on a stopped service without first activating a plan.

Closing out this thread as solved.