Deployment Server — General Availability (immutable tags)
xr-dev/xr-xsi
Identity Broker — nightly builds (mutable tags)
xr-release/xr-xsi
Identity Broker — General Availability (immutable tags)
Note:xr-release/* repositories use IMMUTABLE tag policies — a tag you pin today cannot be silently replaced. Use these for production. xr-dev/* tags are mutable and intended for internal / preview use.
Command Line Authentication
For automated access download the XR ECR authentication helper — a Linux/macOS bash script for Docker or Podman, or a PowerShell script for Windows.
Prerequisites — what to install before running the script
The script shells out to standard tools. Install these first, then log out and back in if you had to change group membership:
AWS CLI v2 — used to talk to Cognito and ECR. Install from docs.aws.amazon.com/cli. No aws configure needed — the script sets temporary credentials itself.
Docker or Podman — whichever runtime you picked above. Docker needs a running daemon and the user in the docker group; Podman is rootless out of the box.
PowerShell 5.1+ (Windows only) — plus the AWS Tools for PowerShell module (Install-Module AWS.Tools.CognitoIdentityProvider).
Confirm each tool works: aws --version, jq --version, docker info (or podman info). A common trap is a partial AWS CLI v2 install where aws is on PATH but reports Could not load PyInstaller's embedded PKG archive — reinstall to fix.
Use the commands shown below to pull containers. Click View Tags to see all images for that repo.
Loading container information...
How to... access containers
Step-by-step walkthroughs for authenticating with the XR ECR registry and pulling platform images on each supported host. Pick the guide that matches your workstation — the WSL and native-Windows guides also cover PowerShell, the Fedora and RHEL guides cover the Linux bash flow.
Loading how-to guides...
Deployments overview
Choosing a deployment path
Four established deployment paths are supported. Three are cloud client-packages you deploy into your own subscription/account; the fourth is on-prem via compose files.
Path
Where it runs
Backing store
When to pick it
Azure Container Apps
Managed Container Apps environment in your Azure subscription
Cosmos DB (Mongo API)
New Azure deployments — scales to zero when idle, per-service redeploys supported.
Azure App Service
Web Apps for Containers on a shared App Service plan
Cosmos DB (Mongo API)
Teams already running App Service workloads — managed TLS, familiar lifecycle.
AWS ECS Fargate
ECS Fargate with EFS + ALB in your AWS account
DocumentDB Serverless (Mongo-compatible)
AWS-native customers — DocumentDB is provisioned as part of deploy.sh, no separate step.
On-prem compose
Podman or Docker Compose on a host you own
Self-hosted MongoDB (container or bare-metal)
Air-gapped or customer-managed hosts (RHEL, etc). See Podman / Docker Compose in the sidebar.
Backing store (MongoDB)
xr-ds requires a MongoDB-compatible database. Which one you use depends on the path:
Azure Container Apps / App Service: Cosmos DB with the Mongo API. Provision once, share across environments. See the Azure Cosmos DB (MongoDB) Setup Guide under Deployment guides — step-by-step create + connection-string capture.
AWS ECS Fargate: Amazon DocumentDB Serverless. Provisioned automatically by ./scripts/ecs/deploy.sh as part of the CloudFormation stack — no manual install.
On-prem compose: MongoDB runs as a container in the compose file, or on the host bare-metal. For production, use the *.hardened.yml variants — they pin mongo:7, set a mandatory MONGO_PASSWORD, and cap the WiredTiger cache. Remove the mongo service block if you already run Mongo on the host.
Deployment guides
Standalone PDF guides — the same documents that ship inside each client package, downloadable individually so you can read before you deploy.
Loading deployment guides...
Podman Compose Deployment
Download the complete Podman deployment bundle
Everything you need in one zip: the three compose files and the configs/ template tree. Unzip in an empty directory and follow the sections below.
Prerequisites
Podman and Podman Compose installed
Access to XR container images (authentication completed via ECR script)
Configuration files (settings and license)
Working Directory Structure
Important: Command Execution Location
The Podman compose commands should be run from a parent directory that contains both the compose files and the config/ folder:
Use this option to deploy only the xr-ds service with MongoDB.
Loading podman-compose-xr-ds.yml...
Run xr-ds with MongoDB:
# Update configs/xr-ds/settings.json with your MongoDB connection details
podman-compose -f podman-compose-xr-ds.yml up -d
Option 2: xr-ds + xr-e
Use this option for a complete XR platform with MongoDB.
Loading podman-compose-xr-platform.yml...
Run XR platform with MongoDB:
# Update configs/xr-ds/settings.json with your MongoDB connection details
podman-compose -f podman-compose-xr-platform.yml up -d
Option 3: xr-ds + xr-e + MongoDB (Full Stack)
Use this option for a complete self-contained XR platform with MongoDB included.
Loading podman-compose-full.yml...
Run full stack:
podman-compose -f podman-compose-full.yml up -d
Access Points
After deployment:
xr-e (XR Editor): http://localhost:8080 (available in options 2 and 3)
xr-ds (XR Deployment Server): http://localhost:8100 (available in all options)
xr-xsi (XR Identity Broker): http://localhost:8150 (only in option 3, full stack)
MongoDB: localhost:27017 (only exposed in option 3)
Podman Management Commands
Basic Operations
# Start services in detached mode
podman-compose -f podman-compose-full.yml up -d
# Stop services
podman-compose -f podman-compose-full.yml down
# View running services
podman-compose -f podman-compose-full.yml ps
# Follow logs
podman-compose -f podman-compose-full.yml logs -f
# Restart a specific service
podman-compose -f podman-compose-full.yml restart xr-ds
Pod Management
Podman Compose creates pods for related containers:
# List pods
podman pod list
# Inspect pod details
podman pod inspect <pod-name>
# Stop entire pod
podman pod stop <pod-name>
# Remove pod and containers
podman pod rm <pod-name>
Volume Management
# List volumes
podman volume list
# Inspect volume
podman volume inspect <volume-name>
# Remove unused volumes
podman volume prune
Docker Compose Deployment
Download the complete Docker deployment bundle
Everything you need in one zip: the three compose files and the configs/ template tree. Unzip in an empty directory and follow the sections below.
Prerequisites
Docker and Docker Compose installed
Access to XR container images (authentication completed via ECR script)
Configuration files (settings and license)
Working Directory Structure
Important: Command Execution Location
The Docker compose commands should be run from a parent directory that contains both the compose files and the config/ folder:
# List volumes
docker volume list
# Inspect volume
docker volume inspect <volume-name>
# Remove unused volumes
docker volume prune
Azure Deployments
Self-contained client packages for deploying the XR platform (xr-xsi, xr-e, xr-ds) into your own Azure subscription. Each package includes deploy and teardown scripts, Bicep / Infra templates, configuration templates, the Entra ID setup helper, and the deployment guide PDF.
Before you deploy
An Azure subscription with Contributor on the target resource group.
An Entra ID tenant and a one-off window with Application Administrator rights to register the xr-xsi application.
A Cosmos DB (or Mongo-compatible) connection string for xr-ds. The deploy script will prompt for it.
Platform licence files (config/xr-ds/license.json, config/xr-e/licence.json) supplied separately by XpertRule.
Authenticated aws CLI (this portal) for the platform image imports.
Loading Azure deployment packages...
Quick reference
Once the package is unpacked and licence files are in place:
# 1. Register the Entra ID Enterprise Application for xr-xsi
./tools/setup-azuread.sh
# 2. Deploy (Container Apps example)
./scripts/container_apps/deploy.sh rg-xr-as-aca dev westeurope
# 2. Deploy (App Service example)
./scripts/app_service/deploy.sh rg-xr-as-appsvc dev westeurope B1
Full prerequisites, day-2 operations, and per-service redeploy steps are documented in the deployment guide PDF inside each package.
AWS Deployments
Self-contained client package for deploying the XR platform (xr-xsi, xr-e, xr-ds) onto AWS using ECS Fargate, EFS, an Application Load Balancer, and Amazon DocumentDB Serverless (Mongo-compatible). The package includes the interactive setup.sh wizard, CloudFormation-driven deploy/destroy scripts, config templates, the Entra ID setup helper, and the deployment guide PDF.
Before you deploy
AWS CLI signed in to the target account with rights to create CloudFormation / ECS / EFS / ELBv2 / Route 53 / ACM / DocumentDB Serverless resources.
A Route 53 hosted zone you own (ACM certificates and the ALB listener are provisioned into it).
Azure CLI signed in to the tenant that owns the Entra ID app registration (only needed when setup.sh creates a new app for xr-xsi sign-in).
Docker or Podman installed locally — used to copy platform images from XpertRule's ECR into your own ECR (your tasks run from your local copy, not ours).
The xr-ecr-auth.sh helper from the Containers tab — drop it at the package root before running setup.sh. No second AWS profile required.
Platform licence files (config/xr-ds/license.json, config/xr-e/licence.json) supplied separately by XpertRule.
Loading AWS deployment package...
Quick reference
Once the package is unpacked, xr-ecr-auth.sh is in place, and licence files are copied under config/:
# Interactive wizard: captures Entra ID + Route 53 + admin user, then deploys.
./setup.sh
# Or skip the wizard and call deploy directly (positional args default to
# the pre-baked package.conf when you leave them off):
./scripts/ecs/deploy.sh [stack-name] [env] [region] [hosted-zone]
# Tear down (deletes only the per-stack resources):
./scripts/ecs/destroy.sh [stack-name] [region]
The pre-baked package ships with --company-name demo, which becomes the resource-name suffix (xr-demo-dev-*) and the default Entra app name. Contact XpertRule for a per-tenant rebuild if you need a different label. Full prerequisites, day-2 operations, persistence semantics, and redeploy / scale / destroy flows are documented in the deployment guide PDF inside the package (and downloadable from the sidebar).