Bring Your Own Cloud setup

Under Bring Your Own Cloud (BYOC), Akka provisions and operates a region inside your own cloud account. You prepare the account with the akka-bootstrap utility and grant Akka a deployment identity; Akka then provisions the region, runs smoke tests, and hands it over.

This page lists the cloud-agnostic setup. For your cloud’s resource inventory, private connectivity, and values.hcl specifics, follow the per-cloud page: AWS, Azure, or GCP.

Download the full BYOC setup as a PDF, or the full overview.

Installation flow

  1. Understand: review the technical overview and receive the akka-bootstrap utility from your Akka Success Team, so you can inspect exactly which permissions Akka’s deployment identity will require.

  2. Request a region: submit a region request through the form in the Akka customer portal.

  3. Cloud account: create a cloud account for Akka. Not strictly required, but a dedicated account simplifies cost management.

  4. Apply permissions: run akka-bootstrap to configure the account, then attach the generated deployment-identity details to your region request.

  5. Provision: Akka remotely provisions the region and attaches it to a platform organization created for you.

  6. DNS: create record sets in your DNS zone that map to the region’s load-balancer IP.

  7. Smoke tests: Akka attaches the region to the Federation Plane and runs smoke tests.

  8. Region handover: register a user at akka.io with a corporate email; Akka makes them your organization’s primary owner. A production-labeled region is not fully handed over until you complete the region-readiness steps.

The akka-bootstrap utility

akka-bootstrap prepares your cloud account for AAO by creating the Deployment Identity role the Federation Plane uses to create and manage infrastructure. It creates and manages the Deployment Identity operations role only. You create the Editor, Viewer, and SRE identities.

It is a Terragrunt project with a per-cloud module layout:

.
├── main.tftpl        # generates provider config + module calls
├── modules
│   ├── aws/          # IAM roles, trust policy
│   ├── azure/        # app registration, service principal, roles
│   └── google/       # service account, IAM bindings
├── README.md
└── terragrunt.hcl    # orchestration: reads values.hcl

You create a values.hcl with your backend configuration and the region details for your cloud (the exact block differs per cloud; see the per-cloud page), then run the Terragrunt lifecycle:

terragrunt init     # initialize and validate the generated Terraform
terragrunt plan     # review the planned changes
terragrunt apply    # provision the identity, roles, and credentials

After a successful apply, share the generated deployment-identity details with Akka: the role ARN to assume on AWS, the service-principal credentials on Azure, or the service-account identity to impersonate on GCP.

The utility is the source of truth for the exact permissions Akka’s deployment identity requires. Review its generated output rather than a hand-maintained list, so the permissions you grant always match what Akka runs.

Identity model

AAO uses four roles across all clouds:

Role Responsibilities Who creates it

Deployment

Creation and management of infrastructure

akka-bootstrap

Editor

Management of infrastructure without delete permissions

You

Viewer

Read-only permissions for infrastructure

You

SRE

Identical to the Deployment role, for emergency response or upkeep

You

Within Kubernetes, Akka uses least-privilege access scoped to the Akka-managed namespaces and limits its access to customer-owned Kubernetes resources.

Choose your cloud

Continue with your cloud for its specifics:

  • BYOC on AWS: VPC and subnets, the IAM identity model, private connectivity, and the AWS values.hcl.

  • BYOC on Azure: virtual network, the Microsoft Entra ID identity model, resource providers, private connectivity, and the Azure values.hcl.

  • BYOC on GCP: VPC, the service-account identity model, private connectivity, and the GCP values.hcl.