agola: Open Source Orchestration & Scheduling

What is agola?

What it is

Agola is an open-source CI/CD platform written in Go and released under Apache-2.0. It lives in the DevOps ecosystem, where teams need continuous integration, delivery, and deployment pipelines for Git repositories and containerized execution environments.

It addresses fragmented and non-reproducible pipeline management. Agola treats run definitions as committed artifacts inside a Git repository, starts them from pushes or pull requests, and executes tasks in containers across supported executors. This gives teams one tracked workflow model for building, testing, and deploying software from multiple Git providers.

Key capabilities

Git-based workflow: run definitions are committed inside the repository, and Runs start from push or pull-request events.
Multi-provider integration: GitHub, GitLab, and Gitea repositories can be used inside the same Agola installation.
Scalable deployment: Agola can move from a single instance in a single process to a distributed, high-availability deployment on Kubernetes, IaaS, or bare metal.
Containerized Runs: workflows support fan-in, fan-out, matrixes, dependency caching, restartable or reproducible execution, and at-most-once deployment behavior.
Direct user testing: User Direct Runs let users test software with the same run definition through a single command, while jsonnet and secrets or variables make Runs configurable and testable.

Who uses it and how

Teams maintain repositories on GitHub, GitLab, and Gitea, centralize CI/CD definitions in one Agola installation, and trigger Runs from push or pull-request events.
Platform engineers deploy Agola on Kubernetes, IaaS, or bare metal and execute tasks with container executors such as Docker or Kubernetes.
Developers use User Direct Runs to validate committed run definitions without needing a very powerful workstation, while release engineers model build and deploy workflows with fan-in, fan-out, matrixes, secrets, variables, and dependency caching.

Getting started

The README points users to the agolademo example for a try-it deployment and describes installation as manageable from a single instance to a distributed setup on Kubernetes, IaaS, or bare metal. It does not name a package manager, Docker image, or hosted option in the excerpt.

When to use it — and when not to

Agola fits teams that want Git-committed, containerized CI/CD runs and multi-provider integration across GitHub, GitLab, and Gitea. It is less suitable when a production-ready permissions system is required, because the README describes that capability as work in progress, or when a managed hosted service is expected, because the excerpt provides only a try-it example and self-managed deployment options. Self-hosters must operate the chosen infrastructure and executors, including Kubernetes, IaaS, or bare metal, and manage secrets, variables, and run definitions themselves.

project readme (upstream, from github) — read inline

Agola

CI/CD redefined

For an introduction to agola you can take a look at this post

Try it

See the agolademo example

Features

Easy to install and manage.
Scalable and High Available: go from a single instance (single process) deployment to a distributed deployment.
Deploy anywhere: Kubernetes, IaaS, bare metal and execute the "tasks" anywhere (currently containers executors like docker or orchestrators and Kubernetes, but easily extensible to future technologies or VMs instead of containers).
Support any language, deployment system etc... (just use the right image)
Integrate with multiple git providers at the same time: you could add repos from github, gitlab, gitea (and more to come) inside the same agola installation.
Use it to manage the full development lifecycle: from build to deploy.
Tasks Workflows (that we called Runs) with ability to achieve fan-in, fan-out, matrixes etc..., everything containerized to achieve maximum reproducibility.
Git based workflow: the run definition is committed inside the git repository (so everything is tracked and reproducible). A run execution is started by a git action (push, pull-request).
Design it with the ability to achieve at most once runs: during a deployment to production we don't want multiple concurrent execution of the deploy...
Restartable and reproducible Runs (restart a run from scratch or from failed tasks using the same source commit, variables etc...)
User Direct Runs: give every user the power to test their software using the same run definition used when pushing to git/opening a pull request inside the Agola installation with just one command like if they were running tests locally (without requiring a super powerful workstation).
Testable "Runs" (what is a CI/CD environment if you cannot test your changes to the Runs definitions?): use the same run definition but use a powerful secrets and variables system to access different resources (environments, docker registries etc...).
Don't try to extend YAML to be a templating language but use a real templating language (as of now jsonnet) to easily generate the run configuration without side effects.
An advanced permissions system (work in progress).
Dependency Caching to speed up tasks

Documentation

https://agola.io/doc/

Local development

See how to develop agola

Contributing to Agola

Agola is an open source project under the Apache 2.0 license, and contributions are gladly welcomed! To submit your changes please open a pull request.

Contacts

For bugs and feature requests file an issue
For general discussion about using and developing Agola, join the agola forum

Frequently asked questions

Is agola free to use?

agola is open source under the Apache-2.0 licence. There is no licence fee and no seat count — you can self-host it or, where the project offers one, pay a vendor for a managed version instead.

What does agola do?

Agola: CI/CD Redefined

What is agola written in?

agola is primarily written in Go. Its source is publicly available at https://github.com/agola-io/agola, and it has 1,622 GitHub stars.