Skip to content

Deployment walkthrough

This topic describes what is being deployed, the decisions to make before starting, and the order of the work. Each step links to the topic that covers it in detail.

For the conceptual picture — components, network endpoints, identity, certificates — see Domino Workspace Architecture.

What you are deploying

A Domino Workspace deployment has three layers:

  1. A Kubernetes cluster and supporting infrastructure — the cluster itself plus APISIX (gateway, load balancing, TLS), cert-manager, storage, and — optionally — the observability stack (kube-prometheus-stack, Loki, Alloy) and Linkerd. These are not Domino Workspace charts; see the infrastructure topics.
  2. HCL Domino — deployed by the Domino Helm chart as a set of StatefulSets, one per server role (admin, mail, files, and so on). Domino is the identity provider and LDAP directory for everything above it, so it is always deployed first. See Domino server topology for what gets deployed and how it is sized.
  3. Domino Workspace components — Homepage, Navbar, Huddo Boards, Chat and Meetings, Forms, DX Search, Collabora, ClamAV. Which of these you deploy depends on your edition and licensed capabilities. Each has its own chart topic, listed on the Helm overview page.

Decisions to make first

Decision Notes
Deployment domain A single base domain (for example workspace.example.com); every service is a subdomain of it. Set once as domain in the Domino values file and reused by the other charts.
High availability Whether to run across two (or three) Availability Zones with paired servers, or a single-zone deployment. This changes the server topology — see High availability. Decide before deploying Domino; converting later means adding servers and rebalancing users.
Which applications Deploy only the charts for capabilities you are licensed for. Homepage, Boards, Chat and Meetings, Forms, and Search authenticate against Domino; Navbar and Collabora are standalone.
Sizing Number and size of Domino servers, and the size of the PostgreSQL / MongoDB deployments, scale with user count. See Scaling and adding capacity and System Requirements.
External services PostgreSQL, MongoDB, and a mail gateway are provided by you, not by these charts. See Helm deployment order.

Order of work

1. Provision infrastructure

Stand up the Kubernetes cluster and the supporting components. Start with the prerequisites, then follow the infrastructure deployment order: RKE2 (or another distribution), storage and a load balancer, cert-manager, APISIX, and — optionally — the observability stack (kube-prometheus-stack, Loki, Alloy) and a service mesh (Linkerd).

APISIX also needs the custom dom-router plugin before Domino is deployed — see the Domino chart prerequisites.

2. Provision external services

Make PostgreSQL, MongoDB, and the mail gateway reachable from the cluster. Minimum versions and which component needs which are listed in Helm deployment order.

3. Deploy ClamAV (if antivirus scanning is used)

HCL Domino and Chat and Meetings both connect directly to a ClamAV service for attachment scanning. Domino's One-Touch Setup is not blocked by its absence.

4. Deploy HCL Domino

Deploy the Domino chart and wait for the admin server to finish its One-Touch Setup. This is a hard prerequisite for every application in the next step. Review Domino server topology first to choose the server set and sizing for your deployment.

5. Deploy the applications

Once Domino's admin server is up, deploy the application charts you need, in any order. Dependencies between them (and on MongoDB, PostgreSQL, ClamAV) are in Helm deployment order.

After deployment

  • Verify — each chart topic has a "Verify" section. The deployment is healthy once all pods are Running with all containers ready.
  • Monitor — if you deployed the observability stack, the Domino Grafana dashboards ship with the chart (grafana.dashboards.enabled) and are picked up automatically.
  • Scale — add server capacity as user count grows; see Scaling and adding capacity.