Skip to content

actuated

Actuated brings blazingly fast, secure builds to self-hosted CI runners.

Building containers on self-hosted runners is slow and insecure

Most solutions that use containers for running Docker or Kubernetes in CI have very poor security boundaries. They require either privileged containers (root on the host), a shared Docker socket (root on the host), third-party tools which don't integrate well and still require root to mount folders, or user namespaces which come with their own limitations. The chances are, if you use Docker or K8s in your CI, and run with: actions-runner-controller, Jenkins, or GitLab, then you may be compromising on security or user experience.

Management is a nightmare

Self-hosted CI runners are continually out of date, and require fine-tuning to get all the right packages in place and Kernel modules to build containers and cloud-native software. You'll also have to spend extra time making sure builds don't conflict, and that they can't cause side effects to system-level packages. What if you need two different version of some software?

If you haven't felt this pain yet, then perhaps you're blissfully unaware or are not updating your packages?

Are you running privileged containers for CI in your organisation? Are you sharing a Docker Socket (just as bad!)? Are you running Docker in Docker (DIND)? 🙈

Self-managed runners are inefficient and overprovisioned

Self-hosted runners are typically over-provisioned meaning you're spending too much money.

Why are they over-provisioned? Because you never know how many jobs you'll have to run, so you have to make them bigger, or have too many hosts available.

Why are they inefficient?

By default, the self-hosted runner will only schedule one job per host at a time, because GitHub has no knowledge of the capacity of your machines. So each and every build you run could consume all the resources on the host. The second reason is that builds often conflict with one another causing side effects that only happen in CI and are really difficult to track down and reproduce.

Actuated uses VMs to slice up the whole machine, and can run many builds in parallel. The net effect is that your build queue will get cleared down much more quickly.

Hands-free, VM-level isolation

Actuated provides a fast-booting microVM which can run Docker, Kubernetes and anything else you need, with full root on the VM, and no access to the host. Each environment is created just in time to take a build, and is removed immediately after.

Boot time is usually ~1-2 seconds for the VM, that extra second is because we start Docker as part of the boot-up process.

What does "actuated" mean?

Something that activates or impels itself; specifically (a machine, device, etc.) that causes itself to begin operating automatically, self-activating.

We maintain a VM image that is updated regularly through an automated build, so you don't have to install SDKs, runtimes or language packs on your build machines.

Just enable automated updates on your server then install the actuated agent. We'll do the rest including managing efficient allocation across your fleet of servers, and updating the CI image.

And actuated will run your jobs efficiently across a fleet of hosts, or a single machine. They each need to be either bare-metal hosts (think: AWS Metal / Graviton, Equinix Metal, etc), or support nested virtualization (a feature available on GCP and DigitalOcean)

What people are saying

Watch a live demo

Alex shows you how actuated uses an isolated, immutable microVM to run K3s inside of a GitHub Action, followed by a matrix build that causes 5 VMs to be launched. You'll see how quick and easy it is to enable actuated, and how it can buffer and queue up jobs, when there's no remaining capacity in your fleet of agents.

You can also watch a webinar that Alex recorded with Richard Case from Weaveworks on how microVMs compare to containers and legacy VMs, you'll see Alex's demo at: 1:13:19.

Conceptual overview

Conceptual flow of starting up a new ephemeral runner

Actuated will schedule builds across your fleet of agents, packing them in densely, without overloading the host. Each microVM will run just one build before being destroyed to ensure a clean, isolated build.

Learn more in the FAQ

Get started

Comparison

Feel free to book a call with us if you'd like to understand this comparison in more detail.

Solution Isolated VM Speed Efficient spread of jobs Safely build public repos? ARM64 support Maintenance required Cost
Hosted runners Poor None Free minutes in plan 1 Per build minute
actuated Bare-metal Yes Very little Fixed monthly cost
Standard self-hosted runners Good DIY Manual setup and updates OSS plus management costs
actions-runtime-controller Varies 2 DIY Very involved OSS plus management costs

1 actions-runtime-controller requires use of separate build tools such as Kaniko, which break the developer experience of using docker or docker-compose. If Docker in Docker (DinD) is used, then there is a severe performance penalty and security risk.

2 Builds on public GitHub repositories are free with the standard hosted runners, however private repositories require billing information, after the initial included minutes are consumed.

You can only get VM-level isolation from either GitHub hosted runners or Actuated. Standard self-hosted runners have no isolation between builds and actions-runtime-controller requires either a Docker socket to be mounted or Docker In Docker (a privileged container) to build and run containers.

Got questions, comments or suggestions?

actuated is trademark of OpenFaaS Ltd.

You can contact the team working on actuated via email at: contact@openfaas.com

Follow @selfactuated on Twitter for updates and announcements