Deployments & backups

Every publish creates a deployment, and every deployment is retained. That gives you a full history you can review and roll back to, plus separate point-in-time recovery for a site's data.

Deployment history

The app lists a site's deployments with what changed and when. From there you can roll back to any previous deployment, which re-publishes that version and takes it live. The same is available from the CLI:

acira deployments        # list history
acira rollback <id>      # re-publish a previous version

Rolling back is a normal publish of an older version, so it's safe and reversible — you can roll forward again. If the version you're returning to predates a change to the live data structure, the rollback is refused until you say what should happen to the data collected since: restore the site alone, or rewind the data to match it too.

Backups and point-in-time recovery

Code rollback restores the site; backups restore the data. A site's recent data can be recovered to an earlier point in time, independently of deployments — useful if a bad import or a mistaken bulk change corrupted records. From the CLI:

acira backup bookmark     # mark a known-good point
acira backup restore      # restore data to a bookmark, or to a point in time
acira backup undo         # reverse a restore
acira backup list

Logs

Alongside history, the app surfaces a site's errors and recent console output, and acira logs shows the same from the terminal — so when something misbehaves after a publish, you can see what happened and roll back if needed.

Entries are separated by where the fault came from: the site's own code, output you logged yourself with console, and problems on our side. An error in the site's own code is recorded whether or not the code caught it — wrapping a mistake in try/catch keeps the visitor's page working, which is worth doing, but it doesn't take the mistake off the log. What stays off it is the ordinary business of a working program: a duplicate email address on signup, an expired reset link, an upload rejected for its size. Your code is expected to handle those, and handling one is not a fault.

Automatic error repair

When an error is traced to a site's own code, the AI coding agent can be dispatched to diagnose it, repair the site, and publish the fix, recording what it changed on the log entry. It acts only on faults in the site's own code: output you logged yourself with console.error is shown but never repaired, and neither is anything that failed on our side — that one is ours to fix. A fault that recurs is repaired once rather than on every sighting.

Agency-owned sites have it off by default. You manage the code, and an autonomous republish can collide with local edits you haven't published yet. It's a per-site setting either way: turn it on or off in the app, or from the terminal with acira settings set autofix on.