Anyone Rumming Seafile with the jwilder/nginx-proxy and jrcs/letsencrypt-nginx-proxy-companion?

As soon as I have my Seafile back up and running today, I was going to look at getting it working with the above containers which have provided a generalized pattern to managing Nginx and lets-encrypt in the docker-verse. Has anyone done this yet? I’ve seen some general issues raised trying to run Seafile with lets-encrypt that were not resolved. I was thinking I would terminate SSL at Nginx – and just proxy http rather then adding more complexity.

Even for folks who do not have multiple images on a single host, having a single automated Nginx/lets-encrypt process to manage would likely be a big benefit. If I have to go from scratch, I’ll document stuff on my blog, as I’m sure there’s a few gotchas or things of interest along the way.

  • Andrew

I’m using this combination for several months now. Works without any problems.

Excellent. Did you leave the existing http machinery in the Seafile docker-compose pretty much as is?
For the virtual_host did you use the docker container name of your seafile? I imagine it’ll be pretty easy when I can grab the image.



Yes, that’s what I did

Not quite sure what you mean. That’s part of my Seafile docker-compose:

    image: seafileltd/seafile-mc:latest
    container_name: seafile
    restart: unless-stopped
      - 80
      - /opt/seafile-data:/shared   # Requested, specifies the path to Seafile data persistent store.
      - VIRTUAL_PORT=80
      - DB_HOST=db
      - SEAFILE_SERVER_LETSENCRYPT=false   # Whether to use https or not.
      - db
      - memcached
      - nginx-proxy

One other idea to consider; I just implemented traefik as a front end to a number of services (containers and bare metal), including Seafile. If you haven’t heard of it, it functions similarly to NGINX but works across containers and other devices.

Similar to your desired outcome above, https terminates at traefik and Seafile runs without much complexity behind traefik. If you’re already familiar with NGINX it is probably easier to implement there, but if not, both are worth a look IMHO.

1 Like

I got this working - but not the manner I originally desired. I could not get the jwilder/nginx-proxy / jrcs/letsencrypt to work period; even with the most simple setup. I got tired of messing with it, magic that doesn’t work, even in the most simple case. All it would ever do is return a 503. I saw others with the same problem. I decided it was obviously to fragile for my tolerance levels.
I ended up using a similar approach, except I have to maintain the NginX config. It was a ceph something other other image and letsencrypt. It worked without any ado

That said, I had to do some fugly stuff with Seafile config – as it would not work behind a reverse proxy (for me). I went through far too much trial and error; again people having similar problems – often times no known resolve. One thread I found - the author claimed it worked. I put my stuff aside totally, to ensure I wasn’t doing something, and it didn’t work. I reverse proxy from my front-end Nginx directly, just as the bundled Nginx would have. To do that, I just had to set the ports in the docker-compose. Except in one case, I had to handle the root mount for the site elements: images, styles, etc. I did that by just reverse proxying those requests for media to the Nginx that comes with Seafile.
This works perfectly; although a huge clusterfsck. I was so tired of messing with half-baked or magik that wasn’t so magical. We’ll see what happens when i have an upgrade opportunity.

Thanks, I will check out this Traefik and eval it.