Run GitHub Actions with Hakopod

Managed Actions is live in beta. Cloud requires an eligible team, an operator-provisioned sandbox node and available capacity. Self-hosted installations require the Pro capability and the optional Managed Actions runtime. Account signup alone does not enable a pool. Explore the product.

Create a runner pool#

1. Choose a project and environment, then open Catalog → Automation → Managed Actions.
2. Select a GitHub organization or a single repository. For an organization, repository access remains governed by the GitHub runner group's policy.
3. Choose labels, AMD64 or ARM64, concurrent slots, resources and maximum runner lifetime. Each replica is one job slot.
4. During review, save an application-scoped GitHub credential. Organization pools need Self-hosted runners: read and write; repository pools need Administration: read and write. Keep the token out of source files and TOML.
5. Review the plan and deploy the pool.

Use a pool label in GitHub#

This example requires a pool configured with the label hakopod:

name: First runner job
on: workflow_dispatch
jobs:
  test:
    runs-on: [hakopod]
    steps:
      - run: echo 'Hello from my runner'

The workflow stays in GitHub. A pool does not replace the build provider used for ordinary Hakopod application deployments.

Follow a job and inspect its output#

Open the service's Actions tab. Observed running, idle and starting counts describe the runner pool. Select a workflow run and attempt, inspect the assigned runner and expand individual GitHub steps.

Search live or completed log windows, wrap long lines, show timestamps, follow new output or download the available log. Live output is bounded and best effort; completed output depends on GitHub permissions, retention and availability. Missing or truncated output stays explicit. Use GitHub to check workflow queue state.

Plan the resources for each slot#

CPU and memory reservations are distinct from limits. Scheduling checks reserved capacity even when runners are idle. Each slot includes the runner, its Docker daemon and sandbox overhead. The documented minimum memory limit is 4 GiB; workspace storage is configurable from 2 to 16 GiB.

Source files, tools, Docker images and builds share the temporary workspace. Large builds may require more space than their compressed images suggest. Pick another runner type if the job cannot fit the supported runtime or disk allowance.

Keep jobs isolated#

Each single-job runner has its own Docker daemon inside gVisor. It does not receive a host Docker socket, host directories or Kubernetes credentials. Workspace and Docker data are deleted after the job. The GitHub runner-management token stays in control-plane secret storage; the runner receives a one-job registration.

Docker actions, job containers, service containers and Docker builds use the job's own daemon. This Linux sandbox does not provide arbitrary devices, kernel modules or nested virtual machines.

Change or remove a pool deliberately#

Scaling down, pausing and configuration changes drain busy jobs. Draining and cleanup-pending runners still count against the pool's replica limit. Deleting the service cancels its running jobs. Keep the GitHub credential available until registration cleanup finishes.

Prepare a self-hosted installation#

The Managed Actions sandbox is an explicit operator setup step, with runtime and cluster ownership checks. Use the verified installer kit for your installed release and plan the required maintenance window. External or multi-node clusters require their own eligible-node runtime setup. Follow the pinned operator guide for exact prerequisites and installation instructions.