Seahub: the Django and webpack web front of a self-hosted Seafile server

Seahub is one layer of a two-part server

Seahub is the web frontend for Seafile, and that sentence sets the scope precisely. The project is not a file server and it is not a sync client. It is the browser-facing layer of a Seafile deployment, the part a user logs into to browse shared libraries, manage files, and use the sharing and group features. The README's first preparation step is telling: build and deploy the Seafile server from source, with a pointer to the Seafile manual for the details. Everything Seahub does assumes a Seafile server is already running underneath it, and the configuration file is full of directories that only make sense in that context. For an engineer evaluating self-hosted file sync, that ordering is the first thing to internalise. Seahub is where you end up after the harder half of the project is already done.

Four commands get you from clone to running server

The setup sequence in the README is short and explicit. You clone the source, create a virtualenv, activate it, and install the Python dependencies:

    $ git clone git://github.com/haiwen/seahub.git

    $ virtualenv .virtualenv
    $ . .virtualenv/bin/activate

    $ pip install -r requirements.txt

After that you run the service with the provided template script:

    $ . .virtualenv/bin/activate
    $ ./run-seahub.sh.template

and open `http://localhost:8000/` in a browser, where there should be a login page. The presence of a login page is the README's own verification step, which is a useful marker: if you see it, the Django application is wired to the Seafile server correctly. Note that the scripts are named `.template`, so you are expected to copy them and edit the copies, which is the same pattern the configuration file follows.

setenv.sh.template holds four paths that must be right

The configuration section names the file to edit and the four variables in it. You modify `CCNET_CONF_DIR`, `SEAFILE_CENTRAL_CONF_DIR`, `SEAFILE_DATA_DIR`, and `PYTHONPATH` in `setenv.sh.template` to fit your path. The README then explains what each one means. `CCNET_CONF_DIR` is the directory containing the ccnet socket, and formerly the ccnet.conf file. Since version 5.0, `SEAFILE_CENTRAL_CONF_DIR` contains most of the config files. `SEAFILE_DATA_DIR` is the seafile-data directory, and formerly contained seafile.conf. The wording about what each directory used to hold is a good signal of a codebase that has accumulated migrations over a decade, and it tells you where to look if a path does not resolve. `PYTHONPATH` is the fourth, and it is the one people miss, because the application has to be able to import the Seafile Python modules that live outside this repository.

The dependency list is a Django server with enterprise SSO attached

`requirements.txt` pins everything with exact version constraints, and the shape of the list tells you what this application is. The core is `Django==5.2.*` with `djangorestframework==3.16.*` for the API surface and `gunicorn==25.0.*` for serving. Then come the pieces a self-hosted deployment usually needs: `djangosaml2==1.11.*` and `pysaml2==7.5.*` for SAML single sign-on, `python-cas==1.7.*` for CAS, `pyjwt==2.13.*` for tokens, and `python-ldap==3.4.*` for directory binding. There is a captcha stack with both `django_simple_captcha==0.6.*` and `captcha==0.7.*`, and `bleach==6.3.*` for sanitising user content. Storage and caching run through `mysqlclient==2.2.*` and `redis==7.1.*`, media handling uses `pillow==12.2.*` plus `pillow-heif==1.2.*` for HEIF images, and `cairosvg==2.9.*` handles SVG. A couple of entries are quietly revealing: `pypinyin==0.55.*` for Chinese phonetic conversion, which is there for search and sorting in a product with a large Chinese user base.

The frontend is webpack, and the Makefile is the build entry point

Although the repository is mostly Python, the UI is a compiled JavaScript bundle served by Django. The dependency on `django_webpack_loader==1.7.*` and the presence of a `frontend/` directory alongside `static/` are the tells. The Makefile is where the build steps live, and the `dist` target chains them:

dist: locale statici18n collectstatic

The `locale` target runs `django-admin compilemessages` to compile the translation catalogues, `statici18n` runs `python manage.py compilejsi18n` to generate the JavaScript locale files into `static/scripts/i18n`, and `collectstatic` runs `python manage.py collectstatic --noinput` into `media/assets`, excluding the admin and termsandconditions. Two further targets exist for production styling: `compressstatic` runs `python manage.py compress` to compress the CSS into `media/CACHE`, and `clean` removes the generated caches. The `develop` target only wires the repository's git hooks into `.git/hooks`, which tells you the contribution workflow assumes a local checkout with hooks enabled rather than a packaged install.

Translations run through Transifex, not pull requests

Internationalisation is handled through Transifex rather than through in-repository string files, and the README documents the joining process in five steps. You visit the Transifex project page for haiwen/seahub, click Join this project, create an account with an email or a GitHub account, select a language and join that language translation, and once the project maintainer accepts you, you can upload a file or translate online. The repository supports this with a `locale/` directory for the translation catalogues and a `.tx/` directory for the Transifex client configuration. The `i18n.sh` script at the root is the local counterpart. The `statici18n` Make target and the `compilejsi18n` management command then push those strings into the frontend bundle, which is why the build order in the Makefile matters.

The release tags and the licence are the two things to check first

The release history in the repository uses tagged versions with a `-pro` suffix, and the dates are not in ascending order of major version. The list shows v13.0.12-pro from 2025-10-23, v13.0.9-pro from 2025-08-27, and v12.0.20-pro from 2026-02-02, so the 12.x and 13.x lines are being maintained in parallel. The last push was on 2026-10-22, which is recent work on an active codebase rather than a dormant one. The licence is the item to resolve before you build on it. GitHub classifies the licence as a custom one it cannot categorise, and the repository carries `LICENSE.txt` alongside `LICENSE-thirdparty.txt` for the bundled dependencies, so the terms have to be read directly rather than assumed. The project also ships a `HACKING` file, an `AGENTS.md`, a `fabfile/` for deployment automation with the `fabric` tool, `tools/`, and a `pytest.ini` with a `tests/` directory, which is the shape of a project with a real contributor workflow rather than a weekend script.

Editorial conclusion

Seahub fits a team that has decided to run its own file sync server and needs the standard web client for it, especially where the Seafile manual already covers building the server side, since Seahub assumes a compiled Seafile server underneath it. It is the wrong tool if you want a hosted file service, because the whole project is a deployment of your own, and it is the wrong tool if you cannot run a Python service, since the frontend is a Django application with a gunicorn-backed server rather than a set of static files. Before adopting it, read `setenv.sh.template` and the four path variables, confirm your Seafile server build matches the version family, and check the LICENSE file yourself because GitHub reports a custom licence it cannot classify.

Frequently asked questions

Official sources

1. haiwen/seahub on GitHub
2. Issues
3. README
4. Releases