Xtreme1: A Docker Compose Stack for 3D LiDAR, Image and RLHF Annotation
Xtreme1 is an all-in-one data labeling and annotation platform for multimodal data training and supports 3D LiDAR point cloud, image, and LLM.
At a glance
- What is it?
- Xtreme1 bundles a labeling UI, MySQL, Redis, MinIO and optional GPU pre-labeling models into one Docker Compose deployment. It is a sensible fit for teams annotating LiDAR-camera fusion data on their own hardware, and a poor fit for anyone who needs a managed service or a fully documented API.
- Who is it for?
- Adopt Xtreme1 if you have Linux hosts with NVIDIA GPUs, a need to keep LiDAR and image data on your own infrastructure, and the appetite to read the docs site rather than the README for feature detail. Do not adopt it if you are on an ARM laptop without accepting QEMU emulation for MySQL, or if you need a stable programmatic API, since the README documents only installation.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Xtreme1 fills: one tool for point clouds, images and preference data
Most annotation tools pick a lane. Label Studio and CVAT started with images and added video. 3D tools such as SUSTechPOINTS handle point clouds but not RLHF. Xtreme1's claim is that a single platform covers 2D bounding boxes and segmentation, 3D LiDAR annotation, LiDAR-camera fusion, and, in beta, RLHF annotation for large language models. The README lists these as separate feature bullets, and the screenshots in the repository show an image annotation view and a 3D fusion view side by side.
The audience is narrow but real. If you are training a perception model on nuScenes-style data and you also need to collect human preference rankings for a language model, running two annotation stacks means two sets of credentials, two storage backends and two export formats. Xtreme1's pitch is that both live in one deployment. The topics list on the repository (lidar-camera-fusion, point-cloud, rlhf) is consistent with that positioning.
What the README does not do is explain the labeling workflow itself. It says plainly that the document covers installation, building and running, and that questions about features belong on the docs site. Treat the repository as a deployment artifact, not a manual.
Architecture: Compose services, MySQL, Redis, MinIO and a profile-gated model tier
The deployment is a Docker Compose application. The README names five service images pulled from Docker Hub: MySQL, Redis and MinIO as backing services, plus backend and frontend as the application. The frontend is served on port 8190. MinIO's console is exposed at 8194, and the README notes that credentials and host-bound ports for MySQL, Redis and MinIO are readable in docker-compose.yml.
Persistence is handled with Docker volumes. The README states that data survives container recreation, and that docker compose down removes containers while keeping volumes, whereas docker compose down -v deletes the volumes and with them all MySQL, Redis and MinIO data. That distinction matters operationally: the difference between a restart and a wipe is one flag.
The built-in pre-labeling models are a separate tier, enabled with a Compose profile rather than started by default. The README shows docker compose --profile model up and lists the underlying model projects: YOLOR and RITM for image bounding boxes and interactive segmentation, OpenPCDet and AB3DMOT for LiDAR-camera fusion, and MobileNetV3 with openTSNE for image data curation. Those models run as their own containers and are the only part of the stack that needs a GPU.
Getting it running: two commands and one profile flag
The install path documented in the README is short. Download and unzip the release package, then start the stack:
wget https://github.com/xtreme1-io/xtreme1/releases/download/v0.9.1/xtreme1-v0.9.1.zip unzip -d xtreme1-v0.9.1 xtreme1-v0.9.1.zip cd xtreme1-v0.9.1 docker compose up
Then open http://localhost:8190. The README recommends Chrome and notes that localhost can be replaced with an IP address for remote access. First startup takes a few minutes because the database is initialized and a test dataset is prepared.
Enabling the pre-labeling models is a second command: docker compose --profile model up. This is where the constraints bite. Model containers run only on a Linux server with an NVIDIA CUDA driver and the NVIDIA Container Toolkit installed. The README gives the required daemon.json fragment, setting default-runtime to nvidia with the nvidia runtime path, and notes that Docker must be restarted afterward. The hardware floor for the model tier is an NVIDIA T4 or similar GPU with 4GB of RAM. The base platform is lighter: 2GB RAM and 10GB of free disk, on AMD64 or ARM64, with Docker Desktop 4.1+ on desktop systems or Docker Engine 20.10+ with the Compose plugin 2.0+ on a Linux server.
Where the deployment fights back: ARM, GPU drivers and a thin README
Three concrete limitations are visible in the material. The first is ARM. The README warns that some images, MySQL named explicitly, may not be compatible with ARM64. The suggested workaround is a docker-compose.override.yml that pins the mysql service to platform: linux/amd64, which the README says uses QEMU emulation and may impact performance. That is a workaround, not a fix, and it applies to the database at the center of the stack.
The second is the GPU path. Pre-labeling is the feature that distinguishes Xtreme1 from a plain labeling UI, and it is exactly the feature that will not start on a Mac or Windows desktop. The README points Docker Desktop plus WSL2 users to issue #144 rather than offering a supported configuration. If your team develops on laptops and deploys on Linux, expect the interactive model features to be unavailable in local development.
The third is documentation depth. The README states that it only covers installation, building and running, and defers feature questions to docs.xtreme1.io. Nothing in the supplied material describes an HTTP API, an export format, or a Python SDK. For a platform whose output feeds a training pipeline, that is the gap I would probe first. The repository also shows a gap between releases: v0.9.1 landed in April 2024, and the most recent push to main is dated June 2026, so the release cadence and the commit cadence are not the same thing.
How it differs from Label Studio and CVAT
The honest comparison is with Label Studio and CVAT, both of which are open source, self-hostable and widely used for image annotation. The difference is scope and packaging. CVAT is built around video and image annotation with a server plus workers architecture, and its 3D support arrives through separate tooling. Label Studio is a general-purpose labeling frontend with a large template library and a documented API for importing tasks and exporting annotations.
Xtreme1's differentiator is that 3D LiDAR, LiDAR-camera fusion and RLHF are first-class in the same product, and that the pre-labeling models ship as containers you enable with a Compose profile instead of integrating yourself. The trade is maturity and extensibility. Label Studio's API and webhook surface is the kind of thing you build a data pipeline against; Xtreme1's README does not describe one. If your requirement is a scriptable labeling backend for images alone, Label Studio is the lower-risk choice. If your requirement is one deployment that handles point clouds and images together, Xtreme1 is aimed squarely at that, and the built-in OpenPCDet and AB3DMOT integration is the reason.
Maintenance cost, licensing and what to check before you commit
The licence is Apache-2.0, which permits commercial use and modification, and the README links to a separate enterprise offering from Basic.ai. I am not a lawyer and this is not legal advice; if you plan to redistribute a modified build, read the licence text and the enterprise terms yourself.
Upgrade cost is dominated by the Compose file rather than the code. Because MySQL, Redis and MinIO are pinned images with named volumes, an upgrade means pulling new backend and frontend images and checking whether the schema migration runs on start. The README does not describe a migration command or a backup procedure, so the safe sequence is a volume snapshot before docker compose down and a fresh docker compose up. The docker compose down -v path is destructive by design and should never appear in a runbook for a production instance.
Two things to verify on your own hardware before rollout. First, whether docker compose --profile model starts cleanly with your CUDA driver and Container Toolkit versions, since the README specifies the daemon.json configuration but not a tested driver matrix. Second, whether the Ontology Center's class hierarchies and attributes can express the label schema your model was trained against, because the README describes the ontology as configurable without showing the schema. If either check fails, the fallback is the base platform without models, which is a competent multimodal labeling UI but not the product the feature list advertises.
Editorial conclusion
Adopt Xtreme1 if you have Linux hosts with NVIDIA GPUs, a need to keep LiDAR and image data on your own infrastructure, and the appetite to read the docs site rather than the README for feature detail. Do not adopt it if you are on an ARM laptop without accepting QEMU emulation for MySQL, or if you need a stable programmatic API, since the README documents only installation. Before committing, verify two things on a staging box: that docker compose --profile model brings up the model services with your driver version, and that the ontology hierarchy in the Ontology Center matches the class structure your training pipeline expects.
Community notes