The Backups tab creates and restores point-in-time snapshots of your service files. It takes one click, which makes it easy to set up and easy to assume is working.
What a backup contains
A backup captures the files in your container — your application code, configuration and uploaded assets. That is the scope, and the boundaries matter more than the feature.
Not included:
- Your databases. Managed databases are separate from your container's filesystem and are not part of a service backup. Export them yourself —
pg_dumpormysqldump— and store the dump somewhere else. - Environment variables. Set on the service, not stored in files.
- Anything installed outside your project directory. Global package installs live outside the tree that gets captured.
A service whose files are backed up but whose database is not has not been backed up. It has had its code preserved, which is the easier half to restore and not the half you lose.
How many slots you get
Backup slots scale with your plan — one on Starter, two on Basic, four on Pro, eight on Max. This is the reason to upgrade beyond memory limits: slots are a hard ceiling on how many restore points you can keep.
Each new backup consumes a slot. With one slot, a new backup replaces the previous one, which means you have exactly one restore point and no history.
Take one before every risky change
The highest-value backup is the one taken immediately before you do something you cannot undo: a manual file edit, a dependency upgrade, a migration.
Two minutes of backup turns an unrecoverable mistake into an inconvenience. Skipping it because “the change is small” is the reasoning that produces incidents.
Test a restore
An untested backup is a hypothesis. Restore into a separate service rather than over your working one — then you can check that it starts, that dependencies are present, and that the files are the version you expected.
Common failures at restore time:
node_modulesor a virtualenv was never in the backup, because it was installed globally or ignored.- Environment variables are missing, so the app cannot boot — a reminder that they are not in the snapshot.
- The code is right but the database schema moved on. Restore the dump too, or expect errors on every query.
Do this once, before you need it. Discovering that your backups do not contain dependencies during an outage is the worst possible time.
A backup routine that holds up
Take a backup before every deploy or manual change, and check the log occasionally to confirm backups are actually being created — a scheduled task that fails silently is worse than no schedule, because it looks like coverage.
Keep database dumps separately from service backups, with their own retention. They are small, they are the irreplaceable part, and they are the thing you will be glad you exported.