Do you have more details about how they are being improved?

We'd love the ability to natively backup common databases (e.g. MongoDB which we're using) and export them offsite.

There should be a backup download option.

There should be a possibility to schedule the backup for the whole environment or at least the option to have the same backup cycle for different services in the same Environment.

Would love scheduled backups from my PG and PGVector instances to GCS .

I would appreciate clarity on the availability of the backup feature. There is no documentation indicating that Backups are restricted to the Pro tier outside the user interface itself.

I did some research before setting up my Railway account, and the only information I found about backup pricing was on the backup docs page, which says "You are only billed for the incremental size of the backup at a rate per GB / minutely, and invoiced monthly" with no mention of a plan-level restriction. The Pricing Reference Page doesn't mention backups at all. There's a Volume Storage price that does not differentiate by Subscription type.

I expected backups to be available on the hobby tier. But then when I hit the backup tab for one of my serivices, it said "Backups are only available for customers on the Pro plan" and links to the plans page. But neither the Plans Page nor the pricing page list Backups as a feature with availability that differs across plans.

It would be really great to be able to take the backups offsite as storing the backups on the same infra is usually a bad decision. It seems right now there is no convenient way of doing this (guessing on the comments above, as I am on Hobby so the feature is not available to me)

Poor man's option/Hobbys't option is to expose your database over the public network and then use tool of your choice to make a backup, ie pg_dump or use a custom cron-service that takes care of making a backup and send it to remote storage like this one https://railway.com/deploy/I4zGrH . This works but far from being convenient ( https://station.railway.com/questions/pg-dump-and-pg-migrate-to-a-new-deployme-62d7d60e )

It would be also great to have some minimal backup option available for the Hobby plan

Exporting / download a backup or storing a backup on s3-like should be a no brainer

In the moment it is impossible to create manual backups if the automatic backups are selected (scheduled). This already exceeds the Limit of 10 Backups. Please fix that as soon as possible!

Would really appreciate the ability to configure scheduled backups from the CLI and API

Can the automated backups be downloaded and restored in a diff project. This would help with real DR scenarios

Would be great if you guys added backup encryption. I need it for for compliance purposes.

I'd like to voice a little bit of frustration I have with backups as they stand. There's a limit of 10 backups per service (at least on the Pro plan), and every single one of these "slots" is taken up by automated backups (we have Daily and Weekly snapshots enabled).

This means that if we ever want to take a manual backup of our database (i.e. before a large update), we have to spend a bit of time deleting the oldest automated backups in order to make room for any new manual ones.

I try to time to time manual backups like these as close as possible to the actual redeployment of a service (I'll watch it transition from "Building" to "Deploying") so that the backup aligns as closely with the previous application state as possible. I have on several occasions forgotten to delete older backups to make room and been caught in a bit of a panic trying to get that backup in before the health check completes and traffic cuts over.

Could we either raise the limit of 10 such that combined Daily, Weekly, and Monthly backups will never consume all slots (even 1 free slot would be great), or have it so that automated backups don't use these up and have like 3 manual backup slots counted separately?

I know this probably seems like a nit-pick (sorry) but it would be such a QoL improvement for cases like ours where sometimes our deployments carry data integrity risk requiring as little rollback as possible.

Thanks!