Self hosting production compose changes and backup

  1. Recently the self hosting area changed: reflex/docker-example at main · reflex-dev/reflex · GitHub

Is the production-compose still the same as the production setup before or should I change my deployment (using the old one) to the new way to deploy?

  1. When storing data in the inbuilt database using the compose setup, all the database data is stored in the postgres db right?

What would be an easy way to backup this database (without using simply supabase) in case I delete everything by accident or the server fails?

You can create a server snapshot to rollback if the update to the new self hosting plan fails.

I will try it out later today tho since i have the same question.

1 Like

Hey did you try out the server snapshot?
In that case, is it actually better to do a server backup or a server snapshot?

Hi, sorry for the extremly late reply, u fully forgot about that.

Yes i have tried out using snapshots and it worked perfectly fine. Of course when making a snapshot you should ensure your reflex app has stopped so you wont get any problems with caching. If you dont want to stop your reflex app you could snapshot memory too but what i have learnt is not to do that.

Backup is still needed 100% if you are using databases, in that case i would ONLY backup the databse and make a snapshot of the server where the app is running on. Backups could make your storage pretty full after some time, wont happen that fast with snapshots.

I recommend you using Hetzner for testing purposes, they are extremly cheap. (5$/ month)

There you can test if snapshots will work for you reflex application but there is no reason which comes into my mind why it wouldn’t.

thanks a lot for your thoughts!

Right now I run our reflex apps on hetzner servers, and I do daily backups of Hetzner.

However, if e.g. the backup is done at midnight, a user pays at 10am and I save it in the database, and I mess up the database at 11am, the entries for this user are lost because the last backup didn’t account for the most recent changes.

I’m thinking about something like a managed postgres database on AWS and just connecting my reflex app with it.

Basically just having a single AWS RDS postgres database, and creating a different schema for each of my reflex apps.

Using the cheapest AWS configuration that would cost 17$/mo for single availability zone, 20GB storage included.
But with Single-AZ the backups they do are still not real time, so the same scenario as with the hetzner backups could happen.
Multi-availability zone only costs double, and then there’s very low chance of any data loss.
Also encryption at rest is handled by AWS automatically.

I think I’ll try out this route, cause hosted supabase is too expensive, self hosted supabase really complicated to set up, and just using AWS RDS seems quite simple i.e. low maintenance cost.

Switching to AWS RDS for PostgreSQL with Multi-AZ sounds like a solid plan to ensure higher availability and reduce the risk of data loss. AWS’s managed backups and encryption features provide strong safety, and the Multi-AZ setup adds resilience against server or zone failures.

You could also consider enabling Point-in-Time Recovery (PITR) on AWS RDS. This allows you to restore your database to any point within a specified retention period (up to 35 days), which can be helpful in scenarios where recent changes need recovery. It might slightly increase costs due to storage requirements for transaction logs, but it adds an extra layer of data security.

In addition, using incremental backups can be an effective way to ensure data integrity with minimal storage overhead. Incremental backups only capture the changes since the last backup, which makes them more storage-efficient compared to differential backups, which capture all changes since the last full backup. Since AWS RDS already manages automated backups, this could complement that system by giving you more control over your backup strategy.