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. Three 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 failed scheduled backup is retried. It runs again an hour later, up to three times, instead of waiting for the next daily or weekly slot. If those fail too, the pod waits for its next scheduled run, one full interval later.
  • 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.

Backups after a pod is deleted

Deleting a pod takes its backups out of view straight away: they no longer appear on any Backups tab and can’t be downloaded or restored. They are kept for 14 days and then erased from storage for good. Deleting your account does the same to every pod’s backups. If you deleted a pod by mistake, there is one way back inside that window. Create a new pod with the same name on the same team within 13 days of the delete, and the old pod’s backups reappear on the new pod’s Backups tab, ready to restore (this does not apply to free trial pods). This only works while the name is still free - pod names are released the moment a delete finishes, so anyone can take it - and the new pod should be the same kind as the old one (see the note under Importing a backup). For the new pod’s first 14 days, the recovered backups don’t count toward its plan’s backup limit: its automatic schedule won’t delete them to make room, they don’t stop you taking a manual backup, and the used/max count on the Backups tab leaves them out. The new pod’s own schedule starts fresh, so its first backup isn’t held back by a recent recovered one.
Restore within those 14 days. After that the recovered backups count toward the limit again, and because they are the oldest, they are the first to go: within about 15 minutes the automatic schedule trims the pod back to its Keep last setting (your plan’s limit unless you changed it). On Launch, which keeps one backup, only the newest backup survives. A stopped pod, or one with auto-backups turned off, isn’t trimmed.
To keep a pod’s data longer than 14 days after deleting it, download a backup before you delete.

API reference

Every backup endpoint requires access to the pod: a pod that belongs to another team returns 403. A backupId that belongs to a different pod than the one in the path is refused even if you own both: 404 on get, delete and download, 400 on restore.