# Collabora + Caddy reverse proxy (in Docker)

**URL:** <https://help.nextcloud.com/t/collabora-caddy-reverse-proxy-in-docker/5785>\
**Category:** 📄 Office\
**Tags:** collabora-online\
**Created:** [December 5, 2016, 11:33am UTC](https://help.nextcloud.com/t/collabora-caddy-reverse-proxy-in-docker/5785 "2016-12-05T11:33:42Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Flumble](https://help.nextcloud.com/user_avatar/help.nextcloud.com/flumble/32/1797_2.png) [@Flumble](https://help.nextcloud.com/u/Flumble)\
**Post date:** [December 5, 2016, 11:33am UTC](https://help.nextcloud.com/t/collabora-caddy-reverse-proxy-in-docker/5785/1 "2016-12-05T11:33:42Z")

</div>

Hello all,

I’m trying to set up Nextcloud and Collabora, with Caddy providing secure connections. All 3 are running in separate docker containers and can see each other, Caddy has port 80 and 443 exposed to the outside world and sends connections from two subdomains to either Nextcloud or Collabora.

What is working: Caddy is proxying connections from subdomains to the right services and Nextcloud is working like a charm.

The problem: CODE is returning 502s for every request. Caddy reports for example `04/Dec/2016:12:16:33 +0000 [ERROR 502 /hosting/discovery] EOF`.

* * *

Specific versions used:

- (on the host: Arch Linux 4.8.11, Docker 1.12.3, Docker-compose 1.9.0)
- Nextcloud 10.0
- Collabora Online connector 1.1.15
- Collabora CODE 2.0
- Caddy 0.9.3

(Hopefully all the) relevant parts of `docker-compose.yml`:

```
caddy:
  image: abiosoft/caddy
  restart: always
  environment:
    CADDYPATH: "/etc/caddycerts"
  volumes:
    - ./Caddyfile:/etc/Caddyfile
    - caddy-certs:/etc/caddycerts
    - caddy-web:/srv
  ports:
    - "80:80"
    - "443:443"

nextcloud:
  image: wonderfall/nextcloud
  restart: always
  depends_on:
    - nextcloud-db
  environment:
    - UID=1000
    - GID=1000
    - UPLOAD_MAX_SIZE=10G
    - APC_SHM_SIZE=128M
    - OPCACHE_MEM_SIZE=128
    - REDIS_MAX_MEMORY=64mb
    - CRON_PERIOD=15m
    - TZ=Europe/Amsterdam
    - ADMIN_USER=<somenameB>
    - ADMIN_PASSWORD=<somepasswordB>
    - DB_TYPE=mysql
    - DB_NAME=<somedbA>
    - DB_USER=<somenameA>
    - DB_PASSWORD=<somepasswordA>
    - DB_HOST=nextcloud-db
  depends_on:
    - nextcloud-db
  volumes:
    - nextcloud-data:/data
    - nextcloud-config:/config
    - nextcloud-apps:/apps2

collabora:
  image: collabora/code
  restart: always
  depends_on:
    - nextcloud
  environment:
    domain: "nextcloud\\.<somedomainA>"
  cap_add:
    - MKNOD
  expose:
    - "9980"

nextcloud-db:
  image: mariadb
  restart: always
  volumes:
    - nextcloud-db-data:/var/lib/mysql
  environment:
    - MYSQL_ROOT_PASSWORD=<somepasswordC>
    - MYSQL_DATABASE=<somedbA>
    - MYSQL_USER=<somenameA>
    - MYSQL_PASSWORD=<somepasswordA>

```

Relevant parts of the `Caddyfile`:

```
nextcloud.<somedomainA> {
  proxy / http://nextcloud:8888 {
    transparent
  }
}

collabora.<somedomainA> {
  errors stdout #for debug purposes
  log stdout #for debug purposes

  proxy / collabora:9980 {
    transparent
    websocket
  }
}

```

And finally the setting in the plugin:  
Server: `https://collabora.<somedomainA>`

Note that the domains are internet-facing, so Caddy builds certificates with Let’s Encrypt.

* * *

[One thing I found](https://help.nextcloud.com/t/collabora-configuration-with-docker-compose/3970/7) while making this thread and haven’t tried yet, is specifying the `VIRTUAL_HOST` and friends for the collabora environment. This didn’t help.  
Do CODE and Nextcloud have to communicate internally? If so, how does one specify the address they should use (assuming the services can’t communicate with each other using the domain names)?

---

<div class="post-metadata">

**Author:** ![JakeS](https://help.nextcloud.com/letter_avatar/jakes/32/6_22734026db12803ebb3e059622ac3534.png) [@JakeS](https://help.nextcloud.com/u/JakeS)\
**Post date:** [April 10, 2017, 5:13pm UTC](https://help.nextcloud.com/t/collabora-caddy-reverse-proxy-in-docker/5785/2 "2017-04-10T17:13:49Z")

</div>

Did you figure it out? I’m having the exact same issue

---

<div class="post-metadata">

**Author:** ![Nick\_Cooke](https://help.nextcloud.com/letter_avatar/nick_cooke/32/6_22734026db12803ebb3e059622ac3534.png) [@Nick\_Cooke](https://help.nextcloud.com/u/Nick_Cooke)\
**Post date:** [June 4, 2017, 7:16pm UTC](https://help.nextcloud.com/t/collabora-caddy-reverse-proxy-in-docker/5785/3 "2017-06-04T19:16:55Z")

</div>

I’d love to know too as this is the setup I’m using.

---

<div class="post-metadata">

**Author:** ![Flumble](https://help.nextcloud.com/user_avatar/help.nextcloud.com/flumble/32/1797_2.png) [@Flumble](https://help.nextcloud.com/u/Flumble)\
**Post date:** [June 29, 2017, 11:56am UTC](https://help.nextcloud.com/t/collabora-caddy-reverse-proxy-in-docker/5785/4 "2017-06-29T11:56:47Z")

</div>

Good news everyone!

It’s working with a new setup. The relevant changes are: switching the collabora proxy to https and ignoring that certificate’s validity.  
Since other changes _may_ have side effects that make it work (e.g. using the FPM container for nextcloud), I’ll list the whole setup below. Replace everything between \< angle brackets \> and all full domain names with your own of course.

* * *

`docker-compose.yml`:

```
version: '3'

volumes:
  caddy-web:
  caddy-certs:
  nextcloud-db-data:
  nextcloud-data:
  collabora-loolwsd:

services:
  caddy:
    image: abiosoft/caddy
    links:
      - nextcloud
      - collabora
    environment:
      CADDYPATH: "/etc/caddycerts"
    volumes:
      - ./Caddyfile:/etc/Caddyfile
      - caddy-certs:/etc/caddycerts
      - nextcloud-data:<nextcloud root>:ro
      - caddy-web:<other sites>:ro
    ports:
      - "80:80"
      - "443:443"

  nextcloud-db:
    image: postgres
    volumes:
      - nextcloud-db-data:/var/lib/postgresql/data
    environment:
      - POSTGRES_USER=nextcloud
      - POSTGRES_PASSWORD=<nextcloud db password>

  nextcloud:
    image: nextcloud:fpm
    links:
      - nextcloud-db
    volumes:
      - nextcloud-data:/var/www/html

  collabora:
    image: collabora/code
    depends_on:
      - nextcloud
    environment:
      domain: "my\\.nextcloud\\.domain"
      cert_domain: "collabora"
    cap_add:
      - MKNOD
    volumes:
      - collabora-loolwsd:/etc/loolwsd

```

`Caddyfile` (FPM directives based on [this example](https://github.com/caddyserver/examples/tree/master/nextcloud), collabora directives based on [the official guide](https://www.collaboraoffice.com/code/) and ignoring its certificate):

```
my.other.domain {
  root <other sites>
}

my.nextcloud.domain {
  root <nextcloud root>

### begin nextcloud fpm settings ###
  fastcgi / nextcloud:9000 php {
    root /var/www/html
  }

  rewrite {
    r ^/index.php/.*$
    to /index.php?{query}
  }

# client support (e.g. os x calendar / contacts)
  redir /.well-known/carddav /remote.php/carddav 301
  redir /.well-known/caldav /remote.php/caldav 301

# remove trailing / as it causes errors with php-fpm
  rewrite {
    r ^/remote.php/(webdav|caldav|carddav|dav)(\/?)$
    to /remote.php/{1}
  }

  rewrite {
    r ^/remote.php/(webdav|caldav|carddav|dav)/(.+?)(\/?)$
    to /remote.php/{1}/{2}
  }

# .htaccess / data / config / ... shouldn't be accessible from outside
  status 403 {
    /.htacces
    /data
    /config
    /db_structure
    /.xml
    /README
  }
### end nextcloud fpm settings ###
}

my.collabora.domain {
### begin collabora proxy settings ###
  proxy /loleaflet https://collabora:9980 {
    insecure_skip_verify
    transparent
  }

  proxy /hosting/discovery https://collabora:9980 {
    insecure_skip_verify
    transparent
  }

  proxy /lool https://collabora:9980 {
    insecure_skip_verify
    transparent
    websocket
  }
### end collabora proxy settings ###
}

```

And finally the setting in the Collabora Online plugin:  
Server: `https://my.collabora.domain`

[edit] Trusting the collabora certificate in nextcloud was not necessary after all. It was just a remnant from earlier tests. Good, because it presented a potential security hole: if you’re doing federated cloud stuff or have plugins that do requests to the outside, a MITM can generate a self-signed certificate just like the collabora VM and use it for an attack.

---

<div class="post-metadata">

**Author:** ![SimJoSt](https://help.nextcloud.com/user_avatar/help.nextcloud.com/simjost/32/68230_2.png) [@SimJoSt](https://help.nextcloud.com/u/SimJoSt)\
**Post date:** [March 8, 2018, 10:05am UTC](https://help.nextcloud.com/t/collabora-caddy-reverse-proxy-in-docker/5785/5 "2018-03-08T10:05:31Z")

</div>

Does this configuration still work for you? Especially in Firefox?  
With the current Caddy, Nextcloud and Collabora with the same Collabora section in my Caddyfile, Firefox loads the ui of the editor, but no document shows up. It has trouble connecting to the main socket.

**Edit:** I figured out, that the cache directive I added [currently has some issues with websockets](https://github.com/nicolasazrak/caddy-cache/issues/18). Removing it makes it Firefox-compatible.

---

<div class="post-metadata">

**Author:** ![wwe](https://help.nextcloud.com/user_avatar/help.nextcloud.com/wwe/32/72963_2.png) [@wwe](https://help.nextcloud.com/u/wwe)\
**Post date:** [November 6, 2024, 8:46pm UTC](https://help.nextcloud.com/t/collabora-caddy-reverse-proxy-in-docker/5785/6 "2024-11-06T20:46:50Z")

</div>

wwe: close old topics

---

<div class="post-metadata">

**Author:** ![wwe](https://help.nextcloud.com/user_avatar/help.nextcloud.com/wwe/32/72963_2.png) [@wwe](https://help.nextcloud.com/u/wwe)\
**Post date:** [December 9, 2024, 10:53am UTC](https://help.nextcloud.com/t/collabora-caddy-reverse-proxy-in-docker/5785/7 "2024-12-09T10:53:58Z")

</div>