Xtreme1 ships its database passwords in docker-compose.yml

Four credentials sit in plain text in the compose file

The MySQL service declares `MYSQL_ROOT_PASSWORD: ImOxO8Lz`, creates the `xtreme1` database, and gives the `xtreme1` user the password `Rc4K3L6f`. The MinIO service declares `MINIO_ROOT_USER: admin` with `MINIO_ROOT_PASSWORD: 1tQB970y` and pre-creates the bucket pair `xtreme1:download`. Redis has no password at all in the compose file. Those values are not confined to the file: the MySQL healthcheck runs `/usr/bin/mysql --user=xtreme1 --password=Rc4K3L6f --execute "SHOW DATABASES;"` every ten seconds, and the upgrade section of the page repeats the same account and password in its backup and restore commands. A default that appears in four places in the repository is a default that has to be replaced in four places, and it is worth doing that before the stack is reachable by anything other than the host itself.

The data services are published on host ports, and the page suggests an IP address

nginx publishes `8190:80`, MySQL publishes `8191:3306`, Redis publishes `8192:6379`, and MinIO publishes `8193:9000` plus `8194:9001` for its console. None of those mappings is bound to the loopback interface, so a compose stack started with the documented command exposes the database, the cache and the object store on every address the host has. The page then tells you what to do with that: visit `http://localhost:8190`, and you can replace localhost with an IP address if you want to access from another machine. Read together with the fixed passwords, that sentence describes a database reachable from the network with a password published in the repository. Nothing here needs exploiting to matter; the fix is to change the passwords and narrow the published ports before the stack leaves the machine. Startup order is enforced from the compose file as well: nginx declares `depends_on` backend with `condition: service_healthy`, so the entry point holds back until the backend passes its own healthcheck, and MySQL and Redis carry healthchecks of their own.

A failed migration stops the backend on purpose, and recovery is by hand

Migrations run when the backend starts, and the page is explicit about the failure mode: a migration that fails leaves the database where it stopped, and the backend then serves nothing rather than serve on a half-migrated schema. The log is meant to be enough to act on, naming the version it is on, the script that failed and the statement that failed, and the recovery steps live in `backend/src/main/resources/db/migration/README.md`. Back up first, from the directory of the version you are currently running:

# From the directory of the version you are currently running.
docker compose exec -T mysql mysqldump -uxtreme1 -pRc4K3L6f --databases xtreme1 > xtreme1-backup.sql
docker compose down

# Then, from the new release package directory.
docker compose up -d

The restore is the same command pointed the other way, `docker compose exec -T mysql mysql -uxtreme1 -pRc4K3L6f < xtreme1-backup.sql`. Note also that `./deploy/mysql/migration` is mounted into the MySQL container's `/docker-entrypoint-initdb.d`, so first-boot SQL and later migrations arrive through two different mechanisms.

name: xtreme1 is pinned so a new release directory keeps the old volumes

The first line of the compose file is `name: xtreme1`, and the comment above it explains why. Without a pinned name, Compose derives the project name from the directory, and since the page tells you to unzip each release into a directory named after that release, every upgrade would land on a fresh empty set of volumes. The comment also covers the collision case: a second installation on the same host needs its own name given as `docker compose -p <name>`, or it drives the containers and volumes of the first installation. That is exactly what the download section warns about, since following the fresh install steps on a host that already runs an earlier version starts an empty installation beside the existing one and leaves the old data behind.

MinIO comes from a namespace called bitnamilegacy, and the mount path follows from it

The object store service pulls `bitnamilegacy/minio:2025.7.23-debian-12-r5`, and its volume is mounted at `/bitnami/minio/`. The comment on that line explains the path: the bitnami MinIO image serves `/bitnami/minio/data`, while older 2022.x images used `/data`. A compose file written against the older layout would therefore mount an empty directory here and quietly persist nothing. The rest of the file pins its images by exact tag as well, `nginx:1.22`, `mysql:5.7` and `redis:6.2`, and MySQL gets a custom config file plus the migration directory mounted alongside its data volume. Pinning is the right default here, but the tags are old enough that an upgrade path depends on reading these lines rather than assuming current images.

The base stack asks for 2GB of RAM; the model profile asks for a Linux GPU host

The prerequisites split into two tiers that share almost nothing. The platform itself wants an AMD64 or ARM64 CPU, 2GB of RAM or higher and 10GB of free disk, with Docker Desktop 4.1 or newer on a desktop, or Docker Engine 20.10 with the Compose plugin 2.0 or newer on a Linux server. The built-in model containers are Linux server only, and need an NVIDIA T4 or similar GPU with 4G of RAM or higher plus the NVIDIA CUDA Driver and the NVIDIA Container Toolkit. They stay off until you ask for them by profile:

docker compose --profile model up

Enabling the toolkit means setting the container runtime as the daemon default:

{
  "runtimes": {
    "nvidia": {
      "path": "nvidia-container-runtime",
      "runtimeArgs": []
    }
  },
  "default-runtime": "nvidia"
}

That change applies to every container on the host, not only this stack, and users on Docker Desktop with WSL2 are pointed at issue #144 for their own path. A Mac user can run the labeling platform and cannot run the pre-labeling models that come with it.

The release line skipped two years, and the download command is pinned to v0.9.3

The recorded releases are v0.9.3 on 2026-09-28, v0.9.2 on 2026-09-15, and v0.9.1 on 2024-04-23, so the gap between the first two is a little over two years before the recent pair. The last push to the repository is dated 2026-09-29. The download step on the page hardcodes the current version rather than resolving a latest pointer:

wget https://github.com/xtreme1-io/xtreme1/releases/download/v0.9.3/xtreme1-v0.9.3.zip
unzip -d xtreme1-v0.9.3 xtreme1-v0.9.3.zip

So the page is a snapshot of one release, and following it verbatim after a newer tag exists installs the older package. The page also draws its own boundary, saying it covers installation, building and running and sending feature questions to a separate docs site, with the commercial enterprise version reached through a demo request on basic.ai.

down -v is the one command the page marks as dangerous, and files live outside the database

The advanced command list keeps the volumes by default and names exactly one command as destructive:

# Stop all services and delete all containers, but data volumes will be kept.
docker compose down

# Danger! Delete all volumes. All data in MySQL, Redis and MinIO.
docker compose down -v

The rest of the page leans on volumes for persistence, stating that data survives container recreation. What the backup recipe does not cover is the other half of the storage: file storage is not in the database, and MinIO holds the buckets, including the pre-created `xtreme1:download`. A mysqldump taken before an upgrade restores the schema and the rows, not the uploaded media, so an upgrade plan needs a MinIO side copy as well. The first start is not instant either, since the page says it takes a few minutes to initialize the database and prepare a test dataset, and it recommends Google Chrome for the interface at port 8190.

Editorial conclusion

The stack is coherent and the failure modes are documented well: the backend refuses to serve a half-migrated schema, the project name is pinned so a new release directory reuses old volumes, and the page marks `docker compose down -v` as the one destructive command. What has to be handled before this goes anywhere shared is the security surface, because the credentials live in the repository, the data ports are published on the host, and the page itself suggests swapping localhost for an IP address. Two further checks matter for planning: a mysqldump of MySQL does not cover the files in MinIO, and the built-in pre-labeling models will not run without a Linux GPU host. Treat the shipped defaults as a starting point to replace, not as a configuration to keep.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. xtreme1-io/xtreme1 on GitHub