Concepts
Aetheus manages two things that are usually split across separate tools: the servers you own, and the deployments that run on them. Everything in the product is expressed with the handful of objects below.
Organisations, projects and permissions
An organisation is the top-level tenant. Every other object belongs to exactly one organisation, and nothing is shared across organisations implicitly.
A project groups everything related to one application: its Git repositories, its pipelines, its environments, its releases and its artefacts. Most day-to-day navigation is scoped to a project.
Permissions are granted per resource type and per resource. A user who can read a project does not automatically get to launch its pipelines or read its vaults.
Servers and agents
A server is a machine you own. Aetheus does not reach into it over SSH from the control plane; instead, an agent runs on the machine and polls the backend for work. That inversion is what lets a server behind NAT or a restrictive firewall still participate, as long as it can reach the API over HTTPS.
Agents exist for Linux and Windows. They are installed from an archive downloaded from the app, registered with a one-time token, and then run as a systemd unit or a Windows service. Once registered, an agent reports heartbeats, collects host inventory (services, disks, packages, certificates) and executes pipeline work assigned to it.
An agent that stops sending heartbeats is marked offline. Work that was routed to it is not silently lost: the scheduler can wait for a configured runner to come back rather than failing the run outright.
Pipelines and runs
A pipeline is a YAML document describing stages and steps. The definition is Git-first: it lives in the repository under .pipeline/<slug>.yaml, and the backend re-reads it from the canonical repository on every launch. Pushing a new definition is therefore enough for the next run to use it, with no separate synchronisation step.
A run is one execution of a pipeline. It pins the source revision it builds, resolves its variables once, then dispatches each stage to an eligible agent. Each run carries a per-pipeline sequential number, exposed to steps as BUILD_PIPELINE_RUNNUMBER. It is a build counter, not a semantic version: it increases on every launch of that pipeline, including launches that fail or are cancelled.
Artefacts and releases
An artefact is a file or set of files a stage produces and hands to later stages, or to later runs. Artefacts are stored by the backend, attributed to a project, and subject to a storage quota.
A release records that a specific revision was published to a target. A release links back to the run that produced it, to the commit it was built from and to the artefacts it shipped, so a rollback has a precise object to roll back to.
Environments
An environment is a named deployment target inside a project, such as staging or production. Environments carry their own checks: a pipeline that deploys to a protected environment can be refused before it runs if the environment's conditions are not met.
Variables, variable libraries and vaults
Steps read values through $(NAME) substitution. Those values come from three places, in increasing order of confidentiality:
- Pipeline variables, declared in the YAML itself. Suitable for anything you are happy to read in the repository, such as ports or public URLs.
- Variable libraries, named sets of values shared between pipelines. A pipeline only sees a library it explicitly lists; libraries are never applied implicitly.
- Vaults, for secrets. Values are encrypted at rest and injected into the step process rather than written into the definition. A pipeline that references a missing vault is refused rather than run with an empty value.
Quality, analysis and supervision
Beyond deployment, Aetheus collects test results, coverage, lint findings and static-analysis reports produced by pipeline steps, and renders them per run and per project. Analysis gates can block a run when a report crosses a threshold.
On the infrastructure side, agents feed dashboards covering host health, running services, disk and storage growth, TLS certificate expiry and security tooling. This is the half of the product that keeps working when no pipeline is running.
Where to go next
- Architecture - which processes exist and where state lives.
- Pipelines - the anatomy of a pipeline YAML.
- Install - get a running instance.