Self-hosted Aspect Enterprise

A self-hosted Aspect Enterprise deployment runs Aspect Workflows in your own AWS account or GCP project, provisioned by Terraform. It has the isolated infrastructure of a deployment hosted by Aspect, and source code, secrets and build artifacts stay in your account, under your retention policy. Self-hosted is also the only option for air-gapped networks and GovCloud. The standard deployment (Aspect-managed, an isolated account, Aspect sign-in, endpoints on Aspect’s domain) is the fastest to stand up and needs the least from your infrastructure team. Every customization below is supported for organizations that require it for security, compliance or data privacy, and usually takes more coordination with your infrastructure team.

The deployment guides, Terraform reference and infrastructure configuration pages are available to Workflows subscribers.

Cloud and region

Choice	Notes
AWS	Full support for CI runners, the cache, remote execution and the Build Results UI. macOS remote execution workers can run on EC2 Mac hosts, or on Macs you provide.
GCP	Full support for CI runners, the cache, remote execution and the Build Results UI. macOS remote execution workers run on Macs you provide. Some configuration lives in Helm chart values rather than Terraform.
Government cloud	Supported on AWS GovCloud and GCP Assured Workloads. Constrains who may work inside the environment and how releases reach it.
Air-gapped	Supported. No egress from the deployment.
On-prem Coming soon	A separate Aspect Enterprise deployment type, installed with a Helm chart on your own hardware. Join the early access list.
Azure Planned	Contact us if you’re interested.
Oracle Cloud Planned	Contact us if you’re interested.

Who operates it

This choice most affects how the two organizations work together, so make it explicitly. The deployment is in your account either way; the choice is who holds write credentials and who performs maintenance.

Arrangement	Maintains and upgrades	Aspect’s access	Aspect’s role
Aspect-managed	Aspect	Full write; your team keeps access for visibility	Operates and maintains it; your team can help
Co-maintained	Shared, under an agreed responsibility matrix	Full write, alongside yours	Looks after its components; brings you in for yours
Customer-managed, operational access	You	Limited write	Handles operations; you handle maintenance
Customer-managed, read-only	You	Read-only	Diagnoses and directs; you act
No Aspect access	You	None	Advisory

In an account shared with your other workloads, Aspect’s access is read-only at most: Aspect doesn’t hold write credentials beside infrastructure it doesn’t manage. More access is faster to support, because the alternative is a human relay between the diagnosis and the fix.

Network topology

Option	What it is	When you need it
Authenticated public endpoints	Cache, build events and remote execution reachable over the internet, JWT-authenticated. Turned on with the external endpoint	Laptops, and CI outside the VPC
In-VPC only	No public endpoint at all	Everything that builds is already inside the VPC
Private endpoints	AWS PrivateLink or GCP Private Service Connect from your VPCs to the deployment	CI runners you operate yourself, or workstations that may not egress
Your VPN	The deployment’s endpoints reached over your own site-to-site or client VPN	Workstations and CI that reach internal services only through your corporate network
VPC peering	Bidirectional route exchange with your VPCs	Only when actions running inside the deployment must reach private services on your side, such as an internal registry, mirror, SCM or test database

Private endpoints are one-directional and need no CIDR coordination. Peering is bidirectional, needs non-overlapping CIDRs and firewall rules on both sides, and puts the deployment inside the blast radius of your network changes. Where a reverse private endpoint would do, prefer it.

Identity

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 managed in the Aspect admin portal, and API tokens are available for CI and headless use.
Your own identity provider, replacing Aspect sign-in. The deployment authenticates against your directory directly, with no Aspect accounts.

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. Bringing your own identity provider removes the Aspect API token route for non-interactive clients. See what CI does instead.

Composition

Full platform: CI runners, cache, remote execution, Build Results UI.
Cache, remote execution and Build Results UI: no CI runners, for teams that already run their own CI.
Remote execution only: remote execution and cache, no CI runner fleet and no Build Results UI.

To upgrade without downtime, see .

Storage and hardware

Option	Notes
Cache storage engine	The `aspect-remote` engine (6.0+, the template default on both clouds) keeps cache storage in object storage: S3 Express One Zone by default on AWS, Cloud Storage on GCP. GovCloud uses the NVMe-sharded `buildbarn` engine. See .
Single-AZ	Keeps the entire high-data path in one availability zone, removing cross-AZ transfer cost.
Custom machine images	Build your own runner images with Packer. See .
Remote execution workers on your own hardware	Machines you run yourself join the deployment’s fleet as remote execution workers, for any worker type.

​Cloud and region

​Who operates it

​Network topology

​Identity

​Composition

​Storage and hardware

​Where to go next

Cloud and region

Who operates it

Network topology

Identity

Composition

Storage and hardware

Where to go next