GitHub Actions 1‑vCPU Linux Runner Now Generally Available

ReactNode.jsDevOps

GitHub Actions announced that 1 vCPU Linux runners are now generally available. These runners run jobs inside a container (not a dedicated VM), provide 1 vCPU and 5 GB RAM, and are limited to 15 minutes per job. They are intended for automation tasks, issue operations and short-running CI jobs; the official runner target is ubuntu-slim. (github.blog)

Why this matters for full‑stack teams

  • Cost and queue-time optimization: low-cost containers are a better fit for frequent, short jobs (lint, format, quick builds, auto-labeling, small tests), reducing spend compared with larger VM runners.
  • Faster feedback loop for developer productivity: short tasks that previously shared VM capacity can move to these lightweight runners and complete more quickly.
  • Clear job sizing boundary: the 15‑minute hard limit forces teams to separate very short automation jobs from heavy CI pipelines.

Key technical details (from the announcement)

  • Spec: 1 vCPU, 5 GB RAM.
  • Execution model: job runs inside a container with hypervisor-level 2 isolation; container is removed after the job completes.
  • Time cap: 15 minutes; jobs exceeding the limit will be terminated and fail.
  • How to target: use the new runner type ubuntu-slim in job definitions. (github.blog)

Practical checklist — what to do this week

  1. Audit workflows: list jobs under your .github/workflows that typically run <15 minutes (linters, formatters, small unit test shards, auto-responders, release-note generators).
  2. Move safe jobs to ubuntu-slim: update runs-on to ubuntu-slim for workflows identified above, test them in a branch.
  3. Watch for container constraints: because these run inside containers (not VMs), verify jobs do not rely on VM-only capabilities (privileged VM tooling, custom kernel features, long-lived mounts). If a job needs a full VM, keep a larger runner.
  4. Measure impact: compare runtime, queue times and billing before/after to quantify cost and latency improvements.
  5. Check installed software and limits: review the runner-images repo and the billing docs before mass migration to ensure required CLI tools and credentials behavior match your needs. (github.blog)

What not to move

  • Long-running build/test jobs that commonly exceed 15 minutes.
  • Jobs requiring privileged VM features (nested virtualization, full VM tooling).
  • Any job that assumes a persistent VM or long-lived state across runs.

Bottom line The ubuntu-slim runner gives teams a cheap, fast option for frequent short tasks that previously consumed larger, more expensive runner capacity. Auditing and moving eligible jobs will reduce cost and speed developer feedback, but test carefully for container constraints and the 15‑minute limit before broad adoption. (github.blog)

Source:

Source

Read Next