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.

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.