Publishing & safety

Publishing takes a site live. Whether you publish from the AI agent or the CLI, the platform runs a set of checks and then makes the new version the live one. This page explains what happens and how to work with it.

What publishing does

When you publish, the platform validates the site, applies the change, and updates the live version. There's no separate build or deploy step to run yourself. Each publish becomes a deployment you can review or roll back to later (see Deployments & backups).

The checks that run

A publish has to pass a few gates. Most are about protecting a live site from a broken or unsafe change:

• Validation (lint). Templates, schemas, and logic are checked for errors. The CLI can also run this locally with acira lint as a fast pre-flight before you publish.
• Unresolved conflict markers. If a file still contains merge conflict markers, the publish is rejected — this one can't be overridden.
• Data-loss protection. A schema change that would discard live data is blocked and shows you exactly what would be lost, unless you explicitly accept it. A restore point is captured automatically when you do.
• Staleness. If the live site has moved on since you pulled (someone else published in between), the publish is rejected so you don't clobber their change. Pull again to merge, then publish.
• Content safety review. Published content is reviewed for policy violations after go-live.

Publishing from the CLI

acira publish -m "Describe the change"

Useful flags:

• --override-lint — publish despite lint warnings (the conflict-marker and data-loss gates still apply).
• --accept-data-loss — proceed with a destructive schema change (a restore point is captured first).
• --force — publish over a newer live version (use deliberately).

Rolling back

Every deployment is retained, so you can roll back to a previous version at any time from the app or with acira rollback <id>. For data specifically, point-in-time backups let you recover recent state independently of code deployments.