Skip to main content
This page is for teams getting an Aspect Enterprise deployment hosted by Aspect. Standing it up needs the following from you; Aspect does everything else. Runners clone your repository with the credentials your CI provider issues, as your existing runners do. The checkout sits on the runner’s disk in your deployment and goes when the runner is recycled.

​
1. A version control integration

Status checks, PR comments and inline lint findings reach your VCS through the Aspect Workflows GitHub App or GitLab App, installed on your organization. It’s the same app and install flow the Aspect CLI uses, so if you’ve already installed it for CLI features, this step is done.

GitHub App

Install the Aspect Workflows GitHub App on your organization and link it to your Aspect account.

GitLab App

Link the Aspect Workflows GitLab App to your Aspect account.
Someone with admin rights on the VCS organization installs the app. Linking it needs the Account Owner, Account Admin, or the matching GitHub Integration Admin / GitLab Integration Admin role in the Aspect settings.

​
2. A CI provider credential, if you use Workflows CI runners

Workflows registers its managed CI runners with your CI provider and polls it for queue depth to drive scaling. That needs one credential, which differs by provider. If you bring your own CI runners, on any CI system, and use only the remote cache, remote execution and Build Results UI, skip this step. Send these through the secure channel your Aspect contact provides, not over email or a shared document. They’re stored in the deployment’s secret manager and readable only by the services that need them.
These credentials scope to runner registration and queue introspection. They don’t give Aspect write access to your repositories; posting status checks and PR comments goes through the VCS app in step 1, which has its own, separately granted permissions.

​
3. An identity provider decision

Choose how developers authenticate to the Build Results UI and to the external cache and execution endpoints:
  • Aspect sign-in (standard). Aspect operates the identity provider. It can connect to your identity provider for SSO, and people still sign in to Aspect accounts. Users are invited through the Aspect settings. Without SSO there’s nothing to configure on your side. Either way, Aspect API tokens are available for CI and headless use.
  • Your own identity provider, an optional customization that replaces Aspect sign-in. The deployment authenticates against your directory directly, with no Aspect accounts. You supply the issuer URL, client ID and client secret, and register Aspect’s redirect URIs at your IdP.
With Aspect sign-in, SCIM provisioning can sync users from your directory. With your own identity provider you don’t need it: you manage users and groups there directly. Replacing Aspect sign-in changes how non-interactive clients authenticate: there’s no Aspect API token, and you supply your own credential helper for CI. Read If the deployment uses your own identity provider before deciding.

​
4. A DNS decision

Standard deployments serve their endpoints on Aspect’s domain, and Aspect issues and renews the certificates. Nothing is needed from you. If you’d rather the endpoints sat on your own domain, you delegate a subdomain to Aspect, for example aspect.example.com, and Aspect issues and renews certificates inside it. That’s a one-time DNS change.

​
What you get back

When the deployment is up, Aspect gives you:
  • The deployment host, for example remote.<your-deployment>.aspect.build. This is the one string developers need: aspect auth configure discovers the cache, build event and remote execution endpoints from it.
  • The Build Results UI URL, on the same domain as the host, under app..
  • The runner group names your CI jobs target. See Targeting runner groups from CI.
  • The remote execution platform properties your Bazel exec platforms must advertise. See Targeting remote execution worker pools.
From there, see local setup and CI setup.