I am not exactly sure what you mean by “rebuild”.
You have your BW container running, with some persistent volumes where the configuration, vaults etc. are stored. The container is a “black box” to you, that you can (and should!) update, restart etc. You never need to get inside that container.
When it is running, you can access it via a port you exposed (-p
or ports:
in docker-compose
). This is maybe fine for tests or limited usage, but this is not how I do it.
I do not expose any ports but have Caddy “offering” https://bitwarden.my.domain
. When calling that URL, it gets actually proxified to the BW container (on the default port, within the docker network). This allows me to handle https://bitwarden.my.domain
at Caddy’s level, especially the TLS (certificate) part that will be done automatically.
Of course, if you use BW outside your local network, you need to have a publicly resolvable name (say, https://bitwarden.mycompany.com
that points to your Internet point of presence. From there the traffic intended to port 80
and 443
would be forwarded to the server that hosts caddy (and that exposes these ports).
Finally, once you settled upon a domain name, you can go to the /admin
URL of your server, authenticate with the token you set at startup time (in docker-composer.yaml
in my case) and in “General” you will find the FQDN of your server to fill in (I guess that could also be done with environment variables)