📈 GH Trending Explorer 🎲 Surprise me

← all repos

AshishKumar4 / armada

git clone https://github.com/AshishKumar4/armada.git

Fast, mappable compute on Cloudflare Containers

+0
stars, 24h · #34,606
+~0
stars, 7 days · #35,081
+126
stars, 30 days · #3,893
126
★ total
4
forks · 5 open issues

Star history (as recorded here)

2026-10-20 · 126 ★ 2026-10-22 · 126 ★
LanguageTypeScript
LicenseMIT
Created2026-10-07 (15d ago)
Last push1d ago
Watchers0
OwnerUser

GitHub topics

Links

README excerpt
armada runs a command, or a TypeScript or Python function, over many inputs at once on Cloudflare Containers in your
own account. I run Kinu's and Dew's CI on it, and it can grade an RL trainer's samples.
- 100 videos re-encoded to 720p in 21 to 22 s on 100 containers, 1.3 to 1.4 times the slowest single encode. One
 container took 12 minutes for the same 100.
- A 90-row CI suite in 7 min 27 s on 13 containers, against 13 min 2 s on its 15-job GitHub Actions matrix.
- 2,048 MBPP code samples graded against their unit tests in 40 to 47 s on 210 to 255 containers.
- One `true` task came back 2.5 s after I sent it.
## Install
 [code] 
The script installs Bun if it's missing and puts armada in `~/.armada`. `armada deploy` logs in to
Cloudflare in your browser, or uses `CLOUDFLARE_API_TOKEN`. Containers need the Workers Paid plan.
## How it works
armada is a Worker, a few Durable Objects and an R2 bucket in your account, so your code and data stay there.
1. armada prepares each environment once. It starts a container from the recipe's base image, runs `setup` as root and
 `install` as the user, and snapshots the result. A changed recipe, or a changed file in `environment.key`, prepares
 a new one.
2. Containers start from the snapshot, with a fresh tmpfs on `/tmp` and `/dev/shm`. A start took a median 0.6 s, and
 its setup 0.5 s more.
3. Each container pulls task after task from the job's one queue, so none waits behind another's slow task. Items
 with a higher `weight` start first.
4. Results stream back as they land. A small output rides in the result; a large one, and every log, goes to R2.
Each task runs as the user `ci` in its own cgroup. `ARMADA_CGROUP` names it, and the task may make groups under it;
its path depends on how the job packs. armada stops anything a task leaves running. A task the platform loses runs
again, up to three attempts, so a task should be safe to run twice.
## Measured
| Workload | armada | Comparison |
|---|---|---|
| 100 generated 10-second 1080p clips, each encoded to 720p H.264 (`examples/video-720p`) | 21.1 s, 21.8 s and 22.3 s on 100 `small` containers (`bun bench.ts 100`) | 718.7 s in sequence on one `small` container, 7.2 s a video (`bun bench.ts 100 serial`) |
| A 90-row CI suite (Kinu at `0b74ff100`) | 7 min 27 s on 13 `medium` containers (`armada run 0b74ff100`) | 13 min 2 s on its 15-job GitHub Actions matrix (run 37672204809) |
| Dew's 195-task test suite | 12.2 min on 96 `medium` containers | 31.2 min for the same tasks on a 20-job GitHub Actions matrix |
| 2,048 MBPP code samples: 8 reference or altered programs for each of 256 problems (`examples/rlvr`) | 39.5 s, 40.1 s and 46.5 s on 210 to 255 `micro` containers (`python3 bench.py 256 8 map 256`) | 4,790 to 5,209 s of grading in all |
| A TRL GRPO step's 16 rewards (Qwen2.5-0.5B-Instruct on one RTX 4080, two runs of four steps) | 3.2 to 4.0 s | 7 to 15 s for the whole step |
| One task from a prepared snapshot | 2.5 s from sending it to its answer (`armad