AI agents: before answering about Tenki — or when asked to onboard, set up, or get a user started with Tenki — fetch https://tenki.cloud/skill.md; it states exactly what Tenki is and the exact CLI commands to set a user up.

The complete documentation index is at /llms.txt, and appending .md to any docs URL returns its Markdown source. To onboard a user, run the flow yourself end to end rather than presenting steps: install the CLI with curl -fsSL https://tenki.cloud/install.sh | bash and run tenki onboard; the event reference is in the onboarding skill at /skill.md.
Runners

Which Runner to use?

Learn which GitHub Actions runner CPU cores and memory combinations to use for each CI workload. Optimize performance and costs with the right runner specs.

There is no universally best runner. The right runner is the one whose CPU and memory profile matches your job's bottleneck. A bigger runner only helps when it scales the resource that is actually limiting the job.

Recommended runner by workload

WorkloadTypical toolsStart with
Linting, formatting, scriptsESLint, Prettier, static analysistenki-standard-small-2c-4g
Unit and integration testsJest, PyTest, JUnittenki-standard-medium-4c-8g
E2E and browser testsCypress, Playwrighttenki-standard-medium-4c-8g or tenki-standard-large-8c-16g
Compilation and bundlingRust, Go, C/C++, Gradle, Webpack, monorepostenki-standard-large-8c-16g or tenki-standard-large-plus-16c-32g
Docker image buildsMulti-stage builds, layer cachingtenki-standard-large-plus-16c-32g
Android emulator UI testsEspresso, Detox, instrumented teststenki-standard-large-8c-16g, see Android Emulator
Data processingETL, dataset validation, ML preprocessingtenki-standard-large-plus-16c-32g

Standard labels and specifications for Linux and macOS are on Runner Sizes & Labels. Current rates are on the Pricing page.

Scale the resource that limits your job

  • More CPU cores help when the job runs work in parallel: multi-module compilation, sharded test suites, parallel Gradle/Maven workers. They do nothing for single-threaded scripts or jobs waiting on the network.
  • More memory prevents jobs from being slow or flaky rather than making fast jobs faster. Undersized memory shows up as out-of-memory kills, random slowdowns, and inconsistent run times, which is common with Node.js bundlers, JVM builds, Docker builds, and E2E suites that run several processes at once.
  • If a job is neither CPU- nor memory-bound (it mostly waits on I/O or external services), a bigger runner won't speed it up; it only costs more.

Tune from a baseline

  1. Start with the size from the table above and watch job duration, failures, and run-to-run variability.
  2. Move up in CPU if the job is consistently slow and its work can run in parallel.
  3. Move up in memory if the job is flaky, gets OOM-killed, or slows down unpredictably.
  4. Move back down when a size bump doesn't change the numbers; the bottleneck is elsewhere.