Runner limits
This page lists the limits of Nerudo CI runners and the jobs that they run.
Job machine resources
| Resource | apple | podman, docker | kubernetes |
|---|---|---|---|
| CPU | --cpus, 1 to 64, default 4 | --cpus, 1 to 64, default 4 | --cpus, as requests and limits |
| Memory | --memory, default 4G | --memory, default 4G, no swap | --memory, as requests and limits |
| Processes | No limit | --pids, default 4096 | The node's limit |
| Workspace disk | No limit: the host's free disk | No limit: the host's free disk | --disk, as ephemeral storage |
/tmp | Memory file system | Memory file system | Counts against --disk |
| Root filesystem | Read-only | Read-only | Read-only |
| User | The image's user | The runner's user | UID 1000, or --run-as |
| Network | Outbound | The engine's default network | Internet only, if the network plugin enforces the shipped policy |
Sizes use binary units: 4G is 4 GiB, and 512M is 512 MiB.
The runner does not share caches between jobs. Each job starts with an empty workspace. Use a pre-built image to make jobs faster.
Time
| Limit | Value |
|---|---|
Job time, from the runner (--timeout) | Default 1800 seconds, maximum 21600 seconds. It includes the machine start. |
Job time, from the repository ([ci] timeout) | Default 1800 seconds, maximum 21600 seconds |
Step time (timeout-minutes) | Shorter than the job time |
| Machine start | 120 seconds on apple, 600 seconds on the other drivers. Change it with --start-timeout. |
| Runner offline | No call for 60 seconds |
| Job without reports | Sent again after 10 minutes, then failed as ci_crashed |
| Job not taken by a runner | After 10 minutes, the landing waits as ci_no_runner and tries again |
| Registration token | 1 hour |
Logs and records
| Limit | Value |
|---|---|
| Log kept for each job | The newest 2 MB |
| Log line | Cut at 4 KiB. The runner splits lines at 8192 characters. |
| Log buffer on the runner | 4 MiB or 8192 lines not yet sent. Later output is omitted, and the log says so. |
| Failed step's log in the change's reason | The last 28 KiB |
| Jobs kept for each repository | The newest 500 |
| Job definition | 1.5 MB |
| Steps for each job | 256 |
| Runner labels | 32, each up to 255 bytes |
| Secrets for each job | 64, each up to 64 KiB |
| Machine samples on the job page | 120, over the whole job |
The runner reads the job machine's memory and CPU every 5 seconds.
Workflow features
A runner runs the run: steps of one job. It supports name, id, working-directory, shell (bash or sh), env, defaults.run, if with success(), failure() and always(), and timeout-minutes.
These features are not available:
uses:actions, which includeactions/checkout. Check out withgitin arun:step.- Matrices, reusable workflows, services, and container jobs.
- Artifacts, caches, and output files such as
GITHUB_OUTPUTandGITHUB_ENV. - Expressions in step scripts. Put values in
env, then use shell variables. - Environment values with line breaks.
cancelled()steps.
A workflow with an unsupported key fails before its first step.
One job at a time
Each runner runs one job at a time. For more parallel jobs, register more runners. On Kubernetes, use one Deployment for each runner. See Run more than one job at a time.
See also CI runners and Troubleshoot a runner.