saggar¶
Push anything, get a built artifact back, with the logs in a web page.
saggar.dev is the build service. Hand it a git URL, a directory or a
tarball, and it works out what the tree is, builds it in a disposable
environment, streams the live logs, and stores the artifacts. Green
artifacts come back as registries: docker pull and apt
install address them directly.
saggar.dev builds nothing itself. Your builds run on runners: machines paired with your account, usually your own hardware. The service queues the jobs and serves the results; the runners do the computing. Pair one from a laptop or a home PC in a few minutes (see Pair your own runners).
Two programs touch your machine:
saggarThe client: submit,
download,logs. The loop’s human and agent side.saggar-workerThe runner: run it on a machine you want builds to happen on and pair it with your account (see Pair your own runners).
The web app covers the same ground in the browser: sign in, import projects, follow live logs, browse artifacts, manage your runner fleet. An account comes from your Gitea or GitHub login; saggar.dev stores no passwords.
Where to start¶
How-tos take a goal and carry it through, start to finish:
How-to
The reference aims to be complete, precise, and boring in the good way:
Conventions used throughout:
The CLI talks to
https://saggar.devby default;--serverpoints a command at another instance (see Connection settings).API paths are written relative to the management prefix
/api/v1(see The management API for what mounts where).A runner is a machine that builds, a build is one job, an artifact is what a green build leaves behind. The CLI’s
saggar nodecommands and the wire protocol say “worker” and “node”: same thing, different word.