JmalCloud: A Self-Hosted Netdisk Split Across Two Repositories

What JmalCloud Solves, and Who It Is Built For

The README describes JmalCloud as a private cloud storage netdisk project for managing files in the cloud. Read past the marketing and the concrete problem is narrower: you have files you want to reach from a browser and from WebDAV clients, you do not want them sitting on a third-party consumer service, and you already have object storage somewhere. The project's stated storage targets are OSS, Alibaba Cloud OSS, Tencent Cloud OSS and MinIO. That list is the tell. JmalCloud is aimed at someone who has an S3-compatible bucket and wants a file manager, preview layer and WebDAV endpoint on top of it, not at someone who wants to run a bare filesystem server.

The audience follows from that. A homelab operator with MinIO running already is a natural fit. A small team that wants shared document editing without a SaaS subscription is a plausible fit, since the README lists online editing and preview for Word, Excel, PPT, flowcharts and mind maps. A single user who just wants a folder synced between two laptops is a poor fit, because the deployment is a multi-container stack and the metadata lives in MongoDB rather than in the files themselves.

One thing the README does not give you is a statement of scale. There is no guidance on how many users or how much data the design targets. Treat the absence as a signal that you are expected to size it yourself.

Two Repositories, One Product: The Architecture You Actually Get

The most consequential fact about this project is buried in the deployment instructions rather than stated as a design decision. jmal-cloud-view is the web client. The server is a separate repository, jmal-cloud-server, which the README links to for the docker-compose file. The development section makes the split explicit: clone the server project, edit src/main/resources/file.yml, then clone the web project and run npm install and npm run dev.

So the runtime picture is a Vue front end served through nginx, a Java service (the dev prerequisites list jdk17+), and a MongoDB instance holding metadata. The container names in the operational commands confirm the shape: jmalcloud_server, jmalcloud_mongodb. File bytes go to whichever object storage backend you configure, which is why the storage list matters more than the language breakdown.

The practical consequence is that "JmalCloud" is not one artifact. If you are evaluating it, you are evaluating a client and a server that version separately. The release feed you see on jmal-cloud-view (v2.16.9, v2.16.8, v2.16.7) tells you about the front end only. Nothing in the supplied material tells you how the server repository's tags line up with these, and that is a real gap for anyone planning upgrades.

Running It: Docker Compose, Port 7070, and the Config Files That Matter

The README requires Docker and Docker Compose v2.0 or later and points at docker-compose.base.yml in the server repository. The documented start command is a single line:

docker compose up -d

After startup the README says to visit http://{your_ip}:7070. That port is the only documented entry point.

For a source build, the prerequisites are jdk17+, mongodb4.4+ and node v16.x.x. The server clone is git clone https://github.com/jamebal/jmal-cloud-server.git. Then you edit src/main/resources/file.yml and change two parameters: rootDir and ip2region-db-path, both to your own directories. The README states that after that change the service can start. The web side is git clone https://github.com/jamebal/jmal-cloud-view.git, then npm install, then npm run dev.

Two operational commands are documented. To reset the administrator password, you exec into jmalcloud_mongodb and run an update against the user collection filtering on creator: true, setting a fixed password hash, then restart jmalcloud_server. The README states the resulting password is jmalcloud. To back up, docker exec -it jmalcloud_mongodb mongodump -d jmalcloud -o /dump/xxx --gzip --quiet. To restore, docker exec -it jmalcloud_mongodb mongorestore --gzip --nsInclude=jmalcloud.* --dir /dump/xxx --quiet.

Note what the backup covers: MongoDB only. The README gives no procedure for backing up the object storage bucket, which is where the actual file content lives. That is a documentation gap worth planning around before you put data in.

Where JmalCloud Is the Wrong Tool

The admin password reset command is the clearest limitation in the supplied material, and it is a maintenance problem rather than a security one. It invokes mongo directly, the legacy shell. MongoDB 6.0 and later ship mongosh instead and drop the old binary, so the exact command in the README may not run on a current MongoDB image. The README's stated development prerequisite is mongodb4.4+, which is consistent with the command as written but also tells you the documented floor is an old release line. If you deploy on a newer MongoDB, plan on translating that command yourself.

The second limitation is the split repository. There is no single clone that gives you both halves at a matching version, and the supplied material contains no compatibility matrix. Upgrading the front end without knowing the server's corresponding tag is guesswork.

The third is the backup asymmetry already mentioned. mongodump captures the jmalcloud database. It does not capture your OSS, COS or MinIO bucket. If you treat the documented backup as complete disaster recovery, you will restore a catalog of files whose contents are gone.

Finally, the README leans on a hosted demo (username demo, password demo1234) rather than a documented API surface. There is no API reference in the material. If you need to integrate JmalCloud into another system programmatically, WebDAV is the documented integration point, and anything beyond that is unspecified.

How It Differs From Nextcloud and Seafile

The obvious comparison is Nextcloud, and the difference is where the bytes live. Nextcloud's classic deployment keeps file data on the server's own storage, with external storage as an add-on. JmalCloud inverts that: the README's storage list is object storage first, and the deployment is a thin service plus MongoDB metadata. If you already pay for a bucket and want the application server to stay stateless with respect to file content, that inversion is the reason to pick JmalCloud. If you want files on a local disk you control byte for byte, it is a reason to pick something else.

Seafile is the closer architectural cousin, since it also separates metadata from block storage and offers WebDAV and desktop sync. The supplied material does not describe JmalCloud's sync clients at all beyond WebDAV, so I cannot claim parity there. What the material does show is a heavier document-editing story: Word, Excel, PPT, flowchart and mind-map editing and preview are listed features, which puts JmalCloud nearer the collaborative-suite end than the pure-sync end.

A third reference point is a plain WebDAV server such as a minimal file daemon behind nginx. JmalCloud gives you a web UI, previews and document editing on top of that. The cost is MongoDB, a Java service and a Vue build. If all you want is WebDAV, the extra components are overhead you will maintain for no benefit.

Maintenance Cost and What the MIT Licence Actually Covers

The licence is MIT, Copyright (c) 2020-present jmal, and the repository is not archived. MIT is permissive: you can use, modify and redistribute the code, including commercially, provided the copyright notice and permission notice are retained. That is a statement about the licence text, not legal advice, and it covers the code in this repository only. It says nothing about the separate server repository, and it says nothing about any third-party components the deployment pulls in through Docker images, which carry their own terms. Check those separately.

Maintenance cost is dominated by the split. You are tracking two repositories, one of which (the server) is not the one you are reading about here. The release cadence visible on the view repository is roughly every two months across the three most recent tags, but the supplied material gives no equivalent cadence for the server, so you cannot assume they move together. Budget for reading both changelogs before any upgrade.

On the operations side, the recurring tasks the README supports are mongodump and mongorestore against the jmalcloud database. Everything else, including object-storage lifecycle rules, bucket versioning and the restore path for file bytes, is outside what the documentation covers. That is where your real maintenance hours will go.

A Concrete Way to Evaluate It Before You Commit

Because the README is thin on compatibility, the cheapest way to judge JmalCloud is to run the documented path exactly as written and see where it breaks. Bring up the stack with docker compose up -d from docker-compose.base.yml, reach port 7070, and confirm the admin password reset command runs against whatever MongoDB image the compose file pins. If it fails on mongo versus mongosh, you have learned the documentation lags the stack, which is useful information before you have data in it.

Then exercise the two features that distinguish it from a plain file server: upload something large enough to trigger the resume path the README advertises for very large files, and connect a WebDAV client. Those two paths are where a netdisk either works or does not, and neither is verifiable from the README alone.

Finally, take a mongodump, delete a file through the UI, restore the dump, and see whether the file returns. That single test tells you whether the documented backup is sufficient for your threat model or whether you also need bucket-level snapshots. The README does not answer that question. The test does.

Editorial conclusion

Adopt JmalCloud if you want a self-hosted netdisk whose file bytes live in an S3-compatible bucket rather than on the application server, and if you are comfortable that the codebase is split into jmal-cloud-view for the Vue front end and jmal-cloud-server for the Java service. Do not adopt it if you need a documented API contract, a stated release cadence, or a single repository you can clone and build. Before committing, verify three things yourself: that the docker-compose.base.yml in jmal-cloud-server matches your storage backend, that the file.yml rootDir and ip2region-db-path settings point at real writable paths, and that the admin password reset command still works against your MongoDB version, since it is written for the legacy mongo shell rather than mongosh.

Official sources

1. jamebal/jmal-cloud-view on GitHub
2. License: MIT
3. Project website
4. README
5. Releases