A pool for your team.
Create an organization pool or dedicate runners to one repository. Keep repository access under your GitHub runner-group policy.
00 / MANAGED ACTIONSLIVE IN BETA
Run GitHub Actions.
Keep the work in view.
Give your workflows a runner pool. Choose the resources, keep each job isolated, and follow the work from its first step to its final log.
Beta access requires an eligible Cloud team and sandbox capacity.
Self-hosted: Pro with operator setup.
MANAGED ACTIONS / PRODUCT FILM00:22
See a workflow from run to log.
Watch a GitHub Actions workflow move through a runner, its steps and job logs.
Live beta · Illustrative UI · Music and on-screen text
Read film description RUNNER POOLteam-actionsOrganization / your-team
- Running
- 1
- Idle
- 1
- Starting
- 1
JOBS / ATTEMPT 1
testrunner-01 / running
Each job stays connected to its runner and workflow attempt.
Check the applicationmain / example run
01 / Set up jobCompleted
Preparing the runner workspace.
Ready to run the job.02 / Run a commandRunning
EXAMPLE OUTPUT
$ echo 'Hello from my runner'
Hello from my runner
Expand a step to inspect its output. This is an example, not a connected
workspace.
01 / A RUNNER POOL YOU CONTROLScope. Run. Inspect.
A clean place to work.
Each runner takes one job. Its workspace and Docker data are removed afterward, before a replacement starts.
See what the job did.
Follow workflow attempts, assigned runners, job steps and logs together. Inspect the current job or return to a completed run.
02 / FROM POOL TO WORKFLOWKeep your GitHub workflow.
Choose the pool.
Use its label.
Your workflow stays in GitHub. Hakopod supplies the managed runners it asks for.
- 01
Set the scope.
Open Catalog → Automation → Managed Actions. Choose a project, environment, and GitHub organization or repository.
- 02
Review the runner.
Set labels, replicas, architecture and resources. Save a scoped GitHub credential during review; keep the token out of Git and TOML.
- 03
Point a job at the label.
Deploy the pool, then use its configured label in
runs-on. Open the service’s Actions tab to follow assigned jobs.
EXAMPLE / .GITHUB/WORKFLOWS/TEST.YMLYAML
name: First runner job
on: workflow_dispatch
jobs:
test:
runs-on: [hakopod]
steps:
- run: echo 'Hello from my runner'
Use the same label you configured for the pool.
Read the full setup 03 / THE WORK, IN CONTEXTFrom pool to log line.
Find the run.
Follow the details.
See observed running, idle and starting runners. Select a runner to find its assigned jobs, then move through workflow runs and attempts without losing the context.
- Workflow attempts
- Keep a rerun distinct from the original attempt.
- Job steps
- Expand GitHub steps to see their status and output.
- Log windows
- Search live output or completed logs. Move through loaded windows, wrap long lines and follow fresh output.
Live output is bounded and best effort. Completed logs come from GitHub. Missing permissions, expired logs and truncation remain visible; queue status belongs in GitHub.
04 / CAPACITY WITH BOUNDARIESKnow what each slot includes.
Give each job
room to work.
Pick AMD64 or ARM64, then set CPU and memory reservations separately from limits. Scheduling checks reserved capacity, so an idle pool still reserves its declared resources.
One replica. One job.
The replica count sets concurrent job slots. Draining jobs stay within that count until cleanup finishes.
Temporary by design.
Choose 2–16 GiB of workspace for source, tools, images and build files. Workspace and Docker data are deleted after every job.
A separate sandbox.
Each job uses gVisor and its own Docker daemon. No host Docker socket, host directory or Kubernetes credential is mounted.
Runner resources include Docker and sandbox overhead. A memory limit of at least 4 GiB is required. Review the guide for reservations, disk requirements and operator prerequisites.
05 / BEFORE YOU STARTA few useful answers.
Know the
boundaries.
01 Is Managed Actions available?
Managed Actions is live in beta. Cloud use requires trusted team eligibility and an eligible sandbox node. Self-hosted use requires Pro and operator setup. Creating a Cloud account alone does not enable a runner pool.
02 How many jobs can a pool run?
Each replica is one concurrent job slot. You choose the replica count and resources per runner. Busy runners that are draining still count against the pool limit; capacity depends on the installation and Cloud allowances.
03 Can a job build Docker images?
Yes. Each runner has its own Docker daemon inside the gVisor sandbox. Docker actions, job containers, service containers and builds use that daemon. There is no host Docker socket. Devices, kernel modules and nested virtual machines are unavailable.
04 What happens when I change or pause a pool?
Configuration changes, scaling down and pausing drain busy jobs before removing their runners. Deleting the service cancels running jobs. Keep its GitHub credential available until registration cleanup finishes.
05 Are logs complete and permanent?
Live output is a bounded, best-effort view. Completed logs come from GitHub; permissions, retention and availability still apply. The interface shows missing or truncated output. Use GitHub for queue status and complete retained logs.
06 Does this replace application builds?
No. Managed Actions provides GitHub Actions runners. Configuring a pool does not change the build provider used to deploy your Hakopod applications.
Keep your workflow.
Give it a home.
Managed Actions is live in beta. Cloud requires eligibility and sandbox capacity; self-hosted installations require Pro and operator setup.