Skip to main content
Every pod is backed up automatically. When a pod is created, InstaPods turns on a daily backup schedule for it - you don’t have to enable anything. Backups capture your application files and dump any database the pod is running, so a restore brings back your data, not just your code. Open the Backups tab on any pod to see its backups, take one by hand, or restore.

What gets backed up

InstaPods backs up your data, not the whole container. The base operating system and installed packages are rebuilt from the preset image, so backups stay small and restores stay fast. On top of that, any database found in the pod is dumped into the archive first - a managed MySQL, PostgreSQL or Redis service, a database bundled with a 1-Click App, or one you installed yourself. The dump is restored back into the running database when you restore the backup.
Dependency directories are excluded on purpose - they are reinstalled from your lockfile and would otherwise dominate the size of every backup. After restoring a Node.js or Python pod, run instapods pods reload my-app to reinstall dependencies.

How many backups you keep

Retention is per plan, and it’s a count of stored backups per pod. When a new backup pushes a pod over its limit, the oldest one is deleted. Once you’re at the limit, a manual backup is rejected with a 403 until you delete an old one or move up a plan. Scheduled backups aren’t rejected - they roll the oldest one off automatically.

The automatic schedule

The default schedule runs every 24 hours and keeps as many backups as your plan allows. Open Automatic Backups on the Backups tab to change it: Enable auto-backups turns the schedule on or off, Frequency switches between daily and weekly, and Keep last sets how many to retain. Two behaviours worth knowing:
  • Stopped pods are skipped. A backup has to run commands inside a live container, so a stopped pod is passed over rather than failing every night. Its existing backups are frozen - nothing is added, and nothing is deleted to make room - so your recovery points survive for as long as the pod is off.
  • A backup that captures nothing fails loudly. If a database dump comes back empty or a directory the app was supposed to write to doesn’t exist, the backup is marked failed instead of being recorded as a successful, empty archive.

Taking a backup by hand

Open the pod, go to the Backups tab and click Create Backup. Type a short note in the Note (optional) field first (“before the v2 upgrade”) to find it again later.The backup runs in the background; the row shows its status and final size when it finishes.

Restoring

Restoring rewinds the pod’s data to the moment the backup was taken.
A restore is destructive and cannot be undone. Every directory covered by the backup is emptied before the archive is extracted, so anything created since the backup is lost. Take a fresh backup first if the current state is worth keeping.
On the Backups tab, find the backup and click Restore. Confirm the warning. The pod’s services are stopped, the data is replaced, databases are re-imported, and the services are restarted.
A restore only reports success when the databases came back too. If the files were restored but a database dump could not be re-imported, the restore is marked failed and the dump file is deliberately left inside the pod (under /tmp) so you can import it by hand rather than losing it. The pod’s Events tab names the file.

Downloading a backup

You can pull any completed backup out of InstaPods as a .tar.gz, for off-site storage or to inspect it locally.
On the Backups tab, use the Download action on any completed backup.

Importing a backup

You can upload a backup archive you downloaded earlier and register it against a pod, then restore from it like any other backup. This is how you move data between two pods, or bring back a pod you rebuilt. On the Backups tab, click Import and pick the .tar.gz. Or over the API:
Uploads are capped at 2 GB and count against your plan’s retention limit.
Import the archive into a pod of the same shape as the one it came from. A backup only carries the paths its source pod used, so restoring a Node.js backup into a 1-Click App pod puts files where nothing will read them.

API reference