Skip to main content

​
Upgrade

Re-run the one-liner. The script sees the existing /etc/instacloud/instad.env, keeps every setting in it, and recreates only what changed:
Pin a version, or go back to one:
Branch containers are not part of the compose stack, so they are not recreated and keep running through the upgrade. The port check is skipped while the stack is up.

​
What a restart does to sleeping services

Nothing. A sleeping service is a stopped container with its files on disk, and it stays that way until something asks for it. Two details:
  • the idle clock starts fresh, so nothing is swept for one full window after the restart
  • the create grace does not restart, because it counts from when the service row was created

​
Backups

The backups API routes answer 501 today, with a hint that names this page, and there is no insta backup command, so this procedure is the only one there is. Follow it exactly: the parts that look optional are the parts that decide whether the archive is worth anything. What holds state. Everything is under the data directory (/var/lib/instacloud by default): md/ is the one an earlier version of this page left out, and a backup that omits it loses every managed database while appearing to succeed. The databases, one dump per branch, which is the copy you should trust:
Everything else. Stop EVERY writer first, not just the daemon: the branch containers and the object store keep writing to md/, vol/ and garage/ while tar reads them, and an archive taken over a running container is torn for that service even when the file list is right.
The middle line is the one people skip. Branch containers are not part of the compose stack, so docker compose stop does not touch them; the filter matches every container this daemon owns, because they are all named io-<ref>-…. Services that were asleep stay asleep and cost nothing. What the archive is and is not. With every writer stopped it is a consistent point-in-time copy of the whole box. If you cannot stop the branch containers (you have traffic to serve), the archive is still consistent for state.json and for any service that was ASLEEP at the time, and NOT for a service that was running: for those, use the pg_dump above for Postgres, and accept that a running Redis, MySQL or MongoDB is captured mid-write. There is no third option today. Restore, on a clean machine:
Restore the archive BEFORE the first insta command: the daemon reads state.json at boot, and a daemon that has already written its own empty one will overwrite what you untar. Keep the domain the same, or every minted hostname in state.json points at a name that no longer resolves to this box.

​
Growing the data disk

When the installer created a loop image and it is filling up:
No downtime, and nothing to restart.

​
Local mode

State stays in ~/.insta-oss.

​
Events

The daemon keeps the newest 5000 events and drops older ones, so treat insta agent events as a recent timeline rather than an archive. Anything you want to keep, export.