- AWS Cost Optimizer and GCP Recommender require weeks of utilization history on{' '}
- long-running instances. CI machines are ephemeral —
- they spin up, run a 5–30 minute job, then terminate. The cloud has no visibility into
- what your GitHub Actions runner or Jenkins agent actually did.
- RunRight captures the entire run in real time and produces a recommendation the
- moment the job finishes. Use it alongside Datadog or Sentry via OTLP — you don't
- have to choose.
-
- Drop one step into any CI workflow. RunRight monitors your job in the background,
- detects the machine it ran on, and recommends a right-sized alternative — saving
- you money without guesswork.
-
-
- No backend or API key needed to start. Just add one step, and recommendations
- appear in your job log and step summary.
-
-
- {[
- { title: '2 min setup', body: 'One action step. No sidecar, no DaemonSet, no infra changes.' },
- { title: 'No backend required', body: 'Recommendations work with file export alone. Backend is optional.' },
- { title: 'API key optional', body: 'Auth is disabled by default. Only enable it when you self-host.' },
- { title: 'Any runner', body: 'GitHub-hosted, self-hosted, GitLab, and Kubernetes runners are all supported.' },
- ].map(c => (
-
- The fastest path: file export only. No server, no database, no
- API key. The agent writes a metrics-summary.json artifact and prints
- recommendations directly to the job log and step summary.
-
-
-
Wrapper mode (recommended)
-
Wrap any command with run: — RunRight monitors it start to finish.
-
-
-
Standalone mode
-
Use step: start / step: stop to span multiple steps.
-
-
-
- Recommendations appear in the Job Summary tab of your GitHub Actions
- run — no extra setup required.
-
-
-
- {/* ── GitHub Actions ───────────────────────────────────────────── */}
-
-
- Install the binary in before_script and send SIGTERM in
- after_script — which always runs even when the job fails,
- so data is captured on OOM kills and runner disconnects too.
-
- Use Jenkins credentials bindings to inject RUNRIGHT_URL and
- RUNRIGHT_API_KEY, then run the monitor as a background process
- inside a sh block. Since Jenkins doesn't have an
- after_script, kill the monitor at the end of the same shell block.
-
- RunRight runs inside your CI job — not as a DaemonSet or sidecar.
- It auto-detects CPU and memory limits from cgroup v2 with no
- extra config on any K8s-hosted runner.
-
-
-
GitHub Actions self-hosted on K8s
-
-
-
Optional: Downward API for guaranteed limit detection
-
- If cgroup namespacing hides the container limits, inject them explicitly via
- RUNRIGHT_VCPUS and RUNRIGHT_MEMORY_GIB:
-
- The RunRight Helm chart deploys the backend and dashboard onto any Kubernetes
- cluster — EKS, GKE, AKS, or self-managed. It bundles a PostgreSQL subchart by
- default, or point it at an existing database with externalDSN.
-
-
-
Quick install
-
-
-
With an existing Postgres database
-
-
-
With an Ingress (EKS ALB controller)
-
-
-
-
- The Helm chart works identically on GKE (use nginx or gce ingress class)
- and AKS (use azure/application-gateway or nginx).
-
-
-
With an Ingress (GKE — Cloud Load Balancer)
-
-
-
-
K8s resource recommendations
-
- Every recommendation in the RunRight dashboard now includes suggested Kubernetes
- resource requests and limits based on observed p95 usage:
-
-
-
- Requests are set to p95 usage with headroom. Limits are set to peak usage with
- a safety margin — enough to absorb a spike without triggering an OOM kill or
- CPU throttle.
-
- The terraform/ module deploys RunRight on AWS Fargate with RDS
- PostgreSQL, Secrets Manager for credentials, CloudWatch logging, and an optional
- ALB target group attachment. All in one terraform apply.
-
-
-
-
- Set create_rds = false and external_dsn to bring your
- own Postgres (RDS in another account, Aurora, Neon, etc.).
-
- The terraform/eks/ module targets an existing EKS cluster. It
- provisions an optional RDS instance, creates a Kubernetes namespace and secret,
- then installs RunRight via the Helm chart using the Terraform Helm provider —
- so the whole stack is managed in one plan.
-
-
-
-
- Set create_rds = false and supply external_dsn to reuse
- an existing Aurora or RDS cluster shared across your platform services.
-
-
-
- {/* ── Terraform GKE ────────────────────────────────────────────── */}
-
-
Terraform — GCP GKE
-
- The terraform/gke/ module provisions a GKE Autopilot cluster, a
- Cloud SQL for PostgreSQL instance, and a Workload Identity binding so the
- RunRight pod can read secrets from GCP Secret Manager without a service-account
- key file. The Helm chart is then installed via the Terraform Helm provider.
-
-
-
-
- Workload Identity is enabled by default. The module creates a GCP service account,
- binds it to the Kubernetes service account in the runright namespace,
- and grants roles/secretmanager.secretAccessor so the pod can pull
- credentials without a JSON key file.
-
-
- Set create_cloud_sql = false and supply external_dsn
- to reuse an existing Cloud SQL or AlloyDB instance. Useful when RunRight shares
- infrastructure with other platform services.
-
-
-
- {/* ── Backend Setup ────────────────────────────────────────────── */}
-
-
Self-Hosting the Backend
-
- The backend is the recommended way to use RunRight at team scale. It gives you
- persistent job history, a shared dashboard, trend charts, and PR comment
- recommendations that update on every push. It's a single Go binary + Postgres —
- spin it up with Docker Compose.
-
-
- Self-hosting takes about two minutes with Docker Compose. Once running, point
- every workflow at it with http-url and all job data flows to a
- single place your whole team can view.
-
-
-
-
-
- {/* ── API Key ──────────────────────────────────────────────────── */}
-
-
API Key — When You Need It
-
- The API key is a server-side guard. It has nothing to do with getting
- recommendations — you get full machine sizing output without ever setting one.
- It only matters when you self-host the backend and want to restrict who can
- write to your dashboard.
-
-
-
-
-
-
-
Scenario
Need API key?
Why
-
-
-
- {[
- ['File export only (no backend)', 'No', 'Data stays local — nothing authenticates'],
- ['Backend, RUNRIGHT_API_KEY unset', 'No', 'Auth is disabled — dev mode'],
- ['Backend, RUNRIGHT_API_KEY set', 'Yes — set the same key in CI', 'Agent sends it as Authorization: Bearer'],
- ['Dashboard login', 'Yes — if backend has a key', 'Login screen checks it against the server'],
- ].map(([s, n, w]) => (
-
-
{s}
-
{n}
-
{w}
-
- ))}
-
-
-
-
-
- The agent reads RUNRIGHT_API_KEY from the environment automatically — no flag needed.
-
-
-
-
- Treat the API key like a password. Use your platform's secret store (GitHub Secrets,
- GitLab Variables, K8s Secrets) and never commit it to source control.
-
-
-
- {/* ── Env Vars ─────────────────────────────────────────────────── */}
-
-
- Add one line to your GitHub Action. RunRight samples CPU, memory,
- disk I/O, and threads throughout your build and stores a snapshot
- for every run, automatically.
-
-
-
-
02
-
Build a History
-
- The dashboard accumulates job history over time. As your build grows
- or shrinks, the data reflects it. No one-off audits, no spreadsheets.
- Everything is already there.
-
-
-
-
03
-
Get Accurate Recommendations
-
- RunRight scores every instance in the AWS and GCP catalog against
- your real workload history and ranks options by cost, headroom, and fit.
- Pick the right machine with confidence.
-
-
-
-
-
- {/* Features strip */}
-
-
- {[
- { Icon: IconMetrics, title: 'Real Metrics', text: 'CPU, memory, disk I/O and threads sampled live, not guessed.' },
- { Icon: IconCloud, title: 'AWS + GCP', text: 'Hundreds of instance types, kept fresh automatically.' },
- { Icon: IconExport, title: 'Any Exporter', text: 'File, OTLP, Prometheus, HTTP. Plug into your existing stack.' },
- { Icon: IconServer, title: 'Self-hosted', text: 'Your data stays on your infra. No third-party SaaS.' },
- ].map(f => (
-
-
-
{f.title}
-
{f.text}
-
- ))}
-
-
-
- {/* Works Everywhere */}
-
-
-
Works Everywhere You Run CI
-
Bare VMs, containers, K8s pods, DinD — detection adapts to the environment automatically.
-
-
-
-
-
EC2 / GCP VMs
- ZERO CONFIG
-
-
- Reads vCPU count and total memory from the OS, then matches against the catalog within a 2 GiB tolerance. Works on GitHub-hosted runners, self-hosted EC2, and GCP VMs.
-
-
-
-
-
-
Kubernetes + DinD Pods
- CONTAINER-AWARE
-
-
- Reads cgroup v2 (cpu.max, memory.max) or cgroup v1 equivalents. Reflects your pod's actual CPU quota and memory limit, not the underlying node's resources.
-
- Skip auto-detection with two env vars. Works for Azure VMs, ARM instances, on-prem, or any environment where OS-level resource counts are unreliable.
-
-
{`RUNRIGHT_VCPUS=4\nRUNRIGHT_MEMORY_GIB=16`}
-
-
-
-
-
-
- {/* CI integrations */}
-
-
Works in any CI
-
- Native GitHub Action or a two-line shell snippet. Pick whichever fits your stack.
-
-
-
- {/* Install section */}
-
-
SELF-HOST THE DASHBOARD
-
Install in minutes.
-
A Go binary + a Postgres database. One Docker Compose file brings it all up.
-
-
-
- {/* Step 01 */}
-
-
01
-
-
Generate an API key
-
RunRight authenticates the agent to the backend with a single shared secret. Generate one now and keep it in your CI secrets.
-
-
-
-
- {/* Step 02 */}
-
-
02
-
-
Start everything with Docker
-
One command starts the backend, dashboard, and Postgres. The dashboard is available at localhost:3000 once it's up.
-
-
-
-
- {/* Step 03 */}
-
-
03
-
-
Add the step to your CI workflow
-
Drop the RunRight step into any job above. It runs as a background process, samples every few seconds, and posts a summary when the job finishes. Your existing steps are untouched.
-
-
-
-
-
-
-
-
- {/* Compare teaser */}
-
-
- How does RunRight compare to Datadog, Grafana, Sentry, and AWS Cost Tools?
-
No seats, no usage caps, no SaaS. Self-hosted on your infrastructure.
-
- See full pricing →
-
-
-
- {/* FAQ */}
-
-
Quick answers
-
- {[
- {
- q: 'Does RunRight slow down my builds?',
- a: 'No. It polls /proc every 5s as a background sidecar. Under 5 MB RSS, under 0.1% CPU on the sampler. Your build time is not affected.',
- },
- {
- q: 'Do I need to change my application code?',
- a: 'No. RunRight wraps your existing CI step. No SDK, no annotations, no config file.',
- },
- {
- q: 'I already use Datadog. Do I need the RunRight backend?',
- a: 'No. Use --export otlp with OTEL_EXPORTER_OTLP_ENDPOINT pointing at your existing collector. The backend and Postgres are only needed for the self-hosted RunRight dashboard.',
- },
- ].map((item, i, arr) => (
-