Infrastructure#
Master#
The control plane that hosts the console, the API and every record. On EJO Cloud every customer has their own master and their own database, running at <subdomain>.ejocloud.com. The master never connects into your network; agents connect to the master.
Organization#
The organization you name when you sign up for EJO Cloud is your own EJO. Users, environments, pipelines and settings belong to it. Organization settings live under Settings > Organization.
Environment#
A deploy target where workloads run. There are two types:
| Type | When |
|---|---|
K8S |
You deploy to a Kubernetes cluster (or a namespace in it). |
DOCKER |
You run containers on a Docker host. |
An environment does no work by itself; the agents registered into it do. Approval requirements, freeze windows, the supply chain policy, deploy verification and preview settings are kept on the environment. See Environments.
Agent#
The process inside an environment that runs the work. It opens the connection to the master itself, so it works behind NAT and firewalls without opening any port. Statuses:
| Status | Meaning |
|---|---|
PENDING |
Registered, no heartbeat yet. |
ONLINE |
Sending heartbeats on schedule and can take work. |
OFFLINE |
Missed its heartbeat window. It turns ONLINE again by itself when it reconnects. |
See Installing an agent.
Registration token#
A one-time token an agent uses to register with the master on first start. It is valid for 1 hour by default. After registering, the agent uses its own long-lived token.
Delivery#
Repository binding#
The record that links an SCM repository (GitHub, GitLab or Azure DevOps) to a pipeline and an environment. Which events start a run (commit, pull request, tag, schedule), merge gates, preview settings and the promote target are kept on the binding. See Triggers and bindings.
Pipeline and pipeline version#
A pipeline is the workflow made of steps. You can edit it in the console or keep it in the repository in ejo.yaml or .ejo. Publishing a pipeline creates an immutable version, and bindings are pinned to a version: publishing a new one does not change what runs until the binding is upgraded.
Step#
One unit of work in a pipeline: GIT_CLONE, DOCKER_BUILD, KANIKO_BUILD, TRIVY_SCAN, COSIGN_SIGN, K8S_DEPLOY, SHELL and so on. Steps are wired with depends_on, can be multiplied with a matrix, and can run conditionally with if and paths. See Pipeline definition.
Step pack#
A package of reusable, versioned steps. Each step runs in a container image and is called from a pipeline with uses: <pack>/<step>@<version>. See Step packs.
Deployment (run)#
One run of a pipeline; EJO's unit of work. Statuses:
| Status | Meaning |
|---|---|
PENDING_APPROVAL |
The environment needs approval; waiting for it. |
PENDING |
Waiting for an agent to claim the job. |
WAITING |
Waiting on a condition (for example, the result of the PR pipeline behind a merge gate). |
RUNNING |
An agent is running the steps. |
SUCCEEDED |
Every step succeeded. |
FAILED |
At least one step failed. |
CANCELLED |
Cancelled. |
SUPERSEDED |
A newer push to the same branch or PR replaced this run. |
The event (Event) that starts a run is one of commit, pull_request, tag, manual, schedule, promote, rollback, teardown.
Promote and rollback#
Promote takes the commit of a successful run (on Kubernetes, its recorded image digest, without a rebuild) to another environment. Rollback returns an environment to a version that ran successfully before. EJO can also roll back automatically when deploy verification fails. See Deploy verification and rollback.
Preview (Review App)#
A temporary deploy for a pull request (merge request on GitLab), in its own namespace on Kubernetes, with its own URL. It is removed when the PR is closed, merged or abandoned. See Preview apps.
Merge gate#
Blocking a merge until the pull request (merge request on GitLab) pipeline succeeds. EJO keeps the main pipeline WAITING and also blocks on the SCM side: a ruleset that requires the ejo status on the target branch on GitHub, Pipelines must succeed on the project on GitLab, and a Status branch policy on the target branch on Azure DevOps. See Connect your source control.
Approval and freeze window#
An environment can hold runs for approval with Require manual approval for deployments. Freeze windows stop new deploys at given times; rollback and preview teardown still work.
Release train#
Runs several bindings in a defined order. Managed under Delivery > Release trains.
Catalog and sources#
Service and .ejo#
The .ejo file at the repository root describes the service: name, description, owner and optionally a pipeline and an environment. A repository with a valid .ejo appears as a service under Services > Catalog. See The .ejo file.
Sources (SCM group)#
A GitHub organization, GitLab group or Azure DevOps project added to the organization. EJO scans its repositories and shows the .ejo status of each under Services > Sources.
Variables and secrets#
Values used in step configs as {{.KEY}}. The types are PLAIN, SECRET, K8S_SECRET and EXTERNAL_SECRET; the scope can be global, repository or environment. See Secrets and variables.
Images and SBOMs#
Images that build steps push to a registry are recorded under Infrastructure > Images, each with its SBOM, vulnerability scan and signature. See Supply chain security.