Advanced Deployment Guide

A guide to advanced deployment methods for MOTAR

Recommended for Scalable Activation Across Organization

This guide is for production deployments only. If you are looking to evaluate MOTAR locally, refer to the MOTARQuickStart / Docker deployment guide instead. The Docker configuration is not suitable for production use — deploying it in a live environment may result in broken service connectivity and degraded performance.

Helm Chart Installation

Helm Chart for Kubernetes

This cloud or local installation method is considered an advanced install option.

You can install MOTAR in a high availability fashion and optionally configure MOTAR components for advanced deployments (production, multi-node Kubernetes cluster deployments).

You will access the MOTAR Helm installation package through Dynepic's Helm Repository.

This Helm chart installs MOTAR with all of its dependencies in a Kubernetes cluster. Our Helm chart also employs non-MOTAR supporting charts, such as:

A custom Minio chart branched from the Minio public chart.
The Bitnami PostgreSQL chart.
The ingress-nginx Kubernetes chart.
The NATS public chart.

Prerequisites

[ ] Kubernetes 1.23+
[ ] Helm 3.8.0+
[ ] PV provisioner support in the underlying infrastructure
[ ] ReadWriteMany volumes for deployment scaling

Don't have a Kubernetes cluster yet? If you are deploying on a single server or EC2 instance and need a simple path to get MOTAR running, see Single-Node Setup with MicroK8s (Development / Evaluation).

Note that a single-node MicroK8s instance is not highly available or horizontally scalable and is not recommended for large or mission-critical deployments.

For true production environments, consider a managed Kubernetes service such as AWS EKS, GKE, or AKS.

The MOTAR Helm chart supports deployments in Kubernetes clusters hosted in nearly any cloud provider, local server, and self-hosted cloud. As such, many of the values are left to be filled in by the installing individual.

The default values.yaml should provide information sufficient to help you prepare the installation for your circumstance. If you find anything confusing or not intuitive, please reach out via Contact Us!

Below we will provide some general recommended values, and then some recommended values based on deployment type. You will be providing the values to the deployment which overrides the default where the values are set.

If MOTAR is already installed, proceed to the Upgrading MOTAR with Helm section below.

If using the Dynepic-provided Helm chart and images, you will need to authenticate with the Dynepic registry to pull the Helm chart, and provide a Secret in the cluster which contains the dockerconfigjson to pull the images. See the imagePullSecret section below.

Step 1 — Configuration

Create a values file in a known directory (replace your_directory with your actual path):

touch /your_directory/your_value.yaml

Edit the values file:

nano /your_directory/your_value.yaml

Add the following values. Update any field containing your or you with your actual values.
Save with CTRL-X (if using nano).

Note that environment is set to development in the samples below. For a live or customer-facing deployment, change this to production.

Sample values.yaml — Single Node Using NodePort

global:
  motarImageRegistry: harbor.dynepic.net
  domainName: your_domain.com
  initialAdminEmail: [email protected]
  environment: production
  mailConfig:
  reportTargets:
    - [email protected]
  securityTargets:
    - [email protected]
  s3Config:
    source: minio
    url: api-minio.your_domain.com

motar:
  ingress:
  className: nginx
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-cluster-issuer # If using certmanager clusterIssuer
    nginx.ingress.kubernetes.io/cors-allow-headers: DNT,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization,clientid
    nginx.ingress.kubernetes.io/enable-cors: "true"
    nginx.ingress.kubernetes.io/proxy-body-size: "0"
  tls:
    enabled: true
    tlsSecret: "webapps-cert" # Substitute with your tlsSecret
  serviceAccount:
    create: true
    name: motar
  minio:
    ingress:
      enabled: true
      className: nginx
      hostname: api-minio.your_domain.com
      annotations:
        apiVersion: networking.k8s.io/v1
        className: nginx
        cert-manager.io/cluster-issuer: letsencrypt-cluster-issuer # If using CertManager/ClusterIssuer
        nginx.ingress.kubernetes.io/proxy-body-size: "0"
      tls:
        enabled: true
        tlsSecret: "api-minio-cert" # Substitute with your tlsSecret
    consoleIngress:
      enabled: true
      className: "nginx"
      annotations:
        apiVersion: networking.k8s.io/v1
        className: nginx
        cert-manager.io/cluster-issuer: letsencrypt-cluster-issuer # If using CertManager/ClusterIssuer
        nginx.ingress.kubernetes.io/proxy-body-size: "0"
      hosts:
        - console-minio.your_domain.com
      tls:
        enabled: true
        tlsSecret: "console-minio-cert" # Substitute with your tlsSecret

storageClass:
  enabled: true
  provisioner: driver.longhorn.io
  parameters:
    fsType: ext4
    numberOfReplicas: "1"
    staleReplicaTimeout: "30"

ingress-nginx:
  enabled: true
  controller:
    service:
      type: "NodePort"
      nodePorts:
        http: 31080
        https: 31443

minio:
  auth:
    existingSecret: "motar-s3-auth"
    rootUserSecretKey: "rootUser"
    rootPasswordSecretKey: "rootPassword"

postgresql:
  sslDisabled: true
  auth:
    existingSecret: "motar-pg-auth"
    secretKeys:
      adminPasswordKey: "postgres-password"
      motarPasswordKey: "motar-password"

Sample values.yaml — AWS EKS

aws_values.yaml

global:
  motarImageRegistry: harbor.dynepic.net
  domainName: your_domain.com
  initialAdminEmail: [email protected]
  environment: production
  mailConfig:
  reportTargets:
    - [email protected]
  securityTargets:
    - [email protected]
  s3Config:
    source: minio
    url: api-minio.your_domain.com

motar:
  ingress:
  className: nginx
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-cluster-issuer # If using certmanager clusterIssuer
    nginx.ingress.kubernetes.io/cors-allow-headers: DNT,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization,clientid
    nginx.ingress.kubernetes.io/enable-cors: "true"
    nginx.ingress.kubernetes.io/proxy-body-size: "0"
  tls:
    enabled: true
    tlsSecret: "webapps-cert" # Substitute with your tlsSecret
  serviceAccount:
    create: true
    name: motar
  minio:
    ingress:
      enabled: true
      className: nginx
      hostname: api-minio.your_domain.com
      annotations:
        apiVersion: networking.k8s.io/v1
        className: nginx
        cert-manager.io/cluster-issuer: letsencrypt-cluster-issuer # If using CertManager/ClusterIssuer
        nginx.ingress.kubernetes.io/proxy-body-size: "0"
      tls:
        enabled: true
        tlsSecret: "api-minio-cert" # Substitute with your tlsSecret
    consoleIngress:
      enabled: true
      className: "nginx"
      annotations:
        apiVersion: networking.k8s.io/v1
        className: nginx
        cert-manager.io/cluster-issuer: letsencrypt-cluster-issuer # If using CertManager/ClusterIssuer
        nginx.ingress.kubernetes.io/proxy-body-size: "0"
      hosts:
        - console-minio.your_domain.com
      tls:
        enabled: true
        tlsSecret: "console-minio-cert" # Substitute with your tlsSecret

storageClass:
  enabled: true
  provisioner: kubernetes.io/aws-ebs
  parameters:
    fsType: ext4
    type: gp3

ingress-nginx:
  enabled: true
  controller:
    config:
      use-proxy-protocol: false
    service:
      type: LoadBalancer
      external:
        enabled: false
      internal:
        externalTrafficPolicy: Local
        enabled: true
        annotations:
          service.beta.kubernetes.io/aws-load-balancer-internal: false
          service.beta.kubernetes.io/aws-load-balancer-backend-protocol: tcp
          service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: true
          service.beta.kubernetes.io/aws-load-balancer-type: nlb-ip

minio:
  auth:
    existingSecret: "motar-s3-auth"
    rootUserSecretKey: "rootUser"
    rootPasswordSecretKey: "rootPassword"

postgresql:
  sslDisabled: true
  auth:
    existingSecret: "motar-pg-auth"
    secretKeys:
      adminPasswordKey: "postgres-password"
      motarPasswordKey: "motar-password"

Step 2 — Prepare the Namespace

Create the namespace:

kubectl create ns motar

Apply the secrets for S3 storage and PostgreSQL.

S3 connectivity is required for core MOTAR functionality. Ensure your global.s3Config.url in values.yaml is reachable from within the cluster with tls to ensure file scanning and external connections function properly. Misconfigured or missing S3 secrets are the most common cause of broken deployments.

Both internal Minio and external S3 configurations require secrets for rootUser and rootPassword. Apply them from a YAML file:

kubectl apply -f mysecrets.yaml -n motar

Example YAML:

apiVersion: v1
data:
  rootPassword: base64enc_value
  rootUser: base64enc_value
kind: Secret
metadata:
  labels:
    app.kubernetes.io/part-of: motar
  name: motar-s3-auth
type: Opaque

Or apply directly using literals:

kubectl -n motar create secret generic motar-pg-auth \
  --from-literal=motar-password=supersecret \
  --from-literal=postgres-password=topsecret

kubectl -n motar create secret generic motar-s3-auth \
  --from-literal=rootUser=minioUser \
  --from-literal=rootPassword=topsecretPassword

If you would like to apply a TLS certificate for use on your ingress and are not using CertManager, this is the point to do so.

Step 3 — Deploy the Chart

helm install motar --version 3.2.6 oci://harbor.dynepic.net/helmrelease/motar -f your_values.yaml -n motar

Step 4 — Access the Site

If you have correctly configured DNS routing to your hosting device, MOTAR should now be accessible at https://admin.your_domain.com.

You have completed Helm setup and may continue to Step 3 — Access Your MOTAR Instance.

NodePort Configuration

If using a NodePort configuration for your ingress controller, you will need to ensure traffic is routed to the correct port within your deployed environment. Below is a sample setup using an nginx reverse proxy.

Install the required services:

sudo apt update
sudo apt install nginx
sudo apt install libnginx-mod-stream
sudo vim /etc/nginx/nginx.conf

Include the proxy passthrough by appending the following outside the http block:

http {
  # default configuration
}
include /etc/nginx/passthrough.conf;

Create /etc/nginx/passthrough.conf with ports matching the NodePort values in your values file:

stream {
  server {
    listen 80;
    proxy_pass 127.0.0.1:31080;
  }
  server {
    listen 443;
    proxy_pass 127.0.0.1:31443;
  }
}

Forward HTTP to HTTPS with a redirect rule. Create a site config:

sudo vim /etc/nginx/sites-available/your.domain

server {
  if ($host ~ ^[^.]+\.your\.domain$) {
    return 301 https://$host$request_uri;
  }
  listen 80;
}

Remove the default nginx site and reload:

sudo rm /etc/nginx/sites-enabled/default
sudo nginx -t
sudo systemctl reload nginx

Upgrading MOTAR with Helm

To upgrade an existing MOTAR installation to a new chart version:

helm upgrade motar --version <new_version> oci://harbor.dynepic.net/helmrelease/motar -f your_values.yaml -n motar

Replace <new_version> with the target chart version. Your existing values file can be reused unless otherwise noted in the release notes.

Troubleshooting FAQ

Services are running but the platform is not loading or media is missing.

This is most commonly caused by S3 connectivity not being established. Verify:

Your global.s3Config.url in values.yaml is correct and reachable from within the cluster.
The motar-s3-auth secret was applied to the motar namespace.
If using internal Minio, confirm the Minio ingress is healthy: kubectl get ingress -n motar

Optional / Alternative Deployments

MOTAR AI Engine with Zero Trust Orchestration Layer (beta) Installation

Note: This is an advanced configuration.

Our MOTAR system includes a dedicated query server that requires an LLM. The query server interfaces with the LLM using OLLAMA API endpoints. We provide an OCI image containing all necessary components for the query server. To leverage your NVIDIA GPU, ensure the nvidia-container-toolkit is installed.

If you prefer to manage dependencies yourself, the query server also requires a Redis database and the following Docker environment variables:

LLM_API_HOST:  ${LLM_API_HOST}
PG_USER: ${POSTGRES_USER}
PG_PASS: ${POSTGRES_PASSWORD}
PG_DBNAME: ${POSTGRES_DB}
PG_HOST: ${POSTGRES_HOST}
PG_PORT: ${POSTGRES_PORT}
MINIO_ENDPOINT: ${MINIO_ENDPOINT}
MINIO_ACCESS_KEY: ${MINIO_ROOT_USER}
MINIO_SECRET_KEY: ${MINIO_ROOT_PASSWORD}
REDIS_HOST: ${REDIS_HOST}
REDIS_PORT: ${REDIS_PORT}
REDIS_DB: ${REDIS_DB}

PG_* variables: Access to MOTAR's PostgreSQL database.
MINIO_* variables: Credentials for your MOTAR MinIO instance.

Example: Running OLLAMA and Redis Containers

OLLAMA:

ollama:
    image: ollama/ollama:latest
    container_name: ollama
    restart: unless-stopped
    runtime: nvidia
    ports:
        - "11434:11434"
    volumes:
        - ollama_models:/models
    environment:
        LOG_LEVEL: debug
        OLLAMA_MODELS: /models
        OLLAMA_DEBUG: 1
    entrypoint: ["/bin/bash"]
    command: ["-c", "dpkg --configure -a && apt update && apt install curl -y && sleep 5 && ollama serve & sleep 15 && ollama pull llama3 && pkill ollama && ollama serve"]
    healthcheck:
        test: ["CMD-SHELL", "curl -sf http://localhost:11434/api/tags | grep llama3"]
        interval: 10s
        timeout: 5s
        retries: 60
        start_period: 15s

Redis:

redis:
    image: redis:7-alpine
    container_name: redis
    restart: unless-stopped
    volumes:
        - redis_data:/data

MOTAR Configuration (External Query Server)

Ensure MOTAR can access your query server. Example values file (AI section only):

motar:
    ai:
        enabled: false  # Only deploys AI dependencies via Helm
        queryServer:
            external:
                enabled: true
                url: http://IP.OF.QUERY.SERVER
                port: 8000

MOTAR Configuration (In-Cluster Deployment)

To run everything inside your cluster, use a node configured for NVIDIA GPU passthrough. Apply a taint (e.g., ai) to schedule the query server and OLLAMA. Example values:

ai:
    enabled: true
    llmServer:
        NodeSelector: node-role.kubernetes.io/ai: "true"
        runtimeClassName: "nvidia"
        tolerations:
            - key: "ai"
              operator: "Equal"
              value: true
              effect: "NoSchedule"
        storageSize: 10Gi
        models:
            - llama3:latest
        storageClassName: ""
        resourcesPreset: "gpuMedium"
        resources: {}
    queryServer:
        NodeSelector: node-role.kubernetes.io/ai: "true"
        tolerations:
            - key: "ai"
              operator: "Equal"
              value: true
              effect: "NoSchedule"
        runtimeClassName: "nvidia"

Adjust values and configuration as needed for your environment and deployment strategy.

MOTAR Discovery: Connecting an XR Headset

When testing MOTAR locally using a Discovery license, it is possible to connect wireless XR headsets to your instance. However, this configuration is advanced and highly dependent on your current networking hardware, networking knowledge, and configuration permissions.

Proceed with Caution

While none of the following configurations will "break" your system and can be reversed, they may cause a loss of functionality for some users.

We don't recommend this configuration if you are not comfortable with altering both your network and the headset configuration.

Your network and hardware should meet the following criteria:

An accessible and configurable router
Developer permissions on the XR headset
Admin permissions on the hosting computer

Connecting a wireless XR device to your local MOTAR test install may require the following changes based on your network and headset hardware:

Router Based Configuration — requires a configurable network router
- Customized record(s) added to the network router
Device Based Configuration
- Hosting and configuring files directly on an XR headset
- Update local host files and/or updates to primary DNS
- Local Domain Name Service changes

Meta Quest 3 Configuration

Coming soon. For questions in the meantime, please contact us.

Single-Node Setup with MicroK8s

Single-Node Setup with MicroK8s (Development / Evaluation)

This setup is not suitable for production. A single-node MicroK8s instance has no high availability, no horizontal scaling, and no redundancy. It is appropriate for development, evaluation, or getting MOTAR running correctly while you plan your production infrastructure. For mission-critical or large-scale deployments, use a managed Kubernetes service such as AWS EKS, GKE, or AKS.

This page is for teams that do not already have a Kubernetes cluster running. If you have an existing cluster (e.g. AWS EKS, GKE, or self-managed), skip this page and proceed directly to the Advanced Deployment Guide.

MOTAR's Helm-based deployment requires a running Kubernetes cluster. If you are deploying on a single server or EC2 instance and do not have a cluster set up, MicroK8s provides a simple path to get a correct Kubernetes environment running quickly. The same MOTAR Helm chart and values.yaml used here will work against any managed Kubernetes cluster when you are ready to scale.

Note: MOTAR support covers the Helm chart deployment and platform configuration. Setting up and administering your Kubernetes environment is outside the scope of MOTAR support. This page provides general guidance to help you get started.

Prerequisites

An EC2 instance or server running Ubuntu 24.04 LTS (recommended)
SSH access to the instance
sudo privileges
Minimum recommended specs: 4 vCPU, 8GB RAM, 50GB storage (adjust based on your workload)

Step 1 — Install MicroK8s

MicroK8s is distributed via snap and installs in a single command.

sudo snap install microk8s --classic

Add your user to the microk8s group to avoid needing sudo for every command:

sudo usermod -aG microk8s $USER
newgrp microk8s

Verify the cluster is ready:

microk8s status --wait-ready

Step 2 — Enable Required Add-ons

MicroK8s uses add-ons for core functionality. Enable the following:

microk8s enable dns storage ingress

Add-on

Purpose

dns

Internal cluster DNS resolution

storage

Persistent volume provisioning (required for MOTAR data)

ingress

HTTP/HTTPS ingress controller

Step 3 — Configure kubectl

MicroK8s ships with its own kubectl. You can either use it directly with the microk8s kubectl prefix, or alias it for convenience:

alias kubectl='microk8s kubectl'

To make the alias permanent, add it to your ~/.bashrc or ~/.bash_profile:

echo "alias kubectl='microk8s kubectl'" >> ~/.bashrc
source ~/.bashrc

Verify cluster access:

kubectl get nodes

You should see your node listed with a Ready status.

Step 4 — Install Helm

MOTAR is deployed via Helm. Install it with:

sudo snap install helm --classic

Verify the installation:

helm version

Next Step

Once MicroK8s is running and Helm is installed, you are ready to deploy MOTAR.

For full MicroK8s documentation, visit canonical.com/microk8s.

Following the Installation and Tutorial Guide?
If you are following along with the tutorial, you should be ready to access and configure your MOTAR Instance. Click the link below to return:
https://docs.motar.com/motar-tutorials#id-3-access-your-motar-instance

PreviousProduction Installation NextMOTAR Tutorials

Last updated 16 days ago

hashtagHelm Chart for Kubernetes

hashtagPrerequisites

hashtagStep 1 — Configuration

hashtagStep 2 — Prepare the Namespace

hashtagStep 3 — Deploy the Chart

hashtagStep 4 — Access the Site

hashtagOptional / Alternative Deployments

hashtagProceed with Caution

hashtagMeta Quest 3 Configuration

hashtagPrerequisites

hashtagStep 1 — Install MicroK8s

hashtagStep 2 — Enable Required Add-ons

hashtagStep 3 — Configure kubectl

hashtagStep 4 — Install Helm

hashtagNext Step

hashtagFollowing the Installation and Tutorial Guide?

Helm Chart for Kubernetes

Prerequisites

Step 1 — Configuration

Step 2 — Prepare the Namespace

Step 3 — Deploy the Chart

Step 4 — Access the Site

Optional / Alternative Deployments

Proceed with Caution

Meta Quest 3 Configuration

Prerequisites

Step 1 — Install MicroK8s

Step 2 — Enable Required Add-ons

Step 3 — Configure kubectl

Step 4 — Install Helm

Next Step

Following the Installation and Tutorial Guide?