quickshare is a self hosted file server with accounts, quotas and browser management

A file manager that happens to run on your own machine

quickshare is described in the repository description as quick and simple file sharing between different devices, built with Go, React and Typescript. That combination tells you the shape of it. The backend is a Go service, the frontend is a React application built with webpack, and the whole thing is a single self hosted application rather than a client that talks to someone else's server.

The homepage is the project's own site, and the repository carries a docs/ directory with a screenshots page, a demo GIF and a doc.md file. The README is bilingual, with an English version and a Simplified Chinese version in the docs folder.

What you get is a browser based file manager. The feature list names uploading, downloading, creating, deleting and moving files and folders, managing them in the browser, uploading hundreds of files at once, and fuzzy searching for files and folders in seconds. There is also cross platform support for Linux, Mac and Windows, and an adaptive UI, plus i18n support and wallpaper customization.

The searching is not a hand rolled feature. The Go module dependencies include github.com/ihexxa/fsearch and github.com/ihexxa/q-radix/v3, a radix tree library, so the fuzzy index is built on a tree structure rather than a directory walk.

The interesting part for an engineer is that this is not a bare upload endpoint. It has a model of users and storage.

User accounts with roles, quotas and speed limits

The user management section is the feature that separates quickshare from a folder of static files served over HTTP. The README lists support for multiple users, a role per user of either user or admin, a home directory per user, per-user download and upload speed limiting, and a per-user space quota.

Quotas and speed limits are the two that change what you can build on top. A quota turns the server into something you can hand to several people without one of them filling the disk. A speed limit turns it into something that will not saturate a link when one person starts a large transfer.

The storage layer is visible in the dependency list, and it is interesting because there are two database drivers rather than one. github.com/mattn/go-sqlite3 and modernc.org/sqlite are both present, the latter being a pure Go implementation, and github.com/boltdb/bolt is also there for a key value store. The authentication side uses github.com/robbert229/jwt for tokens, github.com/dchest/captcha for captcha handling and golang.org/x/crypto for the cryptographic primitives behind password hashing.

The dependency list also shows a scheduler, github.com/robfig/cron/v3, which is consistent with a server that has recurring housekeeping to do, and github.com/natefinch/lumberjack for log rotation, alongside go.uber.org/zap as the structured logger.

Anonymous access exists, but only for sharing: the README says directories can be shared to others, including anonymous, and that QR codes can be scanned to visit sharing folders.

Resumable transfers, and streaming that survives a CDN

Two upload behaviours in the feature list are worth pulling out because they answer different problems.

Resumable uploading and downloading means an interrupted transfer continues rather than starting over. The dependency list explains the mechanism: github.com/ihexxa/multipart is a direct dependency, so the resumable behaviour is built on a multipart handling library rather than on a custom protocol invented for this project.

Streaming uploading is described as making it work behind a CDN or reverse proxy. That is the more subtle claim. A typical upload endpoint buffers to disk and only then answers, which is fine on a direct connection but breaks behind infrastructure that terminates and re-sends requests, because the upstream service may already have received the body and then have to repeat the work. Streaming the request through to storage avoids holding the whole file in memory.

The rest of the data path is ordinary HTTP handled by gin, with gin-contrib/static serving the built frontend. Files can also be managed from the operating system, and the README points to docs/doc.md for the details of that mode rather than describing it in the main page, which is where you should look before planning automation against the storage directory.

Running it in Docker on port 8686

The recommended path is a container, and the README gives the exact command. It starts a quickshare container, publishes port 8686, mounts a directory for storage, and passes the initial admin credentials as environment variables.

docker run \
--name quickshare \
-d -p 8686:8686 \
-v `pwd`/quickshare/root:/quickshare/root \
-e DEFAULTADMIN=qs \
-e DEFAULTADMINPWD=1234 \
hexxa/quickshare

The README then tells you to open http://127.0.0.1:8686 and log in with the user name qs and the password 1234. The three environment variables are explained in the list that follows: DEFAULTADMIN is the default user name, DEFAULTADMINPWD is the default user password, and /quickshare/root is where Quickshare stores files and directories.

Two cautions. Those defaults are published in the README, so anyone who can reach your instance should assume them until you change them. And the volume mount is the only part of your data that is persistent, so if you run the container without it, files live inside the container layer and disappear when it is removed.

A second environment variable name appears in the Dockerfile and the docs for the OS level file access mode, which is a separate feature from the web interface.

Running from source needs Go, Node and Yarn at once

The source path is a three toolchain setup. The README asks you to confirm that Go or Golang of version 1.17 or higher, Node.js and Yarn are installed before you start, and then the sequence is a clone, a directory change, and a start command.

# clone this repo
git clone [email protected]:ihexxa/quickshare.git

# go to repo's folder
cd quickshare

DEFAULTADMIN=qs DEFAULTADMINPWD=1234 yarn start

The start script in package.json is where the two toolchains meet. It runs the frontend build and then the backend in one command.

    "start": "yarn build:fe && go run cmd/start/main.go -c `pwd`/configs/dev.yml",
    "server:dev": "go run cmd/start/main.go -c `pwd`/configs/dev.yml",

The frontend build is a webpack production build driven by src/client/web/webpack.app.prod.js, and the copy_js.sh script in scripts/ prepares the assets first. The backend entry point is cmd/start/main.go, and the configuration comes from a YAML file, with configs/dev.yml for development and configs/demo.yml shipped into the container image.

There is also a separate binary distribution path. The README points at the Release Page for downloads, and the flow is to unzip the archive and run the executable with the same two environment variables, optionally adjusting the execution permission with chmod u+x quickshare. The Go module targets go 1.25.0, while the Dockerfile builds the backend in a golang:1.24 image, which is worth knowing if you hit a toolchain error when building by hand.

The Dockerfile runs as a dedicated user on the container port

The Dockerfile is a three stage build and the last stage is the part that matters for deployment.

FROM debian:stable-slim
RUN groupadd -g 8686 quickshare
RUN useradd quickshare -u 8686 -g 8686 -m -s /bin/bash
RUN usermod -a -G quickshare root
COPY --from=build-be /quickshare/dist/quickshare /quickshare
ADD configs/demo.yml /quickshare
RUN mkdir -p /quickshare/root
RUN chgrp -R quickshare /quickshare
RUN chmod -R 0770 /quickshare
CMD ["/quickshare/start", "-c", "/quickshare/demo.yml"]

The container creates a group and a user that both carry the id 8686, which is the same number as the published port, and adds that user to the root group so it can read the storage directory. The storage path is created inside the image and given group write permissions with chmod -R 0770, which is why the volume mount in the run command has to line up with it.

The entry point is the built binary with a pointer to demo.yml. The frontend is built in a separate node:lts stage and the backend in a golang:1.24 stage, with the Go build driven by scripts/build_exec.sh.

The image is built locally with the build:docker script, which uses Dockerfile_default rather than the Dockerfile shown above, and there is a separate script for a Heroku flavoured build that uses the plain Dockerfile. Two Dockerfiles for two deployment targets is a small thing to be aware of if you build your own image.

What quickshare gives you that a plain file server does not

It is worth being explicit about the difference in approach, because the obvious alternative is to put an ordinary web server in front of a directory and hand out a link.

A plain file server has one job: serve bytes from a path. Authentication is either absent or bolted on by the server you chose, and there is no per-user space to speak of, because a directory has no notion of who owns which file. quickshare instead models users as first class objects with a role, a home directory, a quota and a speed limit, and it builds a browser UI over that model so that creating, moving and deleting folders is a normal operation rather than a scripted one.

The cost of that choice is the thing to weigh. quickshare is a larger system with a database, a session and token layer, a scheduler and a frontend build pipeline, so there is more to operate and more to update. The README itself flags that it is still under active development and that full backward compatibility is not guaranteed, which is a signal that upgrades can move under you.

For a personal setup between a handful of your own devices, the accounts, quotas and the browser file manager are the whole value proposition. If you only need to serve one directory read only to a few people, this is more machinery than the job needs.

LGPL-3.0, an empty FAQ, and releases that trail the commits

The licence is LGPL-3.0, with the text in the LICENSE file at the top level. For a self hosted server that most people run as their own binary or container, the copyleft obligations of the LGPL are usually not the deciding factor, but note that the licence is different from the permissive terms used by many comparable Go servers, so a team embedding this code into a distributed product should read it properly rather than assume.

On maintenance, the repository is not archived and the last push was on 2026-10-22, so work is still landing on the main branch. The recent releases are v0.11.4 on 2026-01-30, v0.11.3 on 2026-01-25 and v0.11.2 on 2026-01-19. The gap between the newest tag and the last push is wide, which means the tagged releases trail the code in the repository by many months. Anyone tracking releases rather than commits is running something considerably older than the current tree.

Documentation is the weak spot. The FAQ section of the README says only that it is coming soon, so the operational questions that matter after deployment, such as backup procedure, quota behaviour at the limit or how to rotate the admin password, are answered by docs/doc.md, by the configs directory or not at all. Read those before you rely on it.

Editorial conclusion

Adopt quickshare when you want to move files between your own devices over a network you control, and you want accounts with quotas rather than an anonymous upload bucket. Do not adopt it as a public file distribution service, because it is under active development with no backward compatibility guarantee and the README FAQ is still empty. Before you expose it, change the default admin credentials that the Docker run command sets through DEFAULTADMIN and DEFAULTADMINPWD, confirm the volume mounted at /quickshare/root is on storage you can back up, and read configs/demo.yml and docs/doc.md for the settings the image does not set for you.

Frequently asked questions

Official sources

1. ihexxa/quickshare on GitHub
2. License: LGPL-3.0
3. Project website
4. README
5. Releases