Limits
Loha is a fully managed platform. Every build runs on Loha-operated, per-workspace-isolated infrastructure: there are no self-hosted runners to provision or size. This page lists the constraints that shape what a build can do.
Limits come in two kinds:
- Fixed platform limits: the same for every workspace. Resource sizes, the timeout ceiling, and
.loha.ymlstructural caps. These are listed here with exact values. - Per-workspace caps: set for your workspace as part of its limit preset. Build minutes, parallel builds, seats, retention, cache, and which resource classes you can pick. These vary by workspace; this page describes the dimensions and where to change them.
Where builds run
Every pipeline runs on Loha's managed Kubernetes cluster. Each workspace gets its own isolated boundary: its own compute quota, filesystem, secrets, and default-deny network. A build in one workspace can never see another's. See Multi-tenancy & isolation for the guarantees.
There are no self-hosted runners. You do not bring, register, or maintain build machines; Loha schedules and isolates every run for you.
Resource classes
A pipeline picks a resource class, which fixes the CPU and memory available to every job in the run. Set it once at the top level with resource_class, or override it per job. The sizes below are fixed platform-wide: they are the same for every workspace and cannot be customized.
| Class | CPU (request → limit) | Memory (reserved = ceiling) |
|---|---|---|
micro | 100m → 250m | 256Mi |
small | 500m → 1 | 1Gi |
medium | 1 → 2 | 4Gi |
large | 2 → 4 | 8Gi |
small is the default when your workspace allows it. Which classes you may select is part of your limit preset: a build that requests a class your workspace isn't cleared for is rejected before it starts. See the .loha.yml schema for how to set resource_class.
m is millicores: 500m = half a CPU core, 1 = one full core. Memory uses binary units: Mi = mebibytes, Gi = gibibytes.
Memory is reserved, not shared. A class's memory figure is both the amount held for your job and the ceiling it may reach — Loha reserves the full amount up front, so no other build can take memory your job is entitled to, and a job that exceeds its class is stopped rather than being allowed to starve a neighbour. If a step is stopped for running out of memory, Loha names the step and the class in the build's error.
CPU can burst. The request is what is guaranteed; the limit is what a job may reach when the machine has spare capacity. Exceeding a CPU limit only slows a job down — it never stops it.
Timeouts and retries
| Limit | Value |
|---|---|
| Maximum build / step timeout | 24 hours |
| Default timeout | None (see below) |
| Maximum retries per step | 3 |
A timeout is a number followed by a unit: s (seconds), m (minutes), h (hours), or d (days), e.g. 30s, 10m, 2h, 1d. A build or step with no timeout runs until it finishes or hits the 24-hour platform ceiling, whichever comes first. Any timeout you set is also capped at 24 hours. See Timeout format for the field details.
Pipeline configuration limits
These caps are enforced when your .loha.yml is validated: an invalid config is rejected before any pipeline materializes, with a clear error.
| Limit | Value |
|---|---|
| Jobs per pipeline | 1–20 |
| Steps per job | 1–50 |
needs (dependencies) per job | 20 |
| Secrets per step | 20 |
| Retries per step | 0–3 |
run script size | 65,536 characters (~64 KB) |
| Document size | 1 MB |
| YAML anchors / aliases | 100 each |
Push trigger branches / tags | 20 each |
Push trigger paths | 50 |
Custom YAML tags are blocked, and run scripts are scanned for unsafe commands. For the full validation surface, see .loha.yml → Limits and security hardening and the Errors reference.
Per-workspace caps
These are set for your workspace as part of its limit preset: they are not fixed platform-wide and not pricing tiers. When a cap is reached, Loha blocks the action with a clear message rather than silently exceeding it.
| Cap | Dimension | When it bites |
|---|---|---|
| Build minutes | Minutes per usage period (~30 days) | Counted on every run; new runs are blocked once the cap is hit. Resets each period. |
| Parallel builds | Concurrent runs | New builds are queued or rejected once the cap is hit. |
| Resource classes | Which of micro/small/medium/large you can pick | A build requesting a class outside your preset is rejected at trigger time. |
| Build cache | Enabled, plus a maximum size | Older cache entries are evicted once the size cap is reached; disabled means no cross-build cache. |
| Log & history retention | Days of build history and logs kept | Older runs and their logs are pruned past the retention window. |
| Seats | Active members + pending invitations | New invitations are blocked once the cap is hit. |
| Repositories | Connected repositories | New repository connections are blocked once the cap is hit. |
| Scheduled triggers | Enabled schedule triggers | Creating or enabling one past the cap is blocked with SCHEDULED_TRIGGER_LIMIT. |
| Schedule interval | Minimum minutes between two firings of one schedule | A cron that fires more often is rejected when you save it. Never below 15 minutes. |
| Build insights history | Days of build metrics you can look back on | Older days are not shown on the Build insights page; the page tells you the window your preset allows. |
| API rate limit | Requests per minute per workspace | Excess requests receive 429 Too Many Requests. |
A self-signup workspace starts on the Free preset (60 build minutes, 1 seat, micro only). There is no self-serve upgrade flow yet: to raise a cap or change your preset, contact the Loha team. See Workspace activation for the Free caps and how paid presets are applied.
What retention deletes
Build logs and artifacts are kept for a retention window set by your workspace's limit preset: the window length varies by preset and is not a fixed platform value.
When a build run passes the retention window, an automated retention job hard-deletes the whole run, not just its logs. After that:
- The build's page returns not found.
- Its logs are unavailable, unless they were archived to object storage, in which case the logs may still be served from the archive.
There is no soft-delete or recovery for a pruned run. If you need a build's logs or artifacts long-term, export or archive them before the window passes.
Related reading
.loha.ymlschema: resource classes, timeout format, and the full field reference- Workspace activation: how limit presets are applied
- Multi-tenancy & isolation: the isolation guarantees behind the quota envelope