> ## Documentation Index > Fetch the complete documentation index at: https://site.aspect.build/llms.txt > Use this file to discover all available pages before exploring further. # Self-hosted Aspect Enterprise > Self-hosted Aspect Enterprise runs Aspect Workflows in your own AWS account or GCP project: isolated infrastructure, with your data in your own account. Cloud, operating model, network topology, identity and hardware options. export const gatedAccess = (user, group) => { const loggedIn = !!(user && user.loggedIn); const groups = user && user.tenantMetadata && user.tenantMetadata.docsGroups || []; if (loggedIn && (!group || groups.indexOf(group) >= 0)) { return "entitled"; } return loggedIn ? "signed-in" : "anonymous"; }; export const GatedLink = ({access, href, group, children}) => { const note = group ? "Aspect Enterprise customers" : "free Aspect account"; const muted = { fontSize: "0.85em", opacity: 0.7, whiteSpace: "nowrap" }; if (access === "entitled") { return {children}; } if (access !== "signed-in") { return {children} (sign in: {note}) ; } return {children} ({note}) ; }; 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](/docs/aspect-workflows/enterprise/hosted/overview), 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. {" "} {!user.loggedIn && Log in} {user.loggedIn && user.tenantMetadata?.docsGroups?.includes('workflows-subscriber') && You have access to them in the navigation.} {user.loggedIn && !user.tenantMetadata?.docsGroups?.includes('workflows-subscriber') && If your organization is a customer, contact Aspect support for access.} ## 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](/contact?topic=on-prem). | | **Azure** Planned | [Contact us](/contact) if you're interested. | | **Oracle Cloud** Planned | [Contact us](/contact) 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](/docs/aspect-workflows/enterprise/connect/local-setup#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](/docs/aspect-workflows/enterprise/connect/ci-setup#if-the-deployment-uses-your-own-identity-provider). ## 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 blue/green deployments. ## 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 remote cache configuration. | | **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 custom machine images. | | **Remote execution workers on your own hardware** | Machines you run yourself join the deployment's fleet as remote execution workers, for any worker type. | ## Where to go next {user.loggedIn && user.tenantMetadata?.docsGroups?.includes('workflows-subscriber') ? ( What must exist in the account before the first apply. Deploy on AWS or GCP. Authenticate clients and point builds at the deployment. Release notes and upgrade guides. ) : ( Authenticate clients and point builds at the deployment. Plan a self-hosted deployment, or ask about a 30-day trial of Aspect Enterprise. )}