Docker migration

I am moving a number of existing services & webservers from Linux-native format into Docker containers.

How do I go about migrating my existing Seafile deployment to use the Docker front-end container? I am assuming it is just that… the Docker container only replaces the webserver element? So the backend deployment is unchanged?

Is there a tutorial / guide / wiki for how to do this, encapsulating all steps?

I have used Seafile from a much earlier version. Will this have an impact on the expected folder structure for the Docker container?

Can I switch between my current working setup and the Docker container easily (while testing)? As in stop apache site, start docker and change any reverse proxy / router configuration - and reverse this for the other way around.

Also, I am using jwilder’s nginx-proxy Docker container to automate the main nginx container’s config. This also handles Lets Encrypt in conjunction with another pre-deployed container. Will this work within this setup? Any known issues or aspects to consider?


No, not at all. Sadly, it has it’s own mariadb server. But when you load your backups into the server it’ll work.

I don’t know one.

Same problem with old library versions as on normal updates.

If you proxy your container, you also can put the certs there. You just have to proxy_pass everything, even fastcgi. So the config should be around 5 lines.

Thanks @bionade24. I knew this migration wouldn’t be as easy as anticipated!

Is it expected to backup existing Seafile data, then load / import it into this new container deployment? Never performed this action before. Would this then be using newer folder structures?

Isn’t mariadb a DB platform, replacing MySQL as open source? Or was this simply a typo?

Another potential way would be to swap the front end from apache to nginx (believe this is preferred in more recent versions anyway) and then look to simply move this nginx config into its own container and proxy it. Unless the inherent way of using Seafile’s own container format is better?

My only concern for a native to container migration would be file permissions, as the Seafile server itself runs as root on the container (completely unnecessary, and dangerous if an attacker finds a vulnerability on the seafile server and manages to break out of the LXC) and the seafile manual instructs you to create an unprivileged user to run the server.

Other than that the migration should be pretty straight forward, just restore the database on the container and modify the directories to match that of the docker container
(Something like that, don’t use symbolic links though)

1 Like

Good Idea, but does it work with the mariadb database?
Edit; I’m not a fan of physical backups, I like the logical ones more.

Just to clarify: The seafile server and seahub (processes created by “” and “” only) should run as an unprivileged user, there’s no reason to run them as root. The same can’t be said about nginx or mariadb, those run on root because they need to (only privileged processes can use the lower 1024 ports) and are designed to deal with those permissions safely.

I haven’t tried to do this myself yet but you shouldn’t have any problems migrating to mariadb since it’s designed to be a drop-in replacement for mysql.

Have you already created an issue on Github?


To close out the initial thread… To help with my initial move to using Docker in my environment, I decided to migrate the Seafile web server from the original Apache webserver installed on the server to a new Nginx container, replicating the same settings. The rest of the Seafile components were to be untouched.

In my Docker setup, I have another Nginx container functioning as the primary reverse proxy as the endpoint for ports 80 & 443 to my external IP. This in turn passes on traffic to other webserver containers depending on the URL typed in by the requester.

The Seafile webserver container is able to connect to the standard Seafile and Seahub processes via ports 8000 and 8082 (bridging between the Docker network(s) and the physical LAN as needed - required specifying the local LAN DNS server within the container creation statement). There were a few volumes that needed mounting inside the container as well.

This should help at least with keeping the Seafile web server itself up-to-date and retiring the host-based webserver software.

In time, I may try to official Docker image, but as was said in the thread, it is as yet unknown the direction of this container as well as understanding some of the implications of the move, like running processes as root, etc.