Why it’s different
Most CI platforms assume the build system is incorrect: incremental state might be stale, so every job gets a clean, cold worker that re-does all the work. Bazel guarantees correctness, so Workflows hosts it the opposite way: runners stay warm, with Bazel’s analysis cache in memory and the output base on local NVMe, and only genuinely new work executes. What that means for you day to day:- Your PR feedback loop shrinks. A cached
bazel test //...returns in seconds, not the 10+ minutes a cold runner spends re-fetching and re-analyzing the world. - It runs in your infrastructure. Source code, secrets, and artifacts never leave your network. That includes locked-down environments: GovCloud, air-gapped, and infrastructure with strict security requirements.
- Big CI savings, before adopting RBE. Runners use the same self-hosted runner mechanism your CI provider already supports (GitHub Actions, CircleCI, GitLab, Buildkite). If you’re on ephemeral runners with long build times today, the warm pool cuts CI time and compute costs immediately, with no remote-execution migration. RBE is in the deployment from day one for when you’re ready for it; until then you don’t have to touch it.
- Your hardware, your choice. Pick the exact runner configuration: instance type, architecture, CPU, memory, GPUs, NVMe. Multiple runner groups let different CI jobs run on different machine types. If your tests need hardware your CI provider doesn’t offer, like GPU instance types for AI workloads, this is how you get it.
- Delete your CI scripting. The AXL task system replaces the pile of shell scripts and YAML.
aspect lintdoes the same thing on your laptop as in CI, so “works on my machine” stops being a category of bug. - No lock-in. The cache and execution speak standard REv2, tasks run on plain Bazel, and the Aspect CLI is free and open source. Nothing about your build depends on us to keep working.
- Tuned by Bazel experts. The engineers operating your deployment maintain
rules_py,rules_js,rules_lint, and a broad portfolio of Bazel open source.
Deployment options
Self-hosted (your cloud): Workflows deploys into your AWS or GCP account via Terraform. Your source code, secrets, and build artifacts never leave your infrastructure. A dedicated cloud project keeps cost attribution and access policies isolated from other systems. Aspect Cloud (hosted): Aspect operates a fully isolated, single-tenant deployment on your behalf. You get the same performance and feature set without managing cloud infrastructure.Core components
CI runners: Auto-scaling, self-hosted runners that automatically register with your existing CI system (GitHub Actions, CircleCI, GitLab, or Buildkite) and keep Bazel’s in-memory state and a populated NVMe-backed output base warm across jobs. Multiple runner groups run different jobs on different machine types. New runners restore from a warming archive with Bazel’s fetch phase already done, so even a first job skips dependency downloads. The pool scales up to demand and back down to zero when idle. Remote cache: A content-addressable cache co-located with your runners in the same VPC. Bazel checks the cache before executing any action; on a hit, the output is fetched and the action is skipped. Remote Build Execution: An auto-scaling worker fleet that executes Bazel actions in parallel across many machines, scaling up to demand and back down to zero when idle. On a cache miss, work fans out horizontally rather than serializing on a single runner. Define multiple RBE platforms the same way you define runner groups: each with its own container image and instance type (arch, CPU, memory, NVMe, GPUs), and multiple worker size classes per platform with automatic size and memory matching per action. Docker-based tests are fully supported on workers. External remote cache and execution: Expose the same cache and execution clusters to developer workstations and external build clients, authenticated via your SSO provider. Selective delivery: Delivers only the targets whose Bazel-built outputs actually changed, driven by the same build graph you already trust. AXL tasks:aspect build, aspect test, aspect format, aspect lint, aspect gazelle, and aspect delivery replace hand-written CI scripts. Each task handles Bazel flag configuration, artifact upload, and CI platform integrations (GitHub Status Checks and PR comments, GitLab job annotations and MR comments, Buildkite Annotations) internally.
Marvin: GitHub & GitLab bot: Marvin adds status checks, posts PR comments, and annotates code reviews on GitHub and GitLab, streaming build results, test failures, and lint findings as the job runs, with one-click suggested fixes.
Build & Test UI: Triage build and test failures fast, with full invocation capture: searchable logs, target outcomes, and downloadable build profiles. Sits behind your SSO (OIDC or SAML), with SCIM provisioning.
CI platform support
Aspect Workflows integrates with GitHub Actions, Buildkite, GitLab CI/CD, and CircleCI. Your pipeline callsaspect <task> in each CI step; the tasks self-configure based on the runner environment and CI provider.
Browse live examples
Theaspect-build/bazel-examples repo runs on Aspect Workflows across all four supported CI providers. Source lives in two places: GitHub (used by the GitHub Actions, Buildkite, and CircleCI pipelines) and GitLab (used by the GitLab CI pipeline).
Getting started
- Evaluating Workflows? Start a free trial. We deploy into your cloud (or ours) and you measure the results on your own repository during the 30-day trial.
- Want a feel for the tooling first? Install the free Aspect CLI. It’s the same task system Workflows runs in CI, and it works in any Bazel workspace in minutes, no account required.
- Ready to deploy? Aspect handles the deployment end to end, into a dedicated cloud account on your cloud or on Aspect Cloud, and operates it from there: provisioning, monitoring, upgrades, and 24/7 expert support. We deploy into high-compliance environments too: GovCloud, air-gapped, and infrastructure with strict security requirements.