Bring Your Own Cloud (BYOC)

A BYOC deployment runs entirely inside your own cloud account, on private networking with no public inbound. The shape is the same on AWS and Azure; each tab shows the concrete services. For how BYOC compares to SaaS, see Deployments.

note

The trust posture in one line: everything — application, data, identity, and inference — stays in your account; there is no public inbound; and Autoheal holds no standing credentials to your infrastructure. Operator access is granted by you and revocable at any time.

AWS (EKS)

The concrete services behind each tier:

• Networking — a VPC across three Availability Zones, private subnets only, no public inbound. Users reach it over VPN or AWS Direct Connect via a Route 53 private hosted zone (ACM certificate); ingress terminates at an internal Application Load Balancer (443); egress is outbound-only over VPC endpoints / PrivateLink where available.
• Compute — Amazon EKS with a private API endpoint; a separate Runner (EC2 Auto Scaling group) for sandboxed execution. The runner has no inbound: it connects outbound to the in-cluster Temporal frontend over an internal NLB (7233), polling for work.
• AI models & inference — in-account Amazon Bedrock (via PrivateLink) keeps inference in your account, or a direct provider you choose.
• Data — Aurora PostgreSQL, ElastiCache for Redis, Amazon S3, AWS Secrets Manager, all in your account; encrypted at rest with your KMS keys; secrets read via EKS Pod Identity / IRSA.

Azure (AKS)

The concrete services behind each tier:

• Networking — a VNet across three Availability Zones, private subnets only, no public inbound. Users reach it over VPN or ExpressRoute via an Azure Private DNS zone (Key Vault certificate); ingress terminates at an internal Application Gateway (443); egress is outbound-only over private endpoints where available.
• Compute — Azure AKS as a private cluster; a separate Runner (VM Scale Set) for sandboxed execution. The runner has no inbound: it connects outbound to the in-cluster Temporal frontend over an internal Load Balancer (7233), polling for work.
• AI models & inference — in-account Azure OpenAI / AI Foundry (via private endpoint) keeps inference in your subscription, or a direct provider you choose.
• Data — PostgreSQL Flexible Server, Azure Cache for Redis, Azure Blob Storage, Azure Key Vault, all in your subscription; encrypted at rest with customer-managed keys; secrets read via Microsoft Entra Workload Identity.

What leaves your environment

The entire platform runs in your account, so by default nothing leaves your environment. With an in-account model and in-network integrations, no data crosses your boundary at all. Data leaves only on paths you deliberately choose:

	Where it goes	Leaves your environment?
Control plane + all data at rest	Your account	No — never
LLM inference — in-account model	Your account, over a private endpoint	No
LLM inference — direct provider	The provider you choose	Only if you pick one instead of an in-account model
Integration reads — in-network tools	Inside your network	No
Integration reads — external SaaS tools	That vendor	Only for the SaaS tools you connect
Inbound — alerts and user sign-in	Into the platform, on private networking	No public inbound

The two egress paths — a direct LLM provider and reads to external SaaS integrations — are choices you make, not something Autoheal does on its own (see Data residency). Inbound is limited to your users signing in over SSO and your monitoring posting alerts to an authenticated webhook; in BYOC both ride private networking, with no public inbound.

Access and identity (SSO)

• Connect your SAML 2.0 identity provider for single sign-on (Okta, Entra ID, PingOne, OneLogin, Google Workspace, or an in-house IdP); your team signs in with existing corporate credentials. OIDC federation is not currently supported — customer SSO is SAML 2.0.
• Every request is authenticated at the gateway, and access is role-based, keyed on the user's email. Autoheal never receives passwords or MFA factors.
• Because role bindings key on email, changing a user's email in your identity provider re-keys their access — plan email changes as a re-grant, not a rename.

Data residency

• All data resides in your infrastructure — databases, cache, object storage, and secrets, all in your account and region.
• Encrypted in transit (TLS) and at rest, with your own keys (KMS or Key Vault) where policy requires.
• Nothing is replicated to another region unless you configure it. The only data that leaves is the LLM and read-only integration traffic you configure.
• Choosing an in-account model (Bedrock, Azure OpenAI / AI Foundry) keeps inference inside your account over a private endpoint. Choosing a direct provider (OpenAI, Anthropic) is a deliberate outbound egress exception you opt into — it is the one path on which prompt and context data leaves your account to a public endpoint.

Backup and restore

All durable state lives in your account's managed services, so backup and restore run under your organization's own retention and DR policy using native cloud tooling.

• PostgreSQL is the system of record — backed up with managed automated backups, point-in-time recovery, and snapshots, encrypted with your keys.
• Object storage (attachments, artifacts) uses versioning, with optional cross-region replication.
• Redis is a transient streaming and cache tier — durable events are persisted to PostgreSQL, so it needs no backup of its own.
• The application runtime is stateless and redeployed from version-pinned releases, so the running services hold no state to back up.

To recover, your platform team restores PostgreSQL to a point in time (and any object versions) from your managed-service backups; Autoheal redeploys the application to reconnect to the restored data. Because backups are encrypted with your keys, protecting those keys is what ultimately protects your data. Detailed recovery-point/recovery-time targets and DR procedures are covered during onboarding.

Deployment and upgrades

Autoheal holds no standing credentials to your infrastructure. There are two ways to run installs and upgrades, and you choose:

• You run it (recommended). Run the install and every upgrade from your own CI/CD with your own credentials. Autoheal never touches your account.
• Autoheal runs it during onboarding. You create a scoped, least-privilege IAM role (with an external ID) that Autoheal assumes only for the install window; that principal is given an EKS access entry (cluster-admin on the app's cluster) so it can create the application's Kubernetes resources, and you can delete the role afterward. The cluster-admin grant is scoped to the install window and the app's resources, not a standing operator login.

A few properties hold in both models:

• Runner hosts are SSM-managed with no inbound SSH — there is no bastion or jump box, and no open inbound path for operators.
• You control the upgrade window. Upgrades are staged under change control.
• The application layer moves independently of your cloud infrastructure, so a routine upgrade never touches your network or data services.

For how an in-flight investigation survives a runner being replaced during an upgrade or scale-in, see Durability and failure handling.