What is EJO? · EJO Documentation

What EJO does and how the master, agents, environments, bindings and deployments fit together.

EJO in short#

EJO is a deployment automation control plane. It builds, scans, signs and deploys your code to targets that run on Kubernetes or Docker, and it keeps a record of every run: which commit, which image, which environment, who started it and how it ended.

EJO has two parts:

Master: the hub that hosts the admin console, the API and every record (PostgreSQL). On EJO Cloud we run the master for you; you get your own master and database at your own address, such as acme.ejocloud.com.
Agent: a small process that runs in your network, on your Docker host or in your Kubernetes cluster. It connects out to the master, picks up work, runs the pipeline steps and reports back.

Your source code, secrets and workloads stay on your own infrastructure. The master only coordinates what runs where and when.

How it fits together#

   GitHub / GitLab / Azure DevOps
          │  push, pull request, tag (webhook)
          ▼
 ┌──────────────────────────────┐
 │  EJO master                  │
 │  acme.ejocloud.com           │
 │  binding → pipeline → run    │
 └──────────────▲───────────────┘
                │ the agent connects out (HTTPS):
                │ heartbeat, job claim, logs and results
 ┌──────────────┴───────────────┐
 │  Your network                │
 │  Environment "production"    │
 │   ├─ Agent (K8s or Docker)   │
 │   └─ Deployed workload       │
 └──────────────────────────────┘

A repository binding links a repository in your SCM to a pipeline and an environment, and says which events (commit, pull request, tag, schedule) start a run.
When a push arrives, the master creates a deployment (a run) and plans the pipeline's steps.
An online agent in that environment claims the job on its next heartbeat, runs the steps in order or in parallel, and streams the logs.
The result shows in the console and is also written to your SCM (GitHub, GitLab or Azure DevOps) as a commit status and a pull request comment.

Core concepts#

Concept	What it does
Master	The hub with the console, the API and the records. Every EJO Cloud customer gets their own master.
Agent	The process inside an environment that does the work. It works behind NAT and firewalls because it opens the connection itself.
Environment	A deploy target: a Kubernetes cluster or a Docker host. Agents register into an environment.
Repository binding	Repository + pipeline + environment + trigger rules.
Pipeline	The workflow made of steps: clone, build, scan, sign, deploy.
Deployment	One run of a pipeline. This is EJO's unit of work.
`.ejo` file	A file at the repository root that describes the service: name, description, owner and, optionally, the pipeline.

See Concepts for the full glossary.

What comes with EJO Cloud#

Your own EJO at <subdomain>.ejocloud.com, set up from ejocloud.com/signup in a few minutes.
GitHub, GitLab and Azure DevOps support. GitHub connects in one click with the shared "EJO Cloud" GitHub App, and you choose which repositories EJO can see; GitLab and Azure DevOps connect with a webhook and a token. See Connect your source control.
Sign up and sign in with Google or GitHub, and two-factor authentication (2FA) with an authenticator app.
Isolated previews (Review Apps) on Kubernetes for every pull request (merge request on GitLab).
Automatic SBOM and Trivy scan after builds, cosign signing and per-environment supply chain policies.
Deploy verification with automatic rollback, and rerunning a deployment from the step that failed.
Step packs, pipeline OIDC tokens, test intelligence and external secret managers (Vault, AWS, Azure, CyberArk).

Next steps#

Quickstart: from signup to your first deployment.
Concepts: the EJO glossary.
Installing an agent: put an agent in your own network.