# Docker Caddy + vaultwarden - Can't get it to work

**URL:** <https://vaultwarden.discourse.group/t/docker-caddy-vaultwarden-cant-get-it-to-work/1249>\
**Category:** Third Party Help\
**Created:** [November 6, 2021, 6:00am UTC](https://vaultwarden.discourse.group/t/docker-caddy-vaultwarden-cant-get-it-to-work/1249 "2021-11-06T06:00:00Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![highend](https://avatars.discourse-cdn.com/v4/letter/h/6de8d8/32.png) [@highend](https://vaultwarden.discourse.group/u/highend)\
**Post date:** [November 6, 2021, 6:00am UTC](https://vaultwarden.discourse.group/t/docker-caddy-vaultwarden-cant-get-it-to-work/1249/1 "2021-11-06T06:00:00Z")

</div>

Hi!

Tried to run Caddy + vaultwarden on Debian Bullseye (stable) on a vServer (hosted by [Netcup.de](http://Netcup.de)).  
DNS entries are fine, even for the used subdomain.

This is my `/etc/Caddyfile`:

```auto
subdomain.domain.tld:443 {
  log {
    level INFO
    output file /var/log/caddy {
      roll_size 10MB
      roll_keep 10
    }
  }

  encode gzip

  reverse_proxy /notifications/hub localhost:3012

  reverse_proxy localhost:80 {
       header_up X-Real-IP {remote_host}
  }
}

```

`subdomain.domain.tld` is (ofc) a real domain (e.g. something like: `vaultwarden.somedomain.de`)

```auto
docker run -d --name vaultwarden -v /srv/vaultwarden:/data -e WEBSOCKET_ENABLED=true --restart on-failure vaultwarden/server:latest
docker run -d --name caddy -v /etc/Caddyfile:/etc/caddy/Caddyfile -v /etc/caddy:/root/.local/share/caddy -p 80:80 -p 443:443 --restart on-failure caddy:2

```

`docker ps -a`

```auto
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
6648b26baa05 caddy:2 "caddy run --config …" 11 minutes ago Up 11 minutes 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp, 2019/tcp caddy
e885f1daaef4 vaultwarden/server:latest "/usr/bin/dumb-init …" 11 minutes ago Up 11 minutes (healthy) 80/tcp, 3012/tcp vaultwarden

```

But I can’t access `https://vaultwarden.somedomain.de` afterwards…

```auto
This page isn’t working
vaultwarden.somedomain.de redirected you too many times.
Try clearing your cookies.
ERR_TOO_MANY_REDIRECTS

```

I’ve cleared the cookies for that domain in Vivaldi, still the same message…

Help, please 🙂

---

<div class="post-metadata">

**Author:** ![cksapp](https://avatars.discourse-cdn.com/v4/letter/c/b9e5f3/32.png) [@cksapp](https://vaultwarden.discourse.group/u/cksapp)\
**Post date:** [November 7, 2021, 2:30am UTC](https://vaultwarden.discourse.group/t/docker-caddy-vaultwarden-cant-get-it-to-work/1249/2 "2021-11-07T02:30:56Z")

</div>

My guess would be that you have both vaultwarden and caddy listening in on port 80, so when you send traffic from port 80 (for http certificate verification within caddy, as well as redirect to 443) it attempts to send this traffic back to vaultwarden which you have specified as localhost:80 again which is where caddy is listening.

> [@highend](#):
>
> ```auto
> CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
> 6648b26baa05 caddy:2 "caddy run --config …" 11 minutes ago Up 11 minutes 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp, 2019/tcp caddy
> e885f1daaef4 vaultwarden/server:latest "/usr/bin/dumb-init …" 11 minutes ago Up 11 minutes (healthy) 80/tcp, 3012/tcp vaultwarden
> 
> ```

> [@highend](#):
>
> ```auto
> reverse_proxy /notifications/hub localhost:3012
> 
> reverse_proxy localhost:80 {
> 
> ```

Either use the environment variable **-e ROCKET\_PORT=8080** (this can be set to any arbitrary unused port so long as it is not publicly accessible as it is assumed to be on a private network)  
This will also mean this same port needs to be use for the caddy redirect,

```auto
  reverse_proxy vaultwarden:8080 {
       header_up X-Real-IP {remote_host}

```

Or you can simply use docker-compose which will allow you to more easily manage multiple container settings cleanly, as well as start up multiple related containers much easier, and this will also create a docker network specifically for internal Caddy → Vaultwarden traffic which would remove the need for a separate port 80 on localhost