.env still has MINIO_ENDPOINT=minio:9000 and the old MinIO container is running, meeting-api
keeps writing new recordings to the old MinIO volume. Change .env before starting, as
shown below. Use the opt-in script to copy the old recordings.
Find your recordings
Default volume names (Compose projectvexa-v012):
Fresh installs use only the new storage. For upgraded Compose installs, change the endpoint in
.env as shown below: until then, an endpoint still pointing to a running MinIO continues to
use it. If that endpoint no longer answers, the storage readiness check prevents meeting-api
from starting. Lite’s normal startup does not inspect the old MinIO volume.
versitygw speaks S3 and keeps object metadata in extended attributes. Back up its volume with
an attribute-preserving copy (rsync -aX, cp -a). MinIO’s volume is not a directory of plain
S3 objects: copying its files directly into versitygw is not a migration.
The storage warning at start-up
Compose prints this line inmake up and make dev after the configured recording store
passes readiness, whenever its host or port differs from the bundled storage:
make up and make dev stop and print storage-init’s
STOP: line instead.
Lite prints this line at the end of up (also part of make lite) whenever .env has a
non-empty S3_ENDPOINT:
http://minio:9000 in Compose or an old MinIO address, your .env still points at the old MinIO
and new recordings are going there. Change .env as shown below and restart.
Copy the old recordings
The standalone tool isdeploy/storage/migrate-from-minio.sh, invoked by make migrate-storage
in either deployment directory. It uses the Python and boto3 in the deployment’s app image.
You need:
- The old MinIO volume and credentials, plus free disk space for a second copy.
- The old MinIO container, running or stopped, or a compatible MinIO server image already on the machine. Keep that image: the script never pulls one.
- The new release’s Lite or meeting-api image available locally (normal installation obtains it).
migration-from-minio/summary.json in the new
volume is its receipt.
Reruns copy source additions and changes when the target still matches the previous copy. They
preserve target edits and deletions, and report conflicts in changed_on_both_sides,
changed_in_target_after_copy, deleted_in_target_after_copy, and deleted_at_source_after_copy.
VERIFIED means every source key was verified or explicitly reported, with no verification
failures; it can include conflicts. Review the report and play old recordings before retiring MinIO.
Lite
From the repository root, after checking out the new release, clearS3_ENDPOINT in .env
if it points at the old MinIO (S3_ENDPOINT=). Then start and copy:
S3_ENDPOINT empty or absent, make lite starts vexa-lite-storage and the app on the
new storage. The copy reads through vexa-lite-minio if it is running. Otherwise it starts a temporary MinIO on the old volume
using the stopped container’s image, then removes the temporary container after the copy.
You can run the copy before switching the app, too; repeat it after switching to capture any
recordings the old app wrote between the first copy and the switch.
For non-default source settings, pass LEGACY_MINIO_CONTAINER, LEGACY_MINIO_VOLUME,
LEGACY_MINIO_ACCESS_KEY, LEGACY_MINIO_SECRET_KEY, or LEGACY_MINIO_BUCKET on the make command.
Target credentials and bucket use MINIO_ACCESS_KEY, MINIO_SECRET_KEY, and MINIO_BUCKET;
use the same overrides as your Lite startup.
Compose
From the repository root, after checking out the new release, update the old endpoint before starting. These edits work with both BSD and GNUsed; the original .env is kept for rollback:
MINIO_ENDPOINT=storage:9000. If the old value is quoted, includes a URL scheme or has
an inline comment, edit that line to this value manually. S3_ENDPOINT, when nonempty, takes
precedence: clear it to use MINIO_ENDPOINT, or keep it if you intend to use your own S3 store.
The bot edit applies only to the in-stack MinIO endpoint; keep an external bot store as configured.
Then run make up. With the bundled storage it prints no storage line. A [storage-init] WARNING:
line naming http://minio:9000 means the stack is still using the old MinIO; a [storage-init] STOP:
line means the configured store did not answer and meeting-api was not started.
docker compose -p vexa-v012 logs storage-init shows the whole check, which ends in
Ready: endpoint http://storage:9000 for the default stack.
Compose leaves the old MinIO container running as an orphan on make up; the copy reads through
it. The new storage publishes 127.0.0.1:18900, so it can run alongside MinIO’s port 9000.
storage-init checks the configured recording endpoint on bring-up: it ensures the bucket exists,
then writes, reads, compares and deletes a probe under .vexa-storage-init/. Any failure stops
meeting-api from starting and names the endpoint, bucket and failed step. The same check applies
to your own S3 endpoint; its credentials need these permissions.
If authenticated bots use a different bucket, also copy it:
MIGRATE_BUCKET sets both bucket defaults; LEGACY_MINIO_BUCKET can override the source.
With BOT_S3_ENDPOINT=http://storage:9000, storage-init provisions the configured bot account
and prefix policy. For custom Compose project names, pass PROJECT=<name> on every make command.
Source credentials default to .env’s MINIO_ACCESS_KEY / MINIO_SECRET_KEY; override them with
LEGACY_MINIO_ACCESS_KEY / LEGACY_MINIO_SECRET_KEY if the old store used different credentials.
If you copied before switching endpoints, repeat each copy after switching to catch late writes.
Check an old recording in your client or request its media:
If the old MinIO container or image is gone
If its container is gone, name a compatible image already listed bydocker image ls:
Stop the stack or retire MinIO
Never remove the old MinIO container or its volume until the script’s last run ends with VERIFIED. The script also copies recordings written to the old MinIO after the upgrade; switch endpoints and rerun it to capture those recordings before retiring MinIO. Composemake down removes containers (including orphans) and keeps data volumes. Lite
make -C deploy/lite down keeps data volumes too. Compose’s separate
make -C deploy/compose destroy DESTROY=yes deletes its current stack’s database, recordings,
Redis data and agent workspace volumes. It does not delete the old MinIO volume, which is no
longer declared in this release’s Compose file.
After checking the copy report and playback, you can remove the old containers explicitly:
Roll back to the previous release
Keep the old MinIO volume, its compatible image, and your previous configuration. Stop new recording activity and stop the current app with this release’s volume-preservingmake down
(Compose) or make -C deploy/lite down (Lite). Check out the previous release and start it
against the old volume, using the locally retained MinIO image. For Compose restore the previous
.env (including MINIO_ENDPOINT=minio:9000 and any old bot endpoint), then use
docker compose -p vexa-v012 up -d --no-build --pull never. For Lite restore the previous app
image tag and run make lite.
The previous release can read the recordings still in the old volume. Recordings created after
the switch exist only in the new volume unless you copy them back separately. Keep the new
storage volume too. Do not use an older release’s destructive shutdown command during rollback.