chore: replace MinIO with RustFS in docker-compose deployments#8820
chore: replace MinIO with RustFS in docker-compose deployments#8820Rasaboun wants to merge 3 commits intomakeplane:previewfrom
Conversation
MinIO's community edition entered maintenance mode (Dec 2025) and is no longer actively maintained. Replace with RustFS, an S3-compatible Apache 2.0 alternative that uses the same port 9000. This change targets new deployments only. The service name `plane-minio` is kept for backward compatibility with the Caddyfile, install.sh, and backup scripts. Existing deployments should not upgrade in-place without migrating their storage data first. Closes makeplane#8774
📝 WalkthroughWalkthroughReplace MinIO with RustFS as the bundled S3-compatible object storage in compose deployments; update environment examples and comments to reference RustFS/bundled storage and adjust backup/install scripts to use Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
Replaces the MinIO container used in docker-compose-based deployments with RustFS as the bundled S3-compatible storage service.
Changes:
- Swap
minio/minioimages forrustfs/rustfs:1.0.0-alpha.90in the selfhost and CLI community compose files. - Update storage container environment variables and data volume mount path (
/export→/data) accordingly. - Refresh
.env.examplecomments to refer to “bundled storage” / RustFS instead of MinIO.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
docker-compose.yml |
Replaces MinIO service image/config with RustFS for bundled S3 storage. |
deployments/cli/community/docker-compose.yml |
Updates the CLI community deployment to run RustFS and inject new storage env vars. |
apps/api/.env.example |
Comment-only updates to reflect bundled storage wording. |
.env.example |
Comment-only updates to reflect bundled storage wording. |
| plane-minio: | ||
| container_name: plane-minio | ||
| image: minio/minio | ||
| image: rustfs/rustfs:1.0.0-alpha.90 |
There was a problem hiding this comment.
The storage service now uses an alpha/pre-release image tag (rustfs/rustfs:1.0.0-alpha.90). For deployment reproducibility and risk reduction, prefer a stable release, or at least pin the image by digest so upgrades are explicit and supply-chain risk is reduced.
| image: rustfs/rustfs:1.0.0-alpha.90 | |
| image: rustfs/rustfs:1.0.0-alpha.90@sha256:1111111111111111111111111111111111111111111111111111111111111111 |
| plane-minio: | ||
| image: minio/minio:latest | ||
| command: server /export --console-address ":9090" | ||
| image: rustfs/rustfs:1.0.0-alpha.90 |
There was a problem hiding this comment.
The storage service now uses an alpha/pre-release image tag (rustfs/rustfs:1.0.0-alpha.90). For deployment reproducibility and risk reduction, prefer a stable release, or at least pin the image by digest so upgrades are explicit and supply-chain risk is reduced.
| image: rustfs/rustfs:1.0.0-alpha.90 | |
| image: rustfs/rustfs:1.0.0 |
| environment: | ||
| <<: *minio-env | ||
| <<: *storage-env | ||
| volumes: | ||
| - uploads:/export | ||
| - uploads:/data |
There was a problem hiding this comment.
The RustFS volume mount was changed from /export to /data, but the community installer/backup script still backs up plane-minio from /export (deployments/cli/community/install.sh:600). This breaks backups and contradicts the stated backward-compatibility intent—either keep the mount at /export (and set RUSTFS_VOLUMES accordingly) or update the backup script to use /data in the same PR.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
deployments/cli/community/docker-compose.yml (1)
118-118: Consider removing*storage-envfrom application services.The
api,worker,beat-worker, andmigratorservices include*storage-envin their environment merge, but these services don't readRUSTFS_*variables—they useAWS_*variables from*aws-s3-env(as shown instorage.py,export_task.py, andcreate_bucket.py). Only theplane-minioservice needs*storage-env.This doesn't break functionality but adds unnecessary environment variables to these containers.
🧹 Suggested cleanup for api service (apply similarly to worker, beat-worker, migrator)
environment: - <<: [*app-env, *db-env, *redis-env, *storage-env, *aws-s3-env, *proxy-env] + <<: [*app-env, *db-env, *redis-env, *aws-s3-env, *proxy-env]Also applies to: 134-134, 151-151, 168-168
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@deployments/cli/community/docker-compose.yml` at line 118, The docker-compose services api, worker, beat-worker and migrator are merging in the *storage-env (RUSTFS_*) variables even though their code (storage.py, export_task.py, create_bucket.py) uses AWS_* vars from *aws-s3-env; remove *storage-env from the environment merge for the api, worker, beat-worker and migrator services and leave *storage-env only on the plane-minio service so containers don’t receive unnecessary RUSTFS_* variables.apps/api/.env.example (1)
44-46: Minor: Remove extra blank lines.Static analysis detected consecutive blank lines at lines 45-46, which can be cleaned up for consistency.
🧹 Suggested fix
# set to 1 if using the pre-configured S3-compatible storage (RustFS) USE_MINIO=0 - - # Email redirections and storage domain settings🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/api/.env.example` around lines 44 - 46, Remove the consecutive blank lines found in the .env example file so there are no multiple adjacent empty lines—leave at most a single newline separator and ensure the file ends with a single trailing newline (i.e., collapse the extra blank lines into one and remove the extra empty lines at the end).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@deployments/cli/community/docker-compose.yml`:
- Line 208: The docker-compose service currently pins the container image to the
unstable tag "rustfs/rustfs:1.0.0-alpha.90"; update the image reference used in
this compose file (the line specifying image: rustfs/rustfs:1.0.0-alpha.90) to
the stable release tag once available (e.g., replace with the stable semver tag
or :latest per your release policy) and ensure you apply the same change to the
main docker-compose.yml so both deployments use the identical, non-alpha image
tag.
In `@docker-compose.yml`:
- Line 145: The docker-compose uses an alpha RustFS image ("image:
rustfs/rustfs:1.0.0-alpha.90"), which is not production-ready; update the
deployment to either point to an approved stable image or gate this alpha image
behind an explicit approval/config flag and documentation; specifically change
the image reference or add a conditional/environment flag and ensure you add
deployment notes documenting the alpha status, limitations, monitoring/rollback
procedures, and a migration plan for when a stable rustfs release is available
so operators must explicitly opt-in before using rustfs/rustfs:1.0.0-alpha.90.
---
Nitpick comments:
In `@apps/api/.env.example`:
- Around line 44-46: Remove the consecutive blank lines found in the .env
example file so there are no multiple adjacent empty lines—leave at most a
single newline separator and ensure the file ends with a single trailing newline
(i.e., collapse the extra blank lines into one and remove the extra empty lines
at the end).
In `@deployments/cli/community/docker-compose.yml`:
- Line 118: The docker-compose services api, worker, beat-worker and migrator
are merging in the *storage-env (RUSTFS_*) variables even though their code
(storage.py, export_task.py, create_bucket.py) uses AWS_* vars from *aws-s3-env;
remove *storage-env from the environment merge for the api, worker, beat-worker
and migrator services and leave *storage-env only on the plane-minio service so
containers don’t receive unnecessary RUSTFS_* variables.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 79cf3b88-ad8f-40de-bbac-7aae9e2a5f89
📒 Files selected for processing (4)
.env.exampleapps/api/.env.exampledeployments/cli/community/docker-compose.ymldocker-compose.yml
| plane-minio: | ||
| image: minio/minio:latest | ||
| command: server /export --console-address ":9090" | ||
| image: rustfs/rustfs:1.0.0-alpha.90 |
There was a problem hiding this comment.
Same alpha version concern applies here.
As noted in the main docker-compose.yml, using rustfs/rustfs:1.0.0-alpha.90 in a production deployment configuration carries stability risks. Ensure both compose files are updated together when a stable release becomes available.
🧰 Tools
🪛 Checkov (3.2.510)
[medium] 207-208: Basic Auth Credentials
(CKV_SECRET_4)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@deployments/cli/community/docker-compose.yml` at line 208, The docker-compose
service currently pins the container image to the unstable tag
"rustfs/rustfs:1.0.0-alpha.90"; update the image reference used in this compose
file (the line specifying image: rustfs/rustfs:1.0.0-alpha.90) to the stable
release tag once available (e.g., replace with the stable semver tag or :latest
per your release policy) and ensure you apply the same change to the main
docker-compose.yml so both deployments use the identical, non-alpha image tag.
| plane-minio: | ||
| container_name: plane-minio | ||
| image: minio/minio | ||
| image: rustfs/rustfs:1.0.0-alpha.90 |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What is the latest stable version of RustFS and is 1.0.0-alpha.90 production-ready?
💡 Result:
The latest stable version of RustFS does not exist; all releases are pre-releases labeled as 1.0.0-alpha.xx. The most recent release is 1.0.0-alpha.90, released on March 24, 2026. 1.0.0-alpha.90 is not production-ready. It is explicitly marked as a pre-release on GitHub, the official download pages, and distribution sites. Official documentation provides production deployment guides and hardware checklists, but the alpha status, ongoing focus on stability/bug fixes per the roadmap (no new features until GA), and absence of a stable 1.0 release indicate it remains in development. The project emphasizes rigorous multi-node stress testing before GA, with no timeline provided as of early 2026.
Citations:
- 1: https://github.com/rustfs/rustfs/releases
- 2: https://rustfs.com/download/
- 3: https://dl.rustfs.com/rustfs/
- 4: https://github.com/rustfs/rustfs
- 5: http://docs.rustfs.com/installation/checklists/software-checklists.html
- 6: https://docs.rustfs.com/installation/
- 7: https://docs.rustfs.com/upgrade-scale/availability-and-resiliency.html
- 8: https://docs.rustfs.com/installation/checklists/hardware-checklists.html
- 9: RustFS Roadmap Update: Focusing on Stability and the Road to GA 🚀 rustfs/rustfs#1097
Alpha release in production configuration requires explicit approval.
rustfs/rustfs:1.0.0-alpha.90 is the only available RustFS release and is explicitly not production-ready. The project offers production deployment guides but the software remains in alpha development with no stable 1.0 release or GA timeline as of March 2026.
Using non-production-ready software in a production/staging configuration (per coding guidelines) introduces stability and compatibility risks. Before deploying:
- Document the alpha status and known limitations for the deployment
- Establish monitoring and rollback procedures
- Plan a migration path when stable releases become available
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docker-compose.yml` at line 145, The docker-compose uses an alpha RustFS
image ("image: rustfs/rustfs:1.0.0-alpha.90"), which is not production-ready;
update the deployment to either point to an approved stable image or gate this
alpha image behind an explicit approval/config flag and documentation;
specifically change the image reference or add a conditional/environment flag
and ensure you add deployment notes documenting the alpha status, limitations,
monitoring/rollback procedures, and a migration plan for when a stable rustfs
release is available so operators must explicitly opt-in before using
rustfs/rustfs:1.0.0-alpha.90.
|
|
- Remove *storage-env from backend services (they only need *aws-s3-env) - Update backup script path /export → /data to match new volume mount
|
RustFS only has alpha releases right now (1.0.0-alpha.90 is the latest) so there's no stable tag to pin to This is the most actively developed S3-compatible alternative with Apache 2.0 licensing, the other options are either AGPL (Garage) or heavier than what Plane needs (SeaweedFS/Ceph) I pinned to the specific alpha tag rather than 'latest' so upgrades are explicit and I'll update the tag when a stable release drops |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
deployments/cli/community/docker-compose.yml (1)
206-216: Consider adding a healthcheck for service readiness.The
plane-minioservice lacks a healthcheck. Dependent services (api, worker, etc.) may attempt to connect before RustFS is ready to accept requests. While Docker'sdepends_onensures container start order, it doesn't guarantee the service inside is ready.♻️ Optional: Add a healthcheck
# Comment this if you using any external s3 compatible storage plane-minio: image: rustfs/rustfs:1.0.0-alpha.90 deploy: replicas: 1 restart_policy: condition: any environment: <<: *storage-env volumes: - uploads:/data + healthcheck: + test: ["CMD", "curl", "-f", "http://localhost:9000/minio/health/live"] + interval: 30s + timeout: 10s + retries: 3 + start_period: 10sNote: Verify the healthcheck endpoint path is correct for RustFS—it may differ from MinIO's
/minio/health/live.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@deployments/cli/community/docker-compose.yml` around lines 206 - 216, Add a Docker healthcheck to the plane-minio service (the rustfs/rustfs image block) so dependent services don't attempt connections before RustFS is ready; update the plane-minio service stanza to include a healthcheck that periodically curls the correct readiness endpoint (verify the RustFS health path, e.g. replace /minio/health/live with the actual RustFS endpoint) with sensible interval, timeout and retries so Docker marks the container healthy only when it can accept requests.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@deployments/cli/community/docker-compose.yml`:
- Around line 206-216: Add a Docker healthcheck to the plane-minio service (the
rustfs/rustfs image block) so dependent services don't attempt connections
before RustFS is ready; update the plane-minio service stanza to include a
healthcheck that periodically curls the correct readiness endpoint (verify the
RustFS health path, e.g. replace /minio/health/live with the actual RustFS
endpoint) with sensible interval, timeout and retries so Docker marks the
container healthy only when it can accept requests.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: e107d87a-a633-4faf-b188-018b8b490a8d
📒 Files selected for processing (2)
deployments/cli/community/docker-compose.ymldeployments/cli/community/install.sh
- Add inline comments warning that RustFS uses a different on-disk format than MinIO (existing deployments must migrate data first) - Document that the admin console moved from port 9090 to 9001 - Add healthcheck using RustFS's /health endpoint
Closes #8774
Summary
MinIO's community edition is no longer maintained admin UI stripped Docker images discontinued and the GitHub repo is in maintenance mode since Feb 13 2026
This replaces "minio/minio" with RustFS (
rustfs/rustfs:1.0.0-alpha.90) an S3-compatible drop-in alternative licensed under Apache 2.0What changed
docker-compose.ymlanddeployments/cli/community/docker-compose.yml: swapped the image, updated env vars (MINIO_ROOT_USER→RUSTFS_ACCESS_KEY), changed volume mount (/export→/data), removed the MinIOcommand, added healthcheck (/healthendpoint), added migration warning commentsdeployments/cli/community/install.sh: updated backup path from/exportto/datato match the new RustFS volume mount.env.exampleandapps/api/.env.example: updated comments only--console-address ":9090", RustFS serves its built-in console on port 9001 by default (this port was never published in the compose files, only accessible inside the Docker network or via manual port forwarding)What was intentionally NOT changed
plane-minio: kept for backward compatibility withCaddyfile.ce,install.sh,swarm.sh, and backup scriptsUSE_MINIO/MINIO_ENDPOINT_SSLenv vars: consumed by the Python backend (storage.py), renaming would require code changesboto3(standard S3 SDK), works with any S3-compatible storage as-isUSE_MINIO=0with external S3, doesn't include the storage containerdocker-compose-local.yml(local dev): still usesminio/miniowith themcbucket-init entrypoint — updating the local dev setup is left for a separate PRScope
This targets new deployments only. Existing deployments should not upgrade in-place without migrating storage data first (MinIO and RustFS use different on-disk formats). A migration guide or script could be added in a follow-up.
Longer-term suggestion
The storage layer could be made fully S3-agnostic by renaming
USE_MINIO→USE_LOCAL_S3and removing product-specific naming throughoutThis PR intentionally avoids that scope to keep things minimal and reviewable