Helm Deployment

Deploy DATAMIMIC 4.0.0 with one public hostname and one saved values.yaml. Choose HTTPS at the ingress, HTTPS at an upstream proxy, or HTTP below. Use the exact chart and matching application version from your release notification.

1. Before you start

You need:

• Kubernetes access, Helm, an ingress controller, and a target namespace.
• Registry credentials and access to the container images. Offline clusters need the images available in their registry or node cache; a chart archive alone is not enough.
• A DNS hostname pointing to your ingress or upstream proxy.
• For HTTPS: a certificate trusted by client browsers. An internal CA works in air-gapped environments; cert-manager is optional if you supply the certificate yourself.
• The supported chart archive or its exact Harbor OCI version.

2. What the chart deploys

The chart deploys the backend (including the Web UI), celeryworker, scheduler, task-monitor, PostgreSQL, MinIO, Redis, and RabbitMQ. The release pipeline sets matching application image tags; normally you do not override them.

Each bundled dependency can be disabled with <component>.install: false when you supply its external connection configuration.

3. Create the image pull secret

Create the namespace and registry Secret once, before installation:

kubectl create namespace <namespace>
kubectl create secret docker-registry rdd-harbor-registry-secret \
  --docker-server=harbor.rapiddweller.com \
  --docker-username=<username> \
  --docker-password=<password> \
  -n <namespace>

Skip namespace creation if it already exists. The default Secret name covers both application and bundled dependency images. If you use another name, set both global.applicationImagePullSecrets and global.imagePullSecrets to [{name: <your-secret-name>}].

helm registry login authenticates the Helm CLI when downloading a chart. It does not create the image pull Secret used by Kubernetes.

4. Supply the application secrets

Both application keys are required. Generate them once and save them in your secret store:

export DM_SECRET_KEY="$(openssl rand -base64 32)"
export DM_PROJECT_TOKEN_SECRET="$(openssl rand -base64 32)"

Create a Kubernetes Secret named datamimic-application in the deployment namespace through your normal secret-management process, with these keys:

Secret key	Value
DM_SECRET_KEY	The saved encryption/pseudonymization key
DM_PROJECT_TOKEN_SECRET	The saved project-token signing key
DM_FIRST_ADMIN_PASSWORD	Your initial administrator password

For a manual installation, create it once with the saved keys and your administrator password:

kubectl create secret generic datamimic-application -n <namespace> \
  --from-literal=DM_SECRET_KEY="$DM_SECRET_KEY" \
  --from-literal=DM_PROJECT_TOKEN_SECRET="$DM_PROJECT_TOKEN_SECRET" \
  --from-literal=DM_FIRST_ADMIN_PASSWORD='<your-admin-password>'

The examples below reference this Secret through global.password_secret. Keep the same keys on upgrades: changing the encryption key can make saved Git credentials unreadable; changing the token-signing key invalidates existing project tokens. Browser sessions use server-side session IDs.

5. Choose the public access mode

The scheme describes the URL in the user's browser, regardless of where TLS terminates.

Access mode	global.api_scheme	Ingress TLS
HTTPS at the ingress	https (default)	Certificate Secret
HTTPS at an upstream proxy	https	Empty if proxy-to-ingress traffic is HTTP
HTTP from browser to ingress	http	Empty

HTTPS at the ingress

Save this as values.yaml. Change the hostname once; YAML aliases reuse it for routing and TLS. Set your administrator email and ingress class.

global:
  api_host: &platform-host datamimic.int.customernet.com
  api_scheme: https
  password_secret: datamimic-application
  first_admin: [email protected]
backend:
  ingress:
    enabled: true
    class: nginx
    hosts:
      - host: *platform-host
        paths: ["/"]
    tls:
      - secretName: datamimic-tls
        hosts: [*platform-host]

Create datamimic-tls in the same namespace using your certificate and private key:

kubectl create secret tls datamimic-tls \
  --cert=<certificate-chain.pem> --key=<private-key.pem> -n <namespace>

Alternatively, have your configured certificate controller issue that Secret. The / Prefix route covers the UI, /api, WebSockets, and OAuth discovery; a separate /api route is unnecessary.

HTTP without TLS

Use this values.yaml instead:

global:
  api_host: &platform-host datamimic.int.customernet.com
  api_scheme: http
  password_secret: datamimic-application
  first_admin: [email protected]
backend:
  ingress:
    enabled: true
    class: nginx
    annotations:
      nginx.ingress.kubernetes.io/ssl-redirect: "false"
      nginx.ingress.kubernetes.io/force-ssl-redirect: "false"
    hosts:
      - host: *platform-host
        paths: ["/"]
    tls: []

These redirect annotations are for ingress-nginx. For other controllers, disable their HTTP-to-HTTPS redirect using the controller's equivalent settings.

HTTP sends credentials and session traffic without transport encryption. Use it only on a network where this is acceptable. Clipboard buttons may be unavailable on HTTP; select and copy text manually where offered. Air-gapped deployments can still use HTTPS with an internal CA.

Browser login, sessions, and the REST API work over HTTP. MCP with a project access token works only with clients that permit remote HTTP endpoints. DATAMIMIC IDE integrations require OAuth and therefore HTTPS. Kiro also rejects non-local remote HTTP MCP URLs regardless of authentication.

HTTPS at an upstream proxy

Start with the HTTP example, but set global.api_scheme: https. Keep tls: [] only when the proxy forwards HTTP to the ingress. The proxy owns the certificate and public HTTPS redirect, preserves the public host, and forwards the original scheme. Configure forwarding-header trust as described in step 8.

If the proxy also uses TLS to the ingress, use the HTTPS ingress configuration and a certificate trusted by that proxy.

api_host and api_scheme derive the public URL, CORS origin, and post-install links. The backend uses the public URL for login Origin checks and the session cookie's Secure flag. Keep UI and API on the same public origin, without a URL path or trailing slash. Setting api_scheme alone does not configure certificates or redirects.

6. Install or upgrade the chart

Use the same saved values and application Secret for installation and upgrades. Replace only the chart archive or pinned version when upgrading.

Downloaded archive:

helm upgrade --install <release-name> <chart-archive>.tgz \
  -n <namespace> -f values.yaml --wait --timeout 10m

Harbor OCI registry:

helm registry login harbor.rapiddweller.com --username <username>
helm upgrade --install <release-name> \
  oci://harbor.rapiddweller.com/datamimic/helm-datamimic \
  --version <chart-version> -n <namespace> -f values.yaml --wait --timeout 10m

Before deploying, inspect the exact chart with your values:

helm show values <chart-archive>.tgz
helm template <release-name> <chart-archive>.tgz -n <namespace> -f values.yaml

For OCI, use the same reference and --version as the install command. Confirm that the backend ConfigMap has the intended public URL and CORS origin, and that an Ingress is rendered with the correct host and TLS mode. Treat rendered output as sensitive because it can contain Secret resources.

After deployment:

kubectl get pods,ingress -n <namespace>

Pods must be ready. For ImagePullBackOff, check the pull Secret and registry access. For Pending, check storage and scheduling. For crash loops, inspect the pod events and application logs. A Helm timeout does not roll back automatically; inspect the release before retrying.

Review the ingress settings below before exposing the installation, then verify login and logout in step 10.

7. Keep the application ingress stateless

DATAMIMIC stores shared server state in Redis. Every backend replica must therefore accept the next browser, WebSocket, or MCP request after a reconnect. Do not configure ingress affinity or sticky-session cookies.

The backend owns its host-only, HttpOnly browser-session cookie and expires it through its logout endpoint. Keep the main application ingress free of:

• cookie domain or path rewrites;
• Lua or configuration snippets that rewrite Set-Cookie;
• proxy-hide-header or header filters that suppress Set-Cookie;
• affinity and session-cookie annotations.

These ingress features create a second cookie owner and make logout behavior depend on the selected replica.

The proxy must pass every upstream response header independently, including multiple Set-Cookie headers. ingress-nginx does this by default; do not collapse them into one comma-separated header.

8. Trust forwarding headers once

If another L7 proxy or load balancer sits in front of ingress-nginx, configure forwarding-header trust once in the ingress-nginx controller ConfigMap:

data:
  use-forwarded-headers: "true"
  proxy-real-ip-cidr: "<trusted-proxy-cidr>[,<trusted-proxy-cidr>]"

Set proxy-real-ip-cidr to the actual CIDRs of the trusted upstream proxies. Do not trust arbitrary client networks. Do not add either setting as an application Ingress annotation.

9. Exclude Platform authentication endpoints from external Ingress authentication

If optional external authentication is enabled for other application paths, keep these Platform-owned endpoint groups outside auth-url and auth-signin handling:

• /.well-known/*
• /api/v2/session/*
• /api/v2/oauth/*

Use separate Ingress resources or equivalent controller routing when path-specific policy is required. These endpoints perform DATAMIMIC session or OAuth authentication themselves; an external redirect or rewritten authentication header breaks browser logout and OAuth discovery.

10. Verify login and logout through the public URL

First open the public URL in a browser: the login page must render, sign-in must succeed, and reloading must preserve the session. Then verify the server session flow with a temporary cookie jar. Replace the URL and credentials; use http:// for HTTP deployments:

PLATFORM_URL="https://datamimic.int.customernet.com"
COOKIE_JAR="$(mktemp)"
trap 'rm -f "$COOKIE_JAR"' EXIT

curl --fail-with-body --silent --show-error \
  --cookie-jar "$COOKIE_JAR" \
  --header "Origin: $PLATFORM_URL" \
  --data-urlencode "username=<email>" \
  --data-urlencode "password=<password>" \
  "$PLATFORM_URL/api/v2/session/login"

curl --fail-with-body --silent --show-error \
  --cookie "$COOKIE_JAR" \
  "$PLATFORM_URL/api/v2/me"

curl --fail-with-body --silent --show-error \
  --request POST \
  --cookie "$COOKIE_JAR" \
  --cookie-jar "$COOKIE_JAR" \
  --header "Origin: $PLATFORM_URL" \
  "$PLATFORM_URL/api/v2/session/logout"

STATUS="$(curl --silent --output /dev/null --write-out '%{http_code}' \
  --cookie "$COOKIE_JAR" \
  "$PLATFORM_URL/api/v2/me")"
test "$STATUS" = "401"

Login and logout return 204; the authenticated /api/v2/me call succeeds before logout, and the final call must return 401. For HTTPS, also verify OAuth discovery from a project MCP URL. For HTTP, verify the project MCP URL with a project access token only through a client that permits remote HTTP; this does not verify an IDE integration. With more than one backend replica, verify a reconnect served without affinity.

If login fails, compare the actual browser origin with the rendered public URL and check for unexpected HTTPS redirects.