Deploy on Azure VM

This is the simplest, most cost-effective way to deploy Sema4.ai on Azure, with infrastructure dependencies kept to a minimum. The application installs onto a single Linux VM — it brings its own Kubernetes runtime and admin console. It's suitable for small-scale production use.

Customers with stricter governance or compliance requirements can work with Sema4.ai to design a tailored architecture. Contact Sema4.ai for other installation options such as AKS or Container Apps. A reference Terraform module is available on request.

The infrastructure in the bill of materials moves at the speed of your procurement, network, IAM, and security teams — anywhere from 2 days to 2 weeks. The Sema4.ai install itself is under 90 minutes, and a POC can run the same day.

Part 1 — Pre-deployment bill of materials

Hand this to procurement and your cloud/security teams on Day 0. Some items may have lead time depending on your organization's policies.

Recommended first installation

Deploy into an existing application landing-zone subscription, in a dedicated resource group. This skips subscription procurement, and resource groups are portable — you can promote to a dedicated subscription later. Suggested naming: rg-sema4-<env>-<region> (e.g. rg-sema4-prod-weu). Use a single region, closest to your primary users; multi-region DR is a follow-on phase.

Decide these carefully — they're painful to retrofit:

Hostname — TLS, OIDC redirect URIs, and ingress all derive from it; changing it later means re-issuing certs and reconfiguring your IdP.
Region — moving regions later means a rebuild.
Private endpoints for Postgres, Blob, and Key Vault — for anything beyond a POC, plan these on day 1.

Components

Category	Component	Spec / SKU	Notes
Compute	Linux VM	4 vCPU, 16 GiB RAM, ≥100 GiB disk, Ubuntu 24.04 LTS (e.g. `Standard_D4s_v6`)	Hosts the full stack: app, agent data server, Caddy ingress
Network	DNS record	A record for the workspace, e.g. `sema4-agents.<customer>.com` → VM IP	TLS, OIDC redirect, and ingress all depend on it. Confirm you can edit DNS first
Network	TLS termination	Public IP: Let's Encrypt via Caddy on the VM (TLS-ALPN-01, no extra Azure resource). No public IP: provide your own TLS termination or a custom cert + key	Customer cert only needed for the App Gateway / Front Door alternative
Network	VNet + subnet	New or existing; `/27` minimum	NSG rules per the rows below
Network	NSG rules (inbound)	HTTPS line of sight for end users and API clients; SSH for VM management
Data	PostgreSQL	Azure DB for PostgreSQL Flexible Server, PG 17+. Low-load: `B2s` (2 vCPU, 4 GB), 100 GB. Production: `DC2ads-v6` (2 vCPU, 8 GB), 100 GB	Public network access disabled; delegated subnet or private endpoint. Allow-list the `uuid-ossp` extension via the `azure.extensions` server parameter (`plpgsql`, also required, is built in). App creates its schema on first boot and enables the extensions itself, so its database user must be able to run `CREATE EXTENSION`
Data	Blob Storage	Azure Storage Account, Standard, ZRS, one container for the deployment	Restrict network access to the VM's subnet or private endpoint. Stores agent files, uploads, exports, artifacts
Data	Key Vault + RSA KEK	Azure Key Vault (Standard), same region as the VM, with an RSA key (≥2048-bit) with `wrapKey` and `unwrapKey` operations	Envelope encryption of secrets at rest. You provide the versioned key identifier (`https://<vault>.vault.azure.net/keys/<name>/<version>`) at install
Identity	OIDC IdP app	App registration in Entra ID / Okta / Auth0 with redirect URI `https://<hostname>/oidc/login/callback`, logout URI `https://<hostname>/oidc/logout/callback`, scopes `openid profile email`, group claims if access-restricted	Discovery URL, Client ID, and Client Secret needed at install. See Identity providers (OIDC)
Identity	Managed identity	User-assigned managed identity attached to the VM	Roles: Get / WrapKey / UnwrapKey on the Key Vault KEK + Storage Blob Data Contributor on the storage account
Access	Subscription role	Suitable permissions on the resource group for the deploying admin	Just-in-time access acceptable
Access	Admin SSH access	SSH keypair for the VM admin account; admin has `sudo`	Required for install and day-2 maintenance
Egress	Outbound HTTPS	Unrestricted egress recommended. Needed to reach the Sema4.ai services (app distribution, licensing, updates), Let's Encrypt ACME, Ubuntu package mirrors, plus your LLMs and MCP servers	See the network endpoints for the Sema4.ai hosts, and Add networking rules

Alternative ingress (advanced)

The default public-IP path uses Caddy on the VM with Let's Encrypt. You can substitute Azure Application Gateway or Azure Front Door (Premium) + Private Link for a managed WAF, a non-internet-facing VM, or Key Vault certificate lifecycle.

If you need a non-default ingress, contact Sema4.ai before provisioning — we'll review the target architecture and adapt the install.

Part 2 — Deployment steps

Step 1: Pick the hostname (foundational)

Decide the public hostname (e.g. finance-agents.company.com) on a domain you control, and confirm you can create and update its DNS records. TLS, the OIDC redirect URI, and the cluster ingress all derive from it — changing it later means re-issuing certificates, updating your IdP, and reconfiguring the cluster.

Step 2: Decide network architecture

Public, internet-accessible: VM with a public IP, port 443 reachable from the internet, Caddy terminating TLS via Let's Encrypt (TLS-ALPN-01).
Non-public IP: if you require an alternative front end (Azure Firewall, App Gateway, Front Door + Private Link), see Alternative ingress and contact Sema4.ai before provisioning.

Step 3: Register the OIDC application

Register an OIDC application in your identity provider and capture the Discovery URL, Client ID, and Client Secret you'll enter at install. Use:

Redirect URI: https://<hostname>/oidc/login/callback
Logout URI: https://<hostname>/oidc/logout/callback
Scopes: openid, profile, email
Authorization code flow with PKCE where supported; restrict to the allowed group(s) if your IdP supports it.

Follow the guide for your provider: Microsoft Entra ID · Auth0 · Okta.

You can register the redirect URI before the hostname resolves, but sign-in won't complete until DNS is live (Step 5).

Step 4: Provision Azure infrastructure

Either apply the reference Terraform (infra/azure/az-virtual-machine/, available from Sema4.ai on request), or provision yourself via Bicep, ARM, the portal, or existing shared infrastructure using the bill of materials as the spec. Whichever path, the end state must include:

PostgreSQL 17+ with the uuid-ossp and plpgsql extensions available (the application must be able to enable them), reachable from the VM; capture host, port, admin credentials, and database name.
Storage account + blob container for the deployment, network-restricted to the VM's subnet or a private endpoint.
Key Vault + RSA KEK in the VM's region, with wrapKey/unwrapKey; capture the versioned key identifier.
VM matching the BOM, with the user-assigned managed identity attached and granted the listed roles.

Step 5: Configure DNS and confirm

Create the A record from Step 1 pointing to the VM's static IP, then confirm resolution:

dig +short <hostname>
# Expected: <vm-ip>

Do not proceed until dig +short <hostname> returns the VM's IP.

Step 6: Install the application

Sema4.ai ships as a Replicated KOTS application installed into an embedded single-node Kubernetes cluster on the VM.

6.1 Get the install command

Open the Sema4.ai Enterprise portal (opens in a new tab) and sign in with the email on your license (you'll get a one-time verification code).
Select your application and copy the install command for the latest release.
SSH into the VM (if using the reference Terraform, get the command from its output).
Run the install command with sudo. On smaller VMs, host preflight checks may fail — they can be skipped with --ignore-host-preflights.
When prompted, set the admin-console password and keep it safe — you'll need it for configuration changes and software updates.

6.2 Open the admin console via SSH tunnel

The admin console isn't exposed to the internet. Open an SSH tunnel forwarding localhost:8800 → admin port :30000 on the VM (the reference Terraform outputs this command):

ssh -i ~/.ssh/s4admin-privatekey.pem -L 8800:localhost:30000 s4admin@<hostname>

6.3 Configure the deployment

Browse to https://localhost:8800, accept the self-signed certificate, sign in with the admin password, accept the license, and choose Single node topology. Then fill in the config screen:

External URL containing the hostname
Service type (Networking): select Built-in TLS termination if the VM is exposed directly to the internet
Postgres host, port, admin credentials, database name
OIDC — choose OIDC Generic and enter the discovery URL, client ID, and client secret
Infrastructure platform: Microsoft Azure
Storage account name, blob container name, and optional key prefix
Key Vault KEK versioned identifier
Observability platform (Datadog supported, otherwise None)

6.4 Deploy

Click Deploy. The first deploy takes 5–15 minutes while the embedded cluster pulls images, runs migrations, and provisions the Let's Encrypt certificate.

Step 7: Validate

Browse to https://<hostname> — login should redirect to your IdP.
Sign in with a permitted user; you should land in the Sema4.ai workspace.
Run a smoke-test agent to confirm the data plane (Postgres, Blob).

Next steps

With the application running, continue to First-time setup to connect LLMs, set up MCP OAuth, and configure the rest of the workspace.

Azure AKS Identity providers (OIDC)