- Complete redesign of the [official Docker deployment](https://manual.seafile.com/docker/deploy%20seafile%20with%20docker/) with containerization best-practices in mind.
- The caddy reverse proxy serves as a single entry point to the stack. Everything else runs in an isolated network.
- Using [Alpine Linux](https://alpinelinux.org/about/) based images for the frontend, which is designed with security in mind and comes with proactive security features.
- Official Seafile Docker deployment uses entirely outdated base images and dependencies. Here base images and dependencies are updated on a regular basis.
- contains the backend component called [seafile-server](https://github.com/haiwen/seafile-server)
- handles storage, some direct client access and seafdav
- *seahub*
- dynamic frontend component called [seahub](https://github.com/haiwen/seahub)
- serves the web-ui
- communicates with seafile-server
- *seahub-media*
- serves static website content as well as avatars and custom logos
- *db*
- the database used by *seafile-server* and *seahub*
- *memcached*
- database cache for *seahub*
- *seafile-caddy*
- reverse proxy that forwards paths to the correct endpoints: *seafile-server*, *seahub* or *seahub-media*
- is the single external entrypoint to the deployment
Volumes:
- *seafile-data*
- shared data volume of *seafile-server* and *seahub*
- also contains configuration and log files
- *seafile-mariadb*
- volume of the *db* service
- stores the database
- *seahub-custom*
- contains custom logos
- stored by *seahub* and served by *seahub-media*
- *seahub-avatars*
- contains user avatars
- stored by *seahub* and served by *seahub-media*
*Note: In the official docker deployment custom and avatars are served by nginx. Seahub alone is not able to serve them for some reason, hence the separate volumes.*
Networks:
- *seafile-net*
- isolated local network used by the services to communicate with each other
If you run a single node swarm and don't want to run multiple replicas, you can use the same compose file. Otherwise refer to [Additional Information / Docker Swarm](#Docker-Swarm-1).
**Important:** The environment variables are only relevant for the first deployment. Existing configuration in the volumes is **not** overwritten.
On a first deployment you need to carefully set those values. Changing them later can be tricky. Refer to the Seafile documentation on how to change configuration values.
This will be used for the SERVICE_URL and FILE_SERVER_ROOT.
Important: Changing those values in the config files later won't have any effect because they are written to the database. Those values have priority over the config files. To change them enter the "System Admin" section on the web-ui. If you encounter issues with file upload, it's likely that those are configured incorrectly.
The [official Docker deployment](https://manual.seafile.com/docker/deploy%20seafile%20with%20docker/) uses [bind mounts](https://docs.docker.com/storage/bind-mounts/) to the host path instead of actual docker volumes. This was probably chosen to create compatibility between a native install and the docker deployment. This deployment uses [named volumes](https://docs.docker.com/storage/volumes/), which come with several advantages over bind mounts and are the recommended mechanism for persisted storage on Docker. The default path for named volumes on Docker is `/var/lib/docker/volumes/PROJECT-NAME_VOLUME-NAME/_data`. Of course you could also use the old paths but it is not best practice according to the Docker documentation.
This deployment does by design **not** include a reverse proxy capable of HTTPS and Let's Encrypt, unlike the official deployment, because usually Docker users already have some docker-based reverse proxy solution deployed, which does exactly that.
