Manage BYOC Cloud Accounts¶

View and manage your customers' BYOC Cloud Accounts for BYOC deployments.

What is BYOC?¶

BYOC (Bring Your Own Cloud) is a deployment model where your customers' applications are deployed and managed within their own cloud accounts rather than in your infrastructure. This approach addresses critical customer requirements around data sovereignty, security compliance, and cost control while still providing a fully-managed SaaS experience.

BYOC Operations¶

Self-served BYOC Setup¶

The Customer Portal can be used by customers to connect and manage their BYOC cloud accounts.

Setup Customer Accounts on behalf of customer¶

You can also work with your customer to perform an assisted setup of their Cloud Account.

Responsibility model¶

In a BYOC deployment, responsibilities are split across three parties:

• Customer account owner: Runs the onboarding flow in the target account, approves IAM and identity setup, and owns cloud quotas, organization policies, and network constraints in that account.
• SaaS provider: Enables BYOC for the service, guides or assists the customer through onboarding, and operates the resulting instances through Omnistrate.
• Omnistrate: Provides the onboarding artifacts, bootstraps the deployment cell, installs platform components, and orchestrates lifecycle operations in the connected account.

Lifecycle of a BYOC account¶

For most BYOC services, the lifecycle looks like this:

1. The customer connects their cloud account from the Customer Portal or through an assisted flow.
2. The first instance in a given account and region bootstraps the deployment cell for that location.
3. Later instances in the same account and region typically reuse that deployment cell instead of creating a new cluster every time.
4. The account can only be offboarded after all instances in that account are deleted.

For more background on deployment cells, see Deployment Cells.

Self-serve vs assisted onboarding¶

Both patterns are supported:

• Self-serve: The customer runs the onboarding flow directly from the Customer Portal.
• Assisted: Your team coordinates with the customer and helps execute the onboarding steps in their cloud account.

The underlying Omnistrate bootstrap flow is the same in both cases. The main difference is who drives the cloud-console or Cloud Shell steps.

CTL workflow for BYOA cloud accounts¶

If you prefer to onboard customer accounts from the CLI, use the provider-specific getting-started guides:

• AWS account onboarding with CTL
• GCP account onboarding with CTL
• Azure account onboarding with CTL
• Nebius account onboarding with CTL

The common BYOA lifecycle commands are:

# Create a customer onboarding instance
omnistrate-ctl account customer create [provider flags] --service <service> --environment <environment> --plan <byoa-plan>

# List and inspect customer onboarding instances
omnistrate-ctl account customer list [flags]
omnistrate-ctl account customer describe <customer-account-instance-id>

# Update or delete a customer onboarding instance
omnistrate-ctl account customer update <customer-account-instance-id> [flags]
omnistrate-ctl account customer delete <customer-account-instance-id>

# Create a BYOA deployment with that onboarding instance
omnistrate-ctl instance create ... --customer-account-id <customer-account-instance-id>

In production environments, account customer create defaults to the calling user's subscription unless you explicitly pass --subscription-id or --customer-email.

Retrying onboarding safely¶

When onboarding fails partway through, or when bootstrap resources are deleted manually later, avoid trying to stitch old and new bootstrap state together.

Recommended approach:

• Re-run the current onboarding flow for the exact target account and cloud provider.
• If the connected account was partially onboarded and then manually modified, disconnect or offboard it and onboard again cleanly.
• For GCP, treat deleted-and-recreated projects, removed workload identity pools/providers, or mismatched onboarding kits as fresh onboarding events.
• Do not assume a previous bootstrap in another region, another environment, or another cloud account can be reused automatically.

BYOC PrivateLink Accounts¶

BYOC PrivateLink is selected at account-onboarding time (Customer Portal toggle, or --private-link on omnistrate-ctl account customer create). Once enabled, every instance in the account uses the PrivateLink dataplane topology.

Omnistrate-managed VPC¶

The simplest topology: Omnistrate provisions the VPC, subnets, NAT gateway, security group, and the management VPC Endpoint inside the customer's account on first deployment. The customer only grants the bootstrap role via CloudFormation — no manual VPC or VPCE setup is required.

To allow this path, the account must be onboarded with the Allow new cloud-native network creation option enabled. This grants Omnistrate permission to create new VPCs in the account on demand; without it, every deployment must reuse an existing customer-supplied VPC.

• Customer Portal: enable Allow new cloud-native network creation on the AWS account form.

• omnistrate-ctl: pass --allow-create-new-cloud-native-network on account customer create:

  omnistrate-ctl account customer create \
    --service=<service> \
    --environment=<environment> \
    --plan=<plan> \
    --customer-email=<customer@example.com> \
    --aws-account-id=<AWS_ACCOUNT_ID> \
    --private-link \
    --allow-create-new-cloud-native-network
  

When this option is set, the first instance in each region triggers Omnistrate to create the deployment cell's VPC, subnets, NAT gateway, security group, and management VPCE. Later instances in the same region reuse the same network.

Imported VPC requirements for BYOC PrivateLink¶

Customers typically bring their own VPC when they need to comply with internal network governance — for example, reusing an existing CIDR plan that fits Transit Gateway / Direct Connect routing, attaching the dataplane to a pre-approved security-group and firewall posture, sharing a NAT gateway or egress proxy with other workloads, or operating under a policy that prohibits the SaaS provider from creating new VPCs in their account.

When the customer brings their own VPC for a PrivateLink account, the VPC must satisfy the following before any instance is deployed:

Account Offboarding¶

When a customer no longer needs your SaaS Product or wants to disconnect their cloud account, you can offboard their BYOC account. This removes all Omnistrate-managed resources from the customer's cloud account and severs the trust relationship.

Prerequisites¶

Before a BYOC account can be offboarded:

1. The customer must delete all deployment instances running in their cloud account. Active instances must be terminated before the account can be offboarded.

Offboarding Steps¶

Offboarding from the Customer Portal¶

Customers offboard their BYOC account directly from the Customer Portal:

1. Navigate to your cloud account settings in the Customer Portal.
2. Delete the cloud account configuration.
3. Confirm the offboarding operation.
4. Wait for Omnistrate to automatically remove all managed resources from your account.

What offboarding cleans up¶

When you offboard a customer's BYOC account, Omnistrate removes the following resources from the customer's cloud:

• Control plane agents and system nodes
• Monitoring infrastructure
• Networking resources (VPCs, subnets, and security groups created by Omnistrate) — only if you are not using a Bring Your Own Network deployment model
• Deployment cells and their underlying Kubernetes clusters

Customer-side cleanup¶

After the offboarding process completes, the customer should remove the onboarding permissions from their cloud account. For cloud-specific cleanup steps, see Offboarding.