Self-hosted CI runners on Wolkra

Updated 2026-10-30

A CI runner on Wolkra is a cloud server in Frankfurt that executes your pipeline jobs, billed by the hour, so you can run a fast build machine only when you need it and pay no per-minute fees.

Runners get full root access, unmetered traffic for image pulls and artifacts, and Docker in one click.

Why run your own runners

• Choose the hardware. Pick a CPU-optimised plan for compiles or a memory-optimised plan for large test suites.
• Warm caches. Dependencies, Docker layers and build caches stay on the runner between jobs.
• No per-minute pricing. You pay for the server's hours, not each job's minutes.
• Code stays in Germany. Source, secrets and artifacts are processed on servers in Frankfurt. See EU VPS and GDPR.
• Private access. Runners in a private network can reach internal databases and staging servers without exposing them.

Supported runners

Anything that runs on Linux works on a KVM VPS, for example:

• GitLab Runner, including with our GitLab app
• Self-hosted GitHub Actions runners
• Forgejo, Gitea and Woodpecker runners
• Jenkins agents, Buildkite agents and similar

Most runners use Docker to isolate jobs. The Docker app installs Docker CE with Compose, so a new runner only needs the runner software and a registration token.

Sizing runners

• Linting, unit tests, small builds: a Standard (s) plan.
• Compiling, bundling, building container images: a CPU-optimised (c) plan.
• Large test suites, databases in tests, JVM builds: a memory-optimised (m) plan.

Watch the CPU and memory graphs while jobs run and resize when builds wait on resources. See monitoring.

Patterns that work well

Always-on runner

One or two runners that are always available. Simple, with caches always warm. Good for small teams with steady commits.

Burst runners

Keep one base runner, and add more during busy hours or release days. Because billing is per started hour and capped at the monthly price, a runner that exists for four hours costs four hours. Delete it afterwards.

Autoscaling with the API

Use the REST API with a project-scoped token to create runner servers when the job queue grows and delete them when it empties. Pass cloud-init user data that installs and registers the runner on first boot, or create runners from a prepared snapshot so they start ready.

Token tips:

• Give the autoscaler its own project, so its token can only touch runner servers.
• Use a read/write token with an expiry and an IP allow list for the machine that runs the autoscaler.

Isolated runners for sensitive jobs

Run deployment jobs on a separate runner in a private network, with no public IP. A NAT gateway gives it outbound access to pull images and packages, and nothing on the internet can reach it directly.

Security checklist

1. Use SSH keys and disable password sign-in.
2. Attach a free firewall with no inbound ports except SSH. Runners usually only make outbound connections.
3. Don't run untrusted pipelines from public forks on runners that hold production secrets.
4. Keep the runner software and the OS updated, or replace runners often from a fresh image.
5. Use labels on runner servers, so one firewall rule set applies to all of them.

Storage for caches and artifacts

Build caches grow quickly. Attach a block storage volume from 10 GB to 10 TB for caches or a local registry, and grow it online when it fills up. Volumes can be formatted and mounted for you.

Caching tips

Keep a shared dependency cache on the runner, reuse Docker layers by ordering Dockerfiles from least to most changed, and clean old images on a schedule.

Why Wolkra for CI

• Hourly billing with a prepaid balance and no contracts. See hourly billing.
• Unmetered traffic on ports up to 10 Gbit/s, shared, with fair use. Base images, dependencies and artifacts don't add up to a bandwidth bill. See network.
• Low latency across Europe from the centre of Europe, close to European Git hosts and registries.

For broader container workflows see Docker hosting and development environments.

Add your first runner

Create an account, launch the Docker app in Frankfurt, and register it with your CI system in a few minutes.