From Provision to Shutdown: The Lifecycle of a Tenki Runner

Whether you're running a simple unit test or orchestrating complex, multi-stage CI/CD pipelines, the compute infrastructure behind your workflows is critical. But too often, it's treated as an invisible layer.

At Tenki, we believe that understanding how your GitHub Actions runners work is essential—not just for developers and DevOps teams, but for anyone looking to optimize speed, reliability, and cost.

In this beginner-friendly article, we take you behind the scenes of a Tenki runner lifecycle: from the moment a job is triggered, all the way to its secure, automated shutdown.

Why Runner Lifecycle Matters

Most developers treat runners as a black box: you push code, a runner picks it up, and results appear. But knowing how runners are provisioned, isolated, and cleaned up can:

• Help you diagnose CI/CD bottlenecks
• Reduce your CI costs
• Improve security and compliance
• Boost observability and control

Understanding the lifecycle is especially helpful if you're moving away from GitHub-hosted runners or tired of managing a fragile self-hosted fleet.

The Lifecycle of a Tenki Runner

1. Job Triggered

Everything starts with a GitHub Actions event—like a push, pull_request, or schedule.

GitHub checks the job’s labels to determine which runner is eligible. If you're using Tenki, your workflow might look like:

runs-on: tenki-standard-autoscale

The job is then securely routed to Tenki through our GitHub App integration.

2. On-Demand Provisioning

Once a job request is received, Tenki instantly provisions a fresh runner:

• Provision ephemeral virtual machines (VMs) hosted on our dedicated bare-metal infrastructure.
• Applies a hardened, ephemeral runner image with:
• • Pre-installed GitHub Actions agent
  • Full job isolation and security patches

💡 Most runners spin up in ~20 seconds.

3. Secure Runner Registration

As soon as the VM is ready:

• It registers with GitHub using a short-lived, secure token
• Awaits job assignment
• Sends metadata (job ID, branch, repo) to Tenki for monitoring

Tenki ensures this connection is secure, verifiable, and ephemeral.

4. Workflow Execution

The assigned job now runs just as it would on a GitHub-hosted runner, but with your custom hardware and policies.

Typical tasks include:

• Checking out source code
• Installing dependencies
• Running tests or builds
• Deploying apps
• Uploading artifacts

✅ Tenki supports 100% of GitHub Actions features: composite actions, caching, Docker, secrets, matrices, and more.

You don’t need to modify your workflows. Just swap the runner label: runs-on

5. Post-Job Cleanup

After the job finishes:

• Logs and artifacts are uploaded to GitHub
• Cache save steps are executed (if configured)
• Secrets are revoked
• Usage metrics are collected (CPU, memory, duration)

Tenki also runs a custom cleanup hook to:

• Remove temp files and leftover processes
• Enforce compliance policies
• Sanitize the runner for full isolation

6. Ephemeral Shutdown

The runner is then securely and automatically destroyed:

• VMs: terminated and wiped
• Containers: stopped and removed
• No daemons, background tasks, or leftover data

This model guarantees:

• Zero resource drift
• Zero idle cost
• Zero contamination risk

Lifecycle Comparison: Tenki vs GitHub-Hosted Runners

o see why the runner lifecycle matters for your workflow performance, let's compare how Tenki and GitHub handle each phase:

What You Get with Tenki

Understanding the runner lifecycle reveals why Tenki delivers superior performance and cost efficiency. Here's what sets us apart:

• Lightning-fast provisioning using on-demand autoscaling
• Ephemeral runners for every job
• Zero-maintenance infrastructure (we handle the lifecycle)

Tenki runners behave exactly like GitHub-hosted runners—but they’re faster, cheaper, and more flexible.

Frequently Asked Questions (FAQ)

• Do I need to rewrite my GitHub workflows to use Tenki?
  No. Just change the runs-on label to match your Tenki configuration.
• How fast are Tenki runners to start?
  Most runners provision in 10–20 seconds.
• How does Tenki's user support work?
  We’re here to support users at every step of their journey with Tenki. If you run into any issues, simply reach out to us at hello@tenki.cloud and our team will respond as quickly as possible.
• Can I choose the cloud or region for my runners?
  For now, we support only the North America region.
• How is usage billed?
  Billing is per-minute with $10 free credit/month. No hidden fees.
• Is Tenki secure?
  Yes. Every runner is hardened, ephemeral, and registered with encrypted tokens.

Glossary

GitHub Actions: A CI/CD platform that lets you automate your development workflows.

Runner: The compute resource (VM or container) that executes GitHub Actions jobs.

Ephemeral: A runner that exists only for the duration of a single job, then gets destroyed.

Provisioning: The process of launching and configuring a runner.

Self-hosted Runner: A runner you own or manage, instead of using GitHub-hosted infrastructure.

On-demand Autoscaling: The ability to spin up new runners automatically when jobs are triggered.

Secrets: Encrypted environment variables used during job execution (like API keys).

Artifact: Files generated during a workflow (e.g., test logs, compiled binaries).

Compute Preset: A pre-defined VM or container spec (e.g., CPU, memory, GPU) chosen for the runner.

TL;DR

Understanding the runner lifecycle is key to optimizing CI/CD performance, cost, and security. With Tenki, each GitHub Actions job runs on an ephemeral, on-demand runner provisioned in ~20 seconds on your own cloud—no DevOps work required.

From job trigger to secure shutdown, Tenki automates:

• Fast provisioning on custom VMs
• Secure GitHub registration
• Full workflow execution with GitHub-native features
• Cleanup, monitoring, and instant teardown

Tenki delivers faster builds, lower costs, and zero idle overhead, while working seamlessly with your existing workflows. Just swap the runs-on label—no rewrites needed.