Moving from MinIO

VaultS3 speaks the same S3 API, so your applications keep working once they point at a new endpoint. The data moves over that API, with the migration wizard built into the dashboard: you run VaultS3 next to MinIO, copy the buckets across, check them, and switch.

VaultS3 cannot open a MinIO data directory directly: the two store objects on disk in different formats. Everything below copies through the S3 API, which is also why MinIO can keep serving until you switch.

What comes across, and what does not

Tools such as mc mirror or rclone sync also work, but they write each object as a new upload, so every object gets today's date, and bucket policies stay behind.

1. Run VaultS3 next to MinIO

Start it on another port. When MinIO runs on the same machine, Docker network or LAN, VaultS3 has to be allowed to read from a private address (Tailscale's 100.x addresses count as private too): the migration source is a URL typed into the dashboard, so by default it may only be a public one. That is what VAULTS3_ALLOW_PRIVATE_MIGRATION_SOURCES does (VaultS3 5.0.10 or later). It never opens the cloud metadata service, and you can remove it once the migration is done.

docker run -d --name vaults3 \
  -p 9010:9000 \
  -v vaults3-data:/data \
  -v vaults3-meta:/metadata \
  -e VAULTS3_ACCESS_KEY=vaults3-admin \
  -e VAULTS3_SECRET_KEY="$(openssl rand -hex 20)" \
  -e VAULTS3_ALLOW_PRIVATE_MIGRATION_SOURCES=true \
  eniz1806/vaults3:latest

Open http://localhost:9010/dashboard/ and sign in with that access key and secret. If MinIO and VaultS3 are both containers, put them on the same Docker network so VaultS3 can reach MinIO by its container name.

Settings you had in MinIO

The admin credentials are saved on the first start, so a changed secret in the environment is ignored later unless you also set VAULTS3_ADMIN_CREDENTIALS_OVERRIDE=true for one start. Every other setting is in the configuration reference.

2. Import the buckets

1. In the dashboard, open Migrate and pick the MinIO preset.
2. Enter MinIO's endpoint, for example http://minio:9000, and its access key and secret.
3. Click Test connection. It lists the source's buckets.
4. Pick the buckets and start. Progress is live, and a running job can be cancelled.

If the test answers that the source is at a private address, the setting from step 1 is missing. If it says the source refused the access key, check the key and secret. Redirects are not followed, so if MinIO sits behind a proxy that redirects http:// to https://, enter the https:// endpoint. If the migration stops, start it again with the same buckets: what is already there is skipped.

3. Recreate users and bucket settings

Create users, groups and policies on the IAM pages, and generate access keys for your applications. Then turn versioning, lifecycle rules, CORS and object lock back on for the buckets that used them, from the dashboard or with any S3 client. Object lock can only be enabled on a bucket before the objects you want protected are written to it, so set it up before you import a bucket that needs it.

4. Check, then switch

Compare object counts and sizes per bucket on both sides, for example with mc du or the dashboard's bucket view. Then point your applications at VaultS3. The client libraries are the same ones you used with MinIO:

# MinIO client
mc alias set vaults3 https://s3.example.com vaults3-admin <secret>

# AWS CLI
aws --endpoint-url https://s3.example.com s3 ls

# boto3
boto3.client("s3", endpoint_url="https://s3.example.com", ...)

Writes that reach MinIO after the import are not copied. Stop writes to MinIO before the final run, or run the migration once more just before switching. Keep MinIO until you are sure, then remove it.

Something different from MinIO

• Every x-amz-* header of a signed request must be signed, as on AWS. The AWS SDKs, the AWS CLI, mc, rclone and s3cmd already do this.
• Virtual-hosted URLs (bucket.s3.example.com) need VAULTS3_DOMAIN; path-style URLs work without it.
• Behind a reverse proxy, list the proxy in VAULTS3_TRUSTED_PROXIES so rate limits and audit logs see real client addresses.

Stuck on something? Open an issue with the output of vaults3 diagnose.