What Aspect Workflows stores
Aspect Cloud
Aspect Cloud is Aspect’s multi-tenant service. It runs the remote cache and the Build Results UI on infrastructure Aspect operates, in Aspect’s cloud account, shared between customers.
If your policy requires infrastructure and data no other customer shares, or data in your own cloud account, choose Aspect Enterprise. Choosing Aspect Cloud or Aspect Enterprise compares them.
Aspect Enterprise
Aspect Enterprise is an isolated deployment for your organization, hosted by Aspect or self-hosted. A third option, on-prem (coming soon), deploys with a Helm chart on your own hardware.Runner state
Runners check your repository out the way your existing CI runners do, using credentials your CI provider issues. That checkout sits on the runner’s local disk, persists between jobs, and goes away when the runner is recycled. Apart from the runner’s checkout and the source files Bazel uploads to the cache as action inputs, no part of the deployment stores your source.Where it lives
Both Aspect Enterprise options give you data isolation: no other customer shares your cache, your workers or your build event database. Self-hosted adds data ownership: the account, the cloud bill, the credentials, the retention policy and the audit trail are yours, and build data never leaves infrastructure you control.Who at Aspect can reach it
On an Aspect Enterprise deployment hosted by Aspect, Aspect operates the infrastructure and its engineers hold the credentials to do so. On self-hosted, you decide, from Aspect-managed, where Aspect maintains it and your team keeps access for visibility, through co-maintained and customer-managed, to no Aspect access at all. Who operates it lays out each arrangement and what it means for incident response. Read-only is required for any shared account: Aspect doesn’t hold write credentials beside infrastructure it doesn’t manage. The roles Aspect uses are least-privilege rather than blanket admin, and every action they take lands in your AWS CloudTrail or GCP audit log. lists each role and its permissions.Identity and access
- Every web surface requires an authenticated user, including the Build Results UI. By default that’s an Aspect account, authenticated over OIDC / OAuth 2.0.
- Build endpoints authenticate every caller, separately from the web surfaces, and serve an OAuth discovery document so clients can configure themselves. See authenticating to a deployment.
- SSO through Aspect sign-in. Your identity provider connects to Aspect sign-in, so people sign in with their corporate account. Aspect sign-in still manages the accounts and issues Aspect API tokens, so CI authenticates as before.
- Your own identity provider, replacing Aspect sign-in. The deployment trusts your identity provider directly, with no Aspect accounts in between. There are no Aspect API tokens either, so read what CI has to do instead before you decide.
- SCIM provisioning, with Aspect sign-in. Syncs users from your directory into Aspect sign-in, so people who join or leave are added or removed without invites. With your own identity provider there’s nothing to sync: you manage users and groups there directly.
In transit and at rest
In transit: HTTPS/TLS on every public endpoint, TLS 1.2 or later. At rest:Network exposure
The default is authenticated public endpoints, so laptops and CI anywhere can reach the cache. Private endpoints and VPC peering are optional customizations.
See network topology.