Self-host Sema4.ai
Stand up a self-hosted deployment in your own cloud account, connect your identity provider, and hand the workspace to your teams.
Audience: IT (the enabler)
Hosted or self-hosted
You can run the platform two ways:
- Hosted by Sema4.ai. We operate the infrastructure. Nothing to provision, nothing to patch.
- Self-hosted in your cloud account. The platform runs in your VPC, against your database and your object storage, under your network policy. This section covers that path.
Choose a deployment target
| Target | Best for |
|---|---|
| AWS EKS | AWS, managed Kubernetes with a prepared sandbox node. |
AWS EKS is the only supported target for this release. If you need a different platform, talk to your Sema4.ai representative.
This release is single node. The application runs on one prepared node and does not scale horizontally, so you size for peak rather than adding capacity later. It also means there is no high availability: losing the node makes the workspace unavailable until a replacement joins, though your data is unaffected. See Caveats and limits.
What you provide
A self-hosted deployment sits on infrastructure you own. There are three things you provide:
- Access. A hostname and ingress so users and API clients can reach the application, an OIDC identity provider for sign-in, and network egress so the platform can reach your models, data sources, MCP servers, and the Sema4.ai services.
- Prerequisites. A PostgreSQL database, an object storage bucket, and a KMS key for envelope encryption of secrets at rest. The database and the bucket are where your data actually lives, so treat them as the things to size, secure, and back up.
- Compute. A prepared Kubernetes cluster. This is where v3 differs most from earlier versions.
The cluster is not interchangeable with a generic one. Agent code runs in hardware-isolated sandboxes, which require nested virtualization, a Kata Containers runtime class registered with containerd, and a dedicated btrfs block device on the node. None of this can be added from inside the cluster after the node has joined. Read Cluster and node requirements before you provision anything.
The deployment flow
- Prepare prerequisites. A cloud account, your license, DNS and TLS for the application hostname, and an identity provider.
- Prepare the cluster and its node. Provision the cluster and the sandbox-capable node, and let node preparation complete. See Cluster and node requirements.
- Deploy to your target. Follow Deploy on AWS EKS.
- Connect your identity provider. Register an OIDC application and wire it into the deployment. See Identity providers (OIDC).
- Configure the workspace. Connect models, integrations, and data sources. See Administration.
What this section covers
What this article will cover
- Hosted on Sema4.ai infrastructure, and what the operating boundary is
- VPC deployment in your own cloud account
- Regions and data residency
- Sizing guidance for a first deployment
- Upgrading and patching a self-hosted deployment
- Backups and disaster recovery for the database and the bucket
- Recovering from the loss of the application node
Where state lives. Your data lives in the PostgreSQL database and the object storage bucket you provide. The application node holds no system of record: its local disk is a cache, and the workspace filesystem is materialized onto it on demand from object storage. Replacing the node costs you a cold cache, not data. See Cluster and node requirements.