Run ax as a service

SSH deployment configures the runner to accept commands without keeping an SSH session open. The service and job-supervisor roles use the same ax executable.

User installation

User mode is the default:

ax deploy ssh user@build-host --name buildbox

The runner service and jobs run as that user. On the runner, inspect the service and its logs on Linux with:

systemctl --user status ax.service
journalctl --user -u ax.service

Starting the user service at boot requires a working user manager and lingering. Deployment reports boot_enabled. If it reports false, an administrator may need to enable lingering for the job account.

On macOS, inspect the user service with:

launchctl print user/$(id -u)/dev.getaster.ax.host

The logs are ~/.local/state/ax/host.stdout.log and host.stderr.log. Deployment registers startup for user login. Individual job supervisors are separate from the host API, so an API restart does not stop their work.

System installation

For a machine-wide Linux service, add --system. This requires root access or noninteractive sudo during deployment:

ax deploy ssh user@build-host --name buildbox --system

The API runs as ax-service-user. A privileged helper launches jobs as the SSH account, or the non-root account selected by --run-as. System installation does not make ordinary jobs run as root.

On the runner:

systemctl status ax.service ax-helper.service
journalctl -u ax.service -u ax-helper.service

Upgrade or remove

Repeat deployment with the intended compatible binary or bundle to upgrade. The installer preserves identities and owner settings and checks readiness. An identical artifact can be reconciled without changing its installed bytes.

Removal is a separate operation. Start with its plan and inspect the selected scope and running-job report; see remove an installation.

For configuration paths, activation checks and detailed behavior, use the SSH deployment reference. For permissions, read access and execution accounts.