Sandbox VM Deployment
For testing and development purposes a single VM sandbox is also available.
The sandbox VM is an all-in-one Rierino environment that runs on a single machine using Docker Compose. It is designed for evaluation, training, and development workflows where you want everything bundled and runnable without Kubernetes.
When to choose the sandbox VM
Use this option when you want:
A single-VM environment with platform components and enabling systems included.
A quick way to explore the UI and core flows without provisioning a cluster.
A lightweight dev/test environment for one person or a small team.
Choose Kubernetes instead when you need higher scale, high availability, or multi-node operations.
Minimum VM requirements
This environment requires a single VM with at least:
4 vCPU
16 GB RAM
If you plan to enable more optional modules, allocate more RAM and disk. Start small, then scale up based on container memory usage.
What gets deployed
The sandbox includes the following components. You can disable parts using Docker Compose profiles/services (see the sandbox repo README for the exact profile names and commands).
Admin UI
Admin Controller
Admin Runner (with Core platform services as well as optional PIM, CMS, training modules)
MongoDB
Optional:
Ops Runner (used with optional modules for CDC and real-time data synch)
Kafka (and Kafka UI)
Elasticsearch
Redis
Browserless (for web scrapping use cases)
LocalAI (for local LLM models)
Prometheus (for metrics collection)
Quickwit (for logs collection)
Get the sandbox assets
The sandbox artifacts live in the public sandbox repository (requires credentials provided with the Rierino license):
https://github.com/rierino-open/sandbox
The main runbook is in composite/README.MD.
Prerequisites on the VM
Before launching, make sure the VM has:
Docker Engine
Docker Compose (v2 recommended)
Network access to pull images and fetch artifacts from GitHub (or your internal mirrors)
If your VM sits behind strict egress controls, make sure it can reach your artifact sources (Docker registry + GitHub). Most “it won’t start” issues are just blocked outbound traffic.
Configuration
Core settings (composite/.env)
composite/.env)Set the following variables in composite/.env before you start:
RIERINO_VERSION: Rierino version to be deployed
GITHUB_USER: Provided username for access to Rierino assets
GITHUB_AUTH_TOKEN: Provided authentication token for access to Rierino assets
Optional: AI enablement
For using GenAI models on runners, LLM provider related secret configuration can be added to globalsecrets.properties file under admin_runner folder before restarting services. Training examples use OpenAI as the sample provider, which can be configured by setting the following key/value in this file.
For using embedded RAI frontend agents, OpenAI related environment variables can be configured in "composite/adminui.env" file, enabling AI assistant use in admin UI.
Using Local LLM Models
If you prefer to use local LLM models instead of an external provider, it is possible with the following steps:
Deploy localai service using
docker compose up localaicommandLocalAI will be available on
http://[YOUR_VM_IP]:3333address with "local" as the login tokenActivate the model(s) and backend(s) you would like to use, or upload your custom trained model
You can then use this model in GenAI model screen either with LocalAI settings or OpenAI (setting baseUrl to
http://localai.admin-backend.svc.cluster.local:8080) since LocalAI service supports standard OpenAI APIs as well
Optional: Monitoring enablement
By default all logs are printed on the docker container console, however all Rierino backend services support OpenTelemetry feeds for metrics, traces and logs, which can be used with optional components for more structured monitoring even in the sandbox deployment.
Deploy prometheus and quickwit services using
docker composecommandEdit .env file with the following parameter values for exporting logs and metrics and run docker compose up for runner services to apply changes:
Monitoring in Admin UI
Saga screens include a monitoring tab, displaying metrics and logs specific to the current saga and its steps. These information are already mapped in the Saga UI design screen, all you need to do for activating display of this data is uncommenting the lines in Handlebars displays configured in this screen.
What goes where (quick map)
composite/.envcontrols the overall sandbox deployment (version, access credentials, public address).composite/adminui.envcontrols UI-side AI agent integration.admin_runner/globalsecrets.propertiescontrols runner-side secrets (including GenAI keys).
Launch
Once the environment files are set, compose/compose.yaml can be used to launch the services.
Validate that it’s healthy
After containers start, validate:
Admin UI is reachable in a browser.
Admin backend services are up (check container logs if the UI cannot load).
MongoDB is running.
If something fails fast, start with docker compose logs -f and check for missing env vars or blocked network access.
Basic operations (day 2)
Common patterns (exact commands depend on the compose setup in the repo):
Stop: bring down the stack when you don’t need it.
Upgrade: bump
RIERINO_VERSION, then restart the affected services.Toggle components: use compose profiles/services to run a smaller footprint.
Treat this VM like a dev/test environment. Use separate credentials and non-production secrets where possible.
The sandbox assets can be found at the sandbox repository with "composite/README.MD" file for more details on launch and administration commands.
Last updated