I have read some discussion about seafile13 and its constraint about deployment/installation.
Docker looks as developer part an easy approach to provide a tool, but looks ugly choice when user try to deploy it.
Until 12,documentation was enough to deploy in many case. Was not perfect but at least all information were provides to manage it.
Now with only docker approach, is not possible to respect is own infrastructure. Is no more possible to use bare metal approach or any other virtualisation solution.
Actually only solution looks to buy pro version without any warranty to install outside docker.
Seafile team could be possible to provide a documentation as before and permit simple installation without any infrastructure requirement ?
Maintaining a manual installation option for the Seafile community edition is no longer practical because it is too time consuming and error-prone. With the complexity of modern software dependencies and the speed at which software evolves, supporting and documenting manual installations across diverse environments is increasingly difficult.
Docker provides a standardized, predictable deployment platform that ensures reliability for users and greatly reduces the maintenance burden for the Seafile (our) team.
While we understand the desire for bare metal or custom infrastructure deployments, the move to containerization allows us to deliver updates and security fixes more consistently, reducing the chance of misconfiguration or failed manual setups.
For these reasons, the manual installation option cannot be maintained alongside Docker-based deployment.
For pro edition users, we also recommend to use docker based deployment. The manual installation option is maintained for customers that not able to change to docker based deployment in short time.
Thanks for your reply, I understand partially this approach but Docker is a lock. It’s ugly to use an another approach or diverge from initial configuration. Also we must accept images provided as black box.
Provide a “recipe“ to build docker image or any infrastructure context could be helpful.
As experience, I’ve yet due to extract discourse installation (only docker based) to fresh Debian although docker image are in fact fresh debian based, really a non sense.
I hope an evolution could be provided to help us, as earlier/old user, to continue to maintain their infrastructure.
I think alternative are less impressive/easy/efficient but I can’t use docker. It’s not compatible with any server I manage (bare metal, incus or ceph like). It’s too complex to convert a dockerfile to simple deployment script.
I’m very confused, I hope a change but as I understand actual approach I can’t have any chance about that.
I’m currently trying to build deb-packages from the seafile-server to suit my needs. If this installation method works for you, please follow my fork on GitHub. Since I can’t post links, you can find the repository using my nickname.
Is there documentation how to move from binary install to docker based install while at the same time maintaining all users, links, databases and repositories? Or is moving to docker always requiring a fresh, start from scratch, do everything new from 0 approach?
Yes, there is documentation on how to migrate from a binary Seafile installation to a Docker-based installation while maintaining all users, links, databases, and repositories. You do not need to start from scratch.Migrate from non-docker deployment - Seafile Admin Manual
The recommended steps generally involve:
Shutting down the existing Seafile, Nginx, and cache server services.
Backing up your MySQL database and Seafile libraries data.
Deploying Seafile Docker on a new machine (or the same machine with careful attention to tips in the document).
Recovering the Seafile libraries and MySQL database in the new Docker environment.
Those files would be wherever you told your system to save them. In the .env file (when using docker at least) has an entry “SEAFILE_VOLUME=” where you set where the seafile container should be saving data. So a backup would be backing up that data, and the matching database. A restore would be putting those files back, and restoring the database.
I’ve been using Seafile for over 10 years. Installation and updates have always been fiddly. But since it always ran reliably in the background once installed, I let it slide a bit, so I’m now stuck on version 11. Obviously, you can’t accept that indefinitely in a production environment.
Now this update is a real slap in the face. I wonder why there aren’t instructions for non-exotic systems like Debian.
Instead, on pure Debian systems, I’m supposed to mess around with completely unnecessary Docker crap for Seafile, instead of just installing it directly?
The icing on the cake is the claim/lie that maintaining instructions would be far too much work! Thanks! I can fool myself just fine, thank you. It’s probably time to start looking for an alternative.
A guide to the development team’s preferred OS base would be sufficient. Then I’ll just have to familiarize myself with that OS base if necessary. Isn’t that something they have internally? They could also provide an .iso file.
But Docker is simply awful and completely out of place.
For Seafile 13 Community Edition, there is no longer a “preferred OS base” for binary installations because official support for non-Docker deployments was discontinued with this version.
The transition to a Docker-only model for the Community Edition was made specifically to eliminate the “fiddly” nature of maintaining complex dependencies (like Python versions and system libraries) across various Linux distributions, which previously made installations and updates difficult to support. By using Docker, the development team provides a consistent environment regardless of the host OS.
Regarding your points:
Preferred OS: While the development team historically supported Ubuntu and Debian for binary installs, those guides now only apply to the Professional Edition, which still supports binary deployment. You can find the Pro binary documentation here.
ISO file: There is no official ISO provided for Seafile.
Non-Docker alternatives: As mentioned earlier in the thread by other community members, you can look into the build scripts in the Seafile Docker repository. While these are used to build the Docker images, some users have used them as a starting point for bare-metal setups, though this is not officially documented or supported.
If a bare-metal installation is a hard requirement for your production environment, you might consider the Professional Edition (which has a free tier for up to 3 users) as it remains the only version with official binary deployment support. Otherwise, the recommended path forward is to follow the migration guide to Docker.
I don’t presume to criticize your (necessary?) economic considerations.
However, I must point out that there is still no proper installation documentation. If you’re championing open-source software, that’s a bad sign.
Even the supposedly “simple” Docker installation is anything but smooth!
The exclusive switch to Docker only makes this situation worse, instead of offering any advantages.
I really like your approach of focusing on the essentials. But the poor update and even installation mechanisms on new machines make it practically impossible for me to use it seriously anymore.
The variety of otherwise well-functioning clients can’t change that.
I just migrated to docker to be able to upgrade to verison 13.
I’m not very satisfied about how the setup is done. Before I had a linux container with seafile and mysql talking via an unix socket, now they expect an ip address to communicate.
Since my NAS kernel doesn’t have the netfilter and bridge modules, I switched to macvlan networking, and now I have redis exposed on the lan.
Wouldn’t be possible to let the services talking via unix sockets? Just share a tmpfs with the sockets in it.
Regarding your question about Unix sockets: support for Unix socket connections was officially discontinued starting around version 11. We found that maintaining support for both TCP/IP and Unix sockets across all components (seaf-server, seahub, seafevents, etc.) significantly increased code complexity and led to frequent configuration errors.
In Seafile 13, the architecture is strictly designed for TCP/IP communication between containers. Since you are using macvlan and exposing these services to your LAN, the recommended security measures are:
Set strong passwords: Ensure you have defined robust passwords for both MariaDB and Redis in your .env file using the SEAFILE_MYSQL_DB_PASSWORD and REDIS_PASSWORD variables.
Access Control: Since your kernel lacks netfilter/bridge modules for standard Docker isolation, password-protecting the services is the primary way to secure them. Seafile components are configured via the .env file to use these credentials for all internal communication.
For more background on why Unix socket support was removed, you can refer to the discussion in GitHub Issue #2590.
I
