Remote Infrastructure

Turn on the server and runner when you actually need them.

Local stays the default. Add a remote authority only when shared state or managed CI solves a real coordination problem for you.

What the remote side covers

`ait-server`

Owns the remote protocol, the repository registry, shared workflow state, policy, and the Worker Job queue.

`ait-runner`

Picks up jobs it can handle, materializes the exact Snapshot, runs your repository's CI entrypoint, and sends back the results.

What changes once you go remote

Your repository registers with a server you picked.
Patchsets, CI results, attestations, policy, and closeout state can live on that server.
A runner can execute jobs against the exact Snapshot they reference.
Server and runner uptime, storage, auth, reachability, and version compatibility become yours to run.

Try 1.1.1 in a container

docker network create ait-native
docker volume create ait-native-data
docker run --detach \
  --name ait-server \
  --network ait-native \
  --publish 127.0.0.1:8088:8088 \
  --restart unless-stopped \
  --volume ait-native-data:/var/lib/ait \
  ghcr.io/weita2026/ait-server:1.1.1

curl --fail http://127.0.0.1:8088/healthz

The public GHCR images cover Linux arm64 and amd64. Binding to loopback keeps this off the public network until you deliberately put a secure ingress in front of it.

What you take on as operator

A bundled server sits inactive until you configure and start it.
Anything public needs your own answer for auth, TLS, network, backups, and upgrades.
Server and runner uptime, storage, monitoring, and compatibility are yours.

Start local, expand when you have a reason

A server should answer a real coordination problem. It shouldn't be something you set up before you can try AIT at all.