> ## Documentation Index
> Fetch the complete documentation index at: https://openworklabs.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Deploy to your cloud

> Run OpenWork in your AWS, Azure, or Google Cloud account with Kubernetes, Helm, and managed MySQL.

OpenWork's supported private-cloud shape uses the published Helm chart, a managed Kubernetes cluster, and a MySQL-compatible database in your own account. You control the network, DNS, certificates, database, backups, identity provider, and secrets; the chart deploys Den web, Den API, migrations, and the optional inference service.

<CardGroup cols={3}>
  <Card title="AWS" icon="cloud" href="/docs/self-host/deploy-to-your-cloud/aws">
    Deploy on EKS with Amazon RDS for MySQL.
  </Card>

  <Card title="Azure" icon="cloud" href="/docs/self-host/deploy-to-your-cloud/azure">
    Deploy on AKS with Azure Database for MySQL.
  </Card>

  <Card title="Google Cloud" icon="cloud" href="/docs/self-host/deploy-to-your-cloud/google-cloud">
    Deploy on GKE with Cloud SQL for MySQL.
  </Card>
</CardGroup>

## Common architecture

Every provider guide uses the same OpenWork boundaries:

* Den web listens on port `3005` and serves the browser experience.
* Den API listens on port `8788` and owns authentication, organizations, policy, and control-plane APIs.
* A MySQL 8-compatible database stores shared control-plane state.
* A migration Job runs before the application rollout.
* The inference service is optional and disabled by default.
* HTTPS hostnames expose web and API traffic through the provider's load-balancing layer.

Use private database networking in production. Require TLS for public application traffic, encrypt storage and backups, and keep database and authentication secrets in the provider secret store or a Kubernetes Secret—not in a Helm values file.

## Deployment sequence

1. Create the Kubernetes cluster and private MySQL database in compatible networks.
2. Reserve the public address or load-balancer entry point.
3. Create the database, database user, and Kubernetes namespace.
4. Generate independent database, Better Auth, and Den encryption secrets.
5. Prepare provider-specific Helm values for the web and API hostnames.
6. Install or upgrade the chart and wait for the migration Job and workloads.
7. Point DNS at the load balancer and verify trusted HTTPS.
8. [Create the first administrator](/docs/self-host/deploy-to-your-cloud/first-administrator).
9. Configure SAML or OIDC SSO and invite or provision members.

## Before you start

You need:

* a cloud account with permission to create Kubernetes, networking, load-balancing, managed MySQL, DNS, certificates, and secrets;
* `kubectl` and Helm, plus the provider CLI and Kubernetes authentication plugin;
* two DNS names, normally one for Den web and one for Den API;
* a real email address for the initial owner;
* a backup, restore, upgrade, and rollback plan.

<Note>
  The provider pages give the supported architecture and point to the repository's detailed operator runbooks for exact commands. Pin a chart version in production and use the runbook from the matching release or branch.
</Note>

## After deployment

Use [Private network deployment](/docs/start-here/private-network-deployment) when Den is reachable only through a VPN or private network. Review [Outbound network access](/docs/start-here/outbound-network-access), [Certificate trust and proxies](/docs/start-here/certificate-trust-and-proxies), and [Air-gapped deployment](/docs/start-here/air-gapped-deployment) before restricting egress.