ZFile: a self-hosted cloud drive front end for S3, OneDrive and local storage

The problem ZFile solves: one interface over many storage backends

Files end up scattered. A photo archive sits in an S3 bucket, documents live in OneDrive, a media folder is on a NAS, and an old FTP server still holds something. Each backend has its own web console with its own navigation, preview behaviour and sharing model. ZFile's stated purpose is to put a single browser interface in front of all of them: the README describes it as an online drive program for individuals and small teams that manages multiple storage types so browsing, previewing and sharing become simpler.

The audience is narrow and specific. It is not a sync client and not a backup tool. It is for someone who already has storage somewhere and wants a presentable web view of it, with previews and share links, without writing that front end. The README lists S3, OneDrive, SharePoint, Google Drive, 多吉云, 又拍云, local storage, FTP and SFTP as supported sources. That list is the product. If your files live in one of those places and you want a browser over them, ZFile is aimed at you.

How ZFile works: a Spring Boot backend with a Vue front end

The repository topics name the stack directly: spring-boot, vue, mysql, h2. The top-level layout is a Maven project (pom.xml, src/) with a Dockerfile, so the backend is Java and the front end is a Vue application served by it. The two database options matter for deployment: H2 gives you an embedded file-backed database for a single-instance setup, while MySQL is the option for anything shared or longer-lived.

Functionally, ZFile sits between the browser and the storage source. The browser requests a directory listing, the backend authenticates against the configured storage source and returns the entries, and previews are rendered in the front end. The README lists image, audio, video, text, PDF, Office and OBJ (3D) preview as supported types. Sharing is a separate path: ZFile can generate direct links to files and short links, and the short links can carry an expiry. Multi-user support is scoped rather than global, since the README says storage sources or directories can be assigned to specific users. That per-user directory boundary is the feature that turns a personal drive into something a small team can share.

Installing ZFile and pointing it at your first storage source

The README's quick start is a one-line install script hosted on the documentation site. It downloads the script, marks it executable, and runs it:

curl -fsSL https://docs.zfile.vip/install.sh -o install.sh
chmod +x install.sh
./install.sh

The README points to the installation documentation at docs.zfile.vip/install for other methods. Docker and Docker Compose are both listed as supported, on AMD64 and ARM64. The repository's Dockerfile is explicitly a sample, not the build ZFile ships: its first comment states that the real packaging uses Graal Native and that this part is not open source. So treat the file as a reference for the runtime shape rather than a reproducible build of the released artifact. What it does show is the runtime contract: the container exposes port 8080 and starts the application with java -jar app.jar.

FROM ibm-semeru-runtimes:open-21-jre-jammy
WORKDIR /root
EXPOSE 8080
COPY --from=builder /root/target/*.jar /root/app.jar
CMD ["java", "-jar", "app.jar"]

After the service is up, the first real task is adding a storage source. The README's screenshots include an "add local storage" admin screen, and the admin area also covers storage source listing, user management and display settings. The practical sequence is: log in to the admin area, add a storage source, then assign it to a user or directory. The README does not walk through the field-level configuration of each source type; that lives in the documentation site.

Where ZFile stops: donation-edition features and the 5.x code split

Two capabilities in the README carry an explicit edition marker: rate-limited downloads and restricting which file types a given user may view or upload. Both are labelled as donation-edition features. If either is a requirement for you, the open repository as described is not the complete answer, and you should confirm the current state on the documentation site before planning around them.

The version note adds a second caveat. ZFile 5.x has been released, and the note says the open source edition and the donation edition have been merged into the same version, with donation-edition code to be separated out and open sourced into this repository later. That is a statement about intent, not a completed state. Anyone evaluating the licence or the feature boundary should read the note as describing work in progress.

A third boundary is platform. The related searches around ZFile include Android and APK terms, but the README describes a responsive web layout for phone, tablet and desktop. Nothing in the README describes a native mobile app. If a mobile client is the requirement, the browser is what you get.

ZFile compared with h5ai and with a cloud provider's own web console

The README's topic list includes h5ai, which names the closest point of comparison. h5ai is a PHP directory indexer: you drop it into a web-served directory and it renders a nicer listing of whatever the web server already exposes. ZFile's approach is different in kind. It is a Java service that talks to remote storage APIs, holds configuration and users in a database, and mediates access rather than exposing a directory tree. That means ZFile can front an S3 bucket or a OneDrive account that has no local filesystem path, which h5ai cannot do. The cost is operational: ZFile needs a JVM and a database, while h5ai needs a PHP-capable web server and a folder.

The other alternative is simply using the provider's console. OneDrive, Google Drive and S3 all have their own web interfaces. ZFile's difference is aggregation and control: one login across several providers, per-user directory scoping, and share links with expiry. If you only ever use one provider and its console is acceptable, ZFile adds a service to run without removing a service you already use.

Maintenance status, licence and upgrade cost

The repository is not archived, and the last push was on 2026-08-13, which is the same date as the 5.0.5 release. The release history shows 5.0.5 on 2026-08-13, 4.5.0 on 2025-11-12 and 4.4.0 on 2025-08-24. That is a slow cadence with a long gap between 4.5.0 and 5.0.5, and the 5.x line is the one the README says is still being split from the donation code. Plan for a project that moves in occasional larger steps rather than continuous small ones.

Upgrade cost follows from the stack. A Java service plus a database means schema changes and configuration drift are the things to watch between major versions, and the 4.x to 5.x transition is the one the README flags. Back up the database before upgrading, and read the changelog at docs.zfile.vip/changelog, which the README names as the place where update contents are recorded.

The licence is MIT, stated in the README and present as a LICENSE file at the repository root. MIT is permissive about use, modification and redistribution, but the README's note about donation-edition code being merged in and later separated means the licence file alone may not settle every question about the current tree. This is a description of what the repository states, not legal advice.

Editorial conclusion

Adopt ZFile if you already keep files in object storage or a cloud drive and want a single browsable, previewable front end with per-user directory scoping, and you are willing to run a Java service and a database yourself. Do not adopt it if you need a desktop or Android client, cannot run a JVM or container, or require rate limiting and file-type restrictions, which the README marks as donation-edition features. Before committing, verify three things on your own deployment: that the storage source you plan to use is on the supported list, that the 5.x donation code split described in the README has actually landed, and that the install script at docs.zfile.vip suits your host rather than the sample Dockerfile, which the repository says is not the one ZFile ships.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. zfile-dev/zfile on GitHub