XR Container Access Portal

Repository/Image	Description
`xr-dev/xr-e`	Editor — nightly builds (mutable tags)
`xr-release/xr-e`	Editor — General Availability (immutable tags)
`xr-dev/xr-ds`	Deployment Server — nightly builds (mutable tags)
`xr-release/xr-ds`	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.

For automated access download the XR ECR authentication helper — a Linux/macOS bash script for Docker or Podman, or a PowerShell script for Windows.

Runtime:

Docker (bash)

Podman (bash)

Windows (PowerShell)

Usage: ./xr-ecr-auth.sh login -u your-email@company.com -p your-password

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.
jq — for parsing AWS responses. sudo apt install jq (Ubuntu/WSL), sudo dnf install jq (Fedora/RHEL), brew install jq (macOS).
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...

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...

Images in the registry are tagged with their build number (for example 7.0.18827) and often also with a moving tag such as latest. A host that pulled latest only remembers latest, and the containers ship without a shell, so docker exec cannot tell you more. Instead, take the digest of the pulled image and ask the registry which tags are attached to it. Nothing needs to be running — the digest is a property of the image.

Same syntax in bash and PowerShell. Substitute podman for docker on Podman hosts.

# All images pulled from the XpertRule registry, one per line
docker images --digests --format '{{.Repository}}:{{.Tag}}@{{.Digest}}' --filter reference='915149977821.dkr.ecr.eu-west-2.amazonaws.com/*/*'

# Or a single image
docker image inspect --format '{{.RepoDigests}}' 915149977821.dkr.ecr.eu-west-2.amazonaws.com/xr-dev/xr-ds:latest

Each line ends with the digest. Copy everything after the @ — sha256: plus the 64 characters — for the image you are interested in. In this example line, copy the highlighted part:

915149977821.dkr.ecr.eu-west-2.amazonaws.com/xr-dev/xr-ds:latest@sha256:e2e982a57d4a4daad34ddb0d3e0fffa565d2496a7cfb33d83fa4874eff6236ec

Also note the repository — the part between the registry host and the :, here xr-dev/xr-ds. An image ending in @<none> was built locally rather than pulled from the registry and cannot be looked up.

Needs the AWS CLI with credentials that can call ecr:DescribeImages on the XpertRule registry. Paste the digest you copied over the highlighted part, and set --repository-name to the repository from the same line.

aws ecr describe-images --region eu-west-2 \
    --repository-name xr-dev/xr-ds \
    --image-ids imageDigest=sha256:<paste the digest here> \
    --query 'imageDetails[0].[imageTags,imagePushedAt]'

Example result:

[
    [
        "latest",
        "7.0.18830"
    ],
    "2026-08-20T10:15:00+01:00"
]

The build-number tag (here 7.0.18830) is the version you have. If only latest comes back, that image was pushed without a build-number tag — quote the digest and the pushed date to XpertRule support instead. ImageNotFoundException means the digest is not in that repository: check the repository name, or try the xr-release/ equivalent.

Does the same lookup as Step 2 using your portal login. Run the Step 1 command on your host, then paste the output here — either just the sha256:… part or the whole output line — and press Look up.

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.

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.

Standalone PDF guides — the same documents that ship inside each client package, downloadable individually so you can read before you deploy.

Loading deployment guides...

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.

Podman and Podman Compose installed

Access to XR container images (authentication completed via ECR script)

Configuration files (settings and license)

The Podman compose commands should be run from a parent directory that contains both the compose files and the config/ folder:

your-project-directory/           ← Run podman-compose commands from here
├── podman-compose-xr-ds.yml
├── podman-compose-xr-platform.yml
├── podman-compose-full.yml
└── configs/
    ├── xr-e/
    │   ├── settings.json
    │   └── licence.json
    ├── xr-ds/
    │   ├── settings.json
    │   └── license.json
    └── xr-xsi/
        └── settings.json

Create the following directory structure and files:

./configs/
├── xr-e/
│   ├── settings.json
│   └── licence.json
├── xr-ds/
│   ├── settings.json
│   └── license.json
└── xr-xsi/
    └── settings.json

xr-e Settings

File: ./configs/xr-e/settings.json

Loading xr-e settings...

xr-ds Settings

File: ./configs/xr-ds/settings.json

Loading xr-ds settings...

Please see settings help for more information

xr-xsi Settings

File: ./configs/xr-xsi/settings.json

Loading xr-xsi settings...

Option 1: xr-ds Only

Use this option to deploy only the xr-ds service with MongoDB.

Loading podman-compose-xr-ds.yml...

# 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...

# 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...

podman-compose -f podman-compose-full.yml up -d

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)

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

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.

Docker and Docker Compose installed

Access to XR container images (authentication completed via ECR script)

Configuration files (settings and license)

The Docker compose commands should be run from a parent directory that contains both the compose files and the config/ folder:

your-project-directory/           ← Run docker compose commands from here
├── docker-compose-xr-ds.yml
├── docker-compose-xr-platform.yml
├── docker-compose-full.yml
└── configs/
    ├── xr-e/
    │   ├── settings.json
    │   └── licence.json
    ├── xr-ds/
    │   ├── settings.json
    │   └── license.json
    └── xr-xsi/
        └── settings.json

Create the following directory structure and files:

./configs/
├── xr-e/
│   ├── settings.json
│   └── licence.json
├── xr-ds/
│   ├── settings.json
│   └── license.json
└── xr-xsi/
    └── settings.json

xr-e Settings

File: ./configs/xr-e/settings.json

Loading xr-e settings...

xr-ds Settings

File: ./configs/xr-ds/settings.json

Loading xr-ds settings...

xr-xsi Settings

File: ./configs/xr-xsi/settings.json

Loading xr-xsi settings...

Option 1: xr-ds Only

Use this option to deploy only the xr-ds service with MongoDB.

Loading docker-compose-xr-ds.yml...

# Update configs/xr-ds/settings.json with your MongoDB connection details
docker compose -f docker-compose-xr-ds.yml up -d

Option 2: xr-ds + xr-e

Use this option for a complete XR platform with MongoDB.

# docker-compose-xr-platform.yml
version: '3.8'

services:
  xr-e:
    image: 915149977821.dkr.ecr.eu-west-2.amazonaws.com/xr-dev/xr-e
    ports:
      - "8080:8080"
    volumes:
      - ./configs/xr-e/settings.json:/var/www/html/settings/settings.json:ro
      - ./configs/xr-e/licence.json:/var/www/html/php/data/licence.json:ro
    restart: unless-stopped
    networks:
      - xr-network

  xr-ds:
    image: 915149977821.dkr.ecr.eu-west-2.amazonaws.com/xr-dev/xr-ds
    ports:
      - "8100:8100"
    volumes:
      - ./configs/xr-ds/settings.json:/usr/xr/jeremy/settings/settings.json:ro
      - ./configs/xr-ds/license.json:/usr/xr/jeremy/settings/license.json:ro
    depends_on:
      - xr-e
    restart: unless-stopped
    networks:
      - xr-network

networks:
  xr-network:
    driver: bridge

# Update configs/xr-ds/settings.json with your MongoDB connection details
docker compose -f docker-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.

# docker-compose-full.yml
version: '3.8'

services:
  mongo:
    image: mongo:latest
    ports:
      - "27017:27017"
    volumes:
      - mongo-data:/data/db
      - mongo-config:/data/configdb
    environment:
      - MONGO_INITDB_ROOT_USERNAME=admin
      - MONGO_INITDB_ROOT_PASSWORD=password
    restart: unless-stopped
    networks:
      - xr-network

  xr-xsi:
    image: 915149977821.dkr.ecr.eu-west-2.amazonaws.com/xr-dev/xr-xsi
    ports:
      - "8150:8150"
    volumes:
      - ./configs/xr-xsi/settings.json:/usr/xr/xsi/settings/settings.json:ro
      - xr-xsi-data:/usr/xr/xsi/data
    restart: unless-stopped
    networks:
      - xr-network

  xr-e:
    image: 915149977821.dkr.ecr.eu-west-2.amazonaws.com/xr-dev/xr-e
    ports:
      - "8080:8080"
    volumes:
      - ./configs/xr-e/settings.json:/var/www/html/settings/settings.json:ro
      - ./configs/xr-e/licence.json:/var/www/html/php/data/licence.json:ro
    depends_on:
      - xr-xsi
    restart: unless-stopped
    networks:
      - xr-network

  xr-ds:
    image: 915149977821.dkr.ecr.eu-west-2.amazonaws.com/xr-dev/xr-ds
    ports:
      - "8100:8100"
    volumes:
      - ./configs/xr-ds/settings.json:/usr/xr/jeremy/settings/settings.json:ro
      - ./configs/xr-ds/license.json:/usr/xr/jeremy/settings/license.json:ro
    depends_on:
      - mongo
      - xr-e
      - xr-xsi
    restart: unless-stopped
    networks:
      - xr-network

volumes:
  mongo-data: {}
  mongo-config: {}
  xr-xsi-data: {}

networks:
  xr-network:
    driver: bridge

docker compose -f docker-compose-full.yml up -d

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)

Basic Operations

# Start services in detached mode
docker compose -f docker-compose-full.yml up -d

# Stop services
docker compose -f docker-compose-full.yml down

# View running services
docker compose -f docker-compose-full.yml ps

# Follow logs
docker compose -f docker-compose-full.yml logs -f

# Restart a specific service
docker compose -f docker-compose-full.yml restart xr-ds

Container Management

Docker Compose manages containers as individual units:

# List containers
docker ps

# Inspect container details
docker inspect <container-name>

# Stop specific container
docker stop <container-name>

# Remove container
docker rm <container-name>

Volume Management

# List volumes
docker volume list

# Inspect volume
docker volume inspect <volume-name>

# Remove unused volumes
docker volume prune

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.

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...

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.

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.

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...

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).

Two bash scripts for moving data in and out of a MongoDB or AWS DocumentDB instance using mongodump / mongorestore. Use them to seed a fresh deployment, snapshot a running database, or copy data between environments.

These are bash scripts. There is no PowerShell equivalent in this package — Windows users should run them from WSL.

Ships export-mongo.sh, import-mongo.sh, and README.md. Unzip into an empty directory, edit the REPLACE_ME_* values at the top of each script, then run.

or grab individual files:

Every value marked REPLACE_ME_* in the CONFIG block at the top of each script must be filled in before running. The scripts refuse to start while any placeholder remains.

`export-mongo.sh` — source (read-from)

Variable	Meaning
`SRC_HOST`	Hostname / cluster endpoint of the source DB
`SRC_PORT`	Port (usually `27017`)
`SRC_USERNAME`	User with read rights on the source
`SRC_PASSWORD`	Password for that user

`import-mongo.sh` — target (write-to)

Variable	Meaning
`DST_HOST`	Hostname / cluster endpoint of the target DB
`DST_PORT`	Port (usually `27017`)
`DST_USERNAME`	User with write rights on the target
`DST_PASSWORD`	Password for that user

Everything else in the CONFIG block (auth database, scope filters, TLS, gzip, drop-before-insert, parallelism, dump directory) has a sensible default. Review the header comment in each script for the full reference, or read the bundled README.md.

MongoDB Database Tools (mongodump / mongorestore) on PATH. On Ubuntu / WSL:

wget -qO /tmp/mdbtools.deb \
  https://fastdl.mongodb.org/tools/db/mongodb-database-tools-ubuntu2204-x86_64-100.10.0.deb \
  && sudo apt-get install -y /tmp/mdbtools.deb && rm /tmp/mdbtools.deb

Network access to the source / target from the host running the script. AWS DocumentDB endpoints are VPC-private — run from a bastion / EC2 in the same VPC, or a tunnel to it.

(DocumentDB only) RDS/DocDB CA bundle. TLS is mandatory for DocumentDB; download the bundle once:

curl -o global-bundle.pem https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem

Then set SRC_TLS="true" / DST_TLS="true" in the relevant script and point *_TLS_CA_FILE at it.

# 1. unpack and edit the REPLACE_ME_* values
unzip db-migrate.zip -d db-migrate && cd db-migrate
chmod +x export-mongo.sh import-mongo.sh
$EDITOR export-mongo.sh    # fill in SRC_*
$EDITOR import-mongo.sh    # fill in DST_*

# 2. dry-run first (prints the mongodump / mongorestore command it would execute)
./export-mongo.sh --dry-run
./import-mongo.sh --dry-run

# 3. run
./export-mongo.sh                            # writes ./dumps/<timestamp>/
./import-mongo.sh                            # restores newest dump under ./dumps/
./import-mongo.sh ./dumps/20260728-140000Z   # or restore a specific dump

import-mongo.sh prints the target details and prompts for confirmation before writing. Pass --yes to skip the prompt in scripted runs.

Available Containers

Command Line Authentication

How to... access containers

How to... check which version you have

Step 1 — get the image digest on the host

Step 2 — ask the registry which tags carry that digest

No AWS CLI? Paste the digest here instead

Deployments overview

Choosing a deployment path

Backing store (MongoDB)

Deployment guides

Podman Compose Deployment

Download the complete Podman deployment bundle

Working Directory Structure

Configuration Files

Deployment Options

Podman Management Commands

Docker Compose Deployment

Download the complete Docker deployment bundle

Working Directory Structure

Configuration Files

Deployment Options

Docker Management Commands

Azure Deployments

Before you deploy

Quick reference

AWS Deployments

Before you deploy

Quick reference

MongoDB / DocumentDB migration

Download the db-migrate bundle

Values you must provide

`export-mongo.sh` — source (read-from)

`import-mongo.sh` — target (write-to)

Prerequisites

Typical run

Available Containers

Command Line Authentication

How to... access containers

How to... check which version you have

Step 1 — get the image digest on the host

Step 2 — ask the registry which tags carry that digest

No AWS CLI? Paste the digest here instead

Deployments overview

Choosing a deployment path

Backing store (MongoDB)

Deployment guides

Podman Compose Deployment

Download the complete Podman deployment bundle

Working Directory Structure

Configuration Files

Deployment Options

Podman Management Commands

Docker Compose Deployment

Download the complete Docker deployment bundle

Working Directory Structure

Configuration Files

Deployment Options

Docker Management Commands

Azure Deployments

Before you deploy

Quick reference

AWS Deployments

Before you deploy

Quick reference

MongoDB / DocumentDB migration

Download the db-migrate bundle

Values you must provide

export-mongo.sh — source (read-from)

import-mongo.sh — target (write-to)

Prerequisites

Typical run

`export-mongo.sh` — source (read-from)

`import-mongo.sh` — target (write-to)