CLI workflow

Agencies work at scale, so the acira CLI is the natural tool: pull a client site, edit it in your own editor with your own version control, and publish it back. This page covers how the CLI fits an agency workflow.

Connecting your team

Each developer signs in on their own machine with acira login — email, then a 6-digit code. There's nothing to mint or share, and the sign-in reaches exactly the sites that person's account reaches: for agency staff, the client sites in your portfolio. acira init does the sign-in as part of setting up a workspace, so a new developer usually starts there and never runs login directly.

Removing someone from the agency removes their access to the portfolio immediately, with nothing to revoke by hand. See Connected devices for the full picture, including how to review devices and revoke them individually.

Credentials for CI

A pipeline can't answer an emailed code, so mint an automation credential from a machine that's already connected and store it in your CI secret store as ACIRA_TOKEN:

acira token create "deploy-pipeline" --expires 365d

It's printed once, an expiry is required (at most a year), and we email the account 14 days before it lapses.

Mint CI credentials from an admin account, not a personal one. An automation credential belongs to the account that created it, and removing that person from the agency revokes it along with the rest of their CLI access — so a pipeline set up by a developer who later leaves stops working the day they're removed. It's the same trap as a personal access token on a shared repository, and the same fix: create it from an account that outlives any one individual.

A portfolio workflow

acira list                       # see the client sites you can access
acira pull acme-dental           # pull one to your machine
cd acme-dental
acira init                        # add AGENTS.md for AI editors
acira preview                     # local preview with the real runtime
# ...edit, commit to your own repo...
acira lint
acira publish -m "Launch the new services page"

Because the CLI and the AI agent edit the same project, a client can keep making small content changes in the app while your team does deeper work locally — the publish gates keep the two from clobbering each other.

Where a new client's data lives

acira create takes the country the site is operated from, and that decides where its data is stored:

acira create "Nordwind Zahnarzt" --country de

An EU country keeps that site's database, sessions, form submissions and email processing in the EU. Leave --country off and the site inherits your agency's own country, which is the right default when your client is in the same place you are — pass it when they aren't.

It is fixed when the site is created. There's no way to move a live site to another jurisdiction afterwards, so a client who needs EU residency has to be created that way from the start. If you're unsure, --country costs nothing to set correctly now and cannot be corrected later.

Single-page apps for client portals

For app-like surfaces on a client site — a customer portal, a booking dashboard — build a single-page app with your own toolchain and publish just the built bundle. Your framework source stays in your agency's repository; only the output ships to the site.

Keep your own source of truth

Since a pulled site is plain files, keep client projects in your own version control. That gives you history, review, and CI independent of the platform, while acira publish remains the step that takes a change live.