> ## Content Index
> Fetch the complete content index at: https://www.tao.media/llms.txt
> Use this file to discover other available public pages before exploring further.

# Hippius Adds Per-Second GitHub Actions Runners on Confidential Virtual Machines
- URL: https://www.tao.media/hippius-adds-per-second-github-actions-runners-on-confidential-virtual-machines/
- Published: 2026-11-06T14:00:00.000Z
- Updated: 2026-11-10T16:36:45.000Z
- Description: The Bittensor cloud gives each CI job a disposable, encrypted machine, with three runner sizes and built-in cost tracking.
- Author: Tristan Hillerich
- Tags: Hippius, Subnets, News

Hippius has [launched GitHub Actions runners](https://x.com/Hippius%5Fcloud/status/2118337759597195319?ref=tao.media) that give every continuous integration job a fresh confidential virtual machine, then destroy it when the job ends. The Bittensor cloud service bills runners per second, with no charge for a machine that never executes a job.

After connecting a GitHub account, developers can direct a workflow to Hippius by changing its runner label. Three sizes are available, along with lower-cost SSD options and country-specific labels for choosing where a job runs.

The service combines disposable build environments with encrypted memory and disks. It also adds a spending dashboard that breaks down runner costs and compares eligible workloads with GitHub-hosted runners at GitHub's list prices.

## How the Confidential Runners Work

A runner is the machine that executes a GitHub Actions job, such as compiling software, running tests, or building a container image. Hippius creates a separate VM for each job rather than keeping a persistent machine available for successive workflows. Nothing is shared between jobs or accounts.

The runners use Hippius's [confidential computing architecture](https://docs.hippius.com/learn/confidential-computing?ref=tao.media), built on AMD EPYC processors with SEV-SNP. The processor encrypts VM memory so the server's operating system and hypervisor cannot read its contents. This protects workloads from the operators supplying the underlying hardware, which Hippius sources from compute miners.

Before releasing a VM's disk key, Hippius's key broker checks a processor-signed attestation report against its approved software and launch configuration. The writable disk is encrypted inside the VM. Hippius remains part of the trust model: it controls the approved images, key broker, and key vault. The hardware protections separate workloads from the hosting operator, rather than removing trust in Hippius itself.

Network access for runners is restricted. A VM can reach the internet, but it has no public IP address or SSH access and never joins the customer's private Hippius network. A workflow therefore cannot use its runner to reach that customer's other Hippius machines.

## Connecting GitHub and Preparing a Workflow

Setup starts under Confidential Computing → Runners in the Hippius console. Users install the Hippius Runners GitHub App on a personal account or organization, select all repositories or specific repositories, and authorize the connection. Linking an organization requires an organization owner.

The App requests repository Administration write access to register single-use runners and remove unused ones, Actions and Metadata read access, and organization Members read access to check ownership. Each runner is registered only on the repository whose job it serves, not across the organization.

Once connected, a workflow can select a runner through its `runs-on` field:

```yaml
on: push

jobs:
  build:
    runs-on: hippius-medium
    steps:
      - uses: actions/checkout@v4
      - run: docker run --rm hello-world
```

The environment runs Ubuntu 24.04 on x64, with Docker, Git, curl, jq, Python 3, and unzip. Jobs execute as a `runner` user with passwordless `sudo`.

It is not a replica of GitHub's hosted runner image. Developers should use `actions/setup-*` actions or container images for language toolchains that are not preinstalled. Hippius estimates three to five minutes from queueing to execution because each VM must boot and install Docker and the GitHub runner. Jobs have a six-hour execution limit.

## Runner Sizes and Per-Second Billing

The [runner documentation](https://docs.hippius.com/use/compute/runners?ref=tao.media) lists three standard NVMe-backed sizes. The hourly rates below are the listed equivalents used for per-second charging, not a requirement to reserve a machine for an hour or month.

| Runner Label   | vCPUs | Memory | Disk  | Listed Hourly Rate |
| -------------- | ----- | ------ | ----- | ------------------ |
| hippius-small  | 1     | 4 GB   | 20 GB | $0.0411            |
| hippius-medium | 2     | 8 GB   | 20 GB | $0.0795            |
| hippius-large  | 4     | 16 GB  | 30 GB | $0.1575            |

Billing has a one-minute minimum. The chargeable period starts one minute before the job begins, never before the VM was created, and ends when the VM is torn down. Most boot time is not billed. If a runner is canceled during startup or never takes a job, it costs nothing.

Adding `-ssd` selects an economy tier with the same CPU, memory, and disk capacity but slower startup. The listed hourly equivalents are $0.0362 for small, $0.0707 for medium, and $0.1405 for large. SSD runners take several additional minutes to start, and jobs wait for SSD capacity rather than falling back to NVMe.

A two-letter country suffix pins placement: `hippius-medium-fr` requests France, while `hippius-medium-ssd-fr` combines French placement with the economy tier. Without a country suffix, Hippius uses the account's default region or any region if no default is set.

Each launch also requires enough balance to cover 24 hours of the account's compute, including the proposed runner. This is a balance check, separate from the job's per-second usage charge.

## Job Controls and Cost Tracking

Accounts can restrict allowed runner sizes, choose a default region, and set concurrent-job limits. The concurrency setting defaults to five, but new accounts have a runner quota of three, and runners also count against CPU, memory, and disk quotas.

Public-repository jobs are disabled by default. Before enabling them, Hippius advises requiring approval for workflow runs from outside collaborators on GitHub, since their pull requests could otherwise trigger machines billed to the account.

The Jobs table tracks repositories, workflows, sizes, regions, queue times, execution times, and estimated charges. Refusals appear in Hippius's console; on GitHub, a refused job remains queued rather than displaying the refusal reason.

The Spend card shows billed credits, runner-minutes, job counts, daily spending, and breakdowns by repository, size, and workflow. Completed hourly bills supply the historical totals, while the open hour is estimated until it closes.

Its GitHub comparison matches small, medium, and large runners with Linux 1-core, 2-core, and 4-core offerings, respectively. It rounds job execution up to whole minutes at GitHub's list rates, then subtracts Hippius charges, including startup minutes, bandwidth, and running jobs. Public-repository jobs on small and medium runners are excluded because GitHub runs those free. The calculation does not account for free minutes included in a customer's GitHub plan, and the comparison is hidden when GitHub would not have cost more.