Self-hosted instance error: Cannot start Caddy

I updated my self-hosted docker instance to the latest version today as well as updated the OS.
Then restarted the system.

After that Caddy is giving an error and not starting:

root@docker-ubuntu-s-1vcpu-1gb-intel-blr1-01:~/baserow# docker-compose up -d
Starting baserow_volume-permissions-fixer_1 ...
baserow_redis_1 is up-to-date
baserow_db_1 is up-to-date
Starting baserow_caddy_1                    ...
baserow_backend_1 is up-to-date
baserow_celery-export-worker_1 is up-to-date
baserow_web-frontend_1 is up-to-date
baserow_celery_1 is up-to-date
baserow_celery-beat-worker_1 is up-to-date
Starting baserow_caddy_1                    ... error

Starting baserow_volume-permissions-fixer_1 ... done
 tcp4 bind: address already in use

ERROR: for caddy  Cannot start service caddy: driver failed programming external connectivity on endpoint baserow_caddy_1 (9f6f825948978bd651ba18a8ee473187b3b6f5204a9663de04a3d13e31aea943): Error starting userland proxy: listen tcp4 bind: address already in use
ERROR: Encountered errors while bringing up the project.

docker-compose ps :

root@docker-ubuntu-s-1vcpu-1gb-intel-blr1-01:~/baserow# docker-compose ps
               Name                             Command                   State         Ports
baserow_backend_1                    /usr/bin/tini -- /bin/bash ...   Up (unhealthy)
baserow_caddy_1                      caddy run --config /etc/ca ...   Exit 128
baserow_celery-beat-worker_1         /usr/bin/tini -- /bin/bash ...   Up (healthy)
baserow_celery-export-worker_1       /usr/bin/tini -- /bin/bash ...   Up (healthy)
baserow_celery_1                     /usr/bin/tini -- /bin/bash ...   Up (healthy)
baserow_db_1                postgres    Up (healthy)     5432/tcp
baserow_redis_1             redis ...   Up (healthy)     6379/tcp
baserow_volume-permissions-fixer_1 chown ...   Exit 0
baserow_web-frontend_1               /usr/bin/tini -- /bin/bash ...   Up (healthy)

How to resolve this issue?

Hi @shrey ,

It looks like you already have another service binded to port 443. If you don’t need to use the Baserow Caddy service to manage SSL then you can instead launch the docker-compose with

WEB_FRONTEND_SSL_PORT=4443 docker-compose up -d

Or some other free port.

Alternatively you could add the above line to your .env file so you don’t need to remember to include it every time you docker-compose up.

@nigel Thanks for your response.
It seems there was another reverse proxy configured for this instance.
Disabled that now and using only Caddy.

Still getting this though:

baserow_caddy_1                      caddy run --config /etc/ca ...   Up (unhealthy)   2019/tcp,>443/tcp,>80/tcp

Does something need to be done about this?

Also, don’t know if this is a related issue or not, but now am unable to log into the dashboard with the primary user credentials.


Incorrect credentials
The provided e-mail address or password is incorrect.

Hm, the unhealthy there means that the custom healthcheck we’ve added in the docker-compose for Caddy isn’t working. Are you able to access and use Baserow? If so then its a problem with the healthcheck and can be safely ignored.

When you say primary user credentials is this an account you’ve already made in Baserow? If so how were you running Baserow previously and what version were you running?

Yes, this is the main account that i use my Baserow instance with and already created when first installed (couple of months ago).

Before upgrading today, i was on the version released before this.

And you were using docker-compose up also previously?

Are you able to create a new account just to see if that is working?

Just created an account with the same email address.
Seems like my old settings & data have been lost somehow, during the upgrade :confused:

Unless you explicitly deleted the old data volume somehow by running any of the following:

  • docker-compose down -v (the -v flag will delete any volumes, never use this unless you want to delete your data!)
  • docker volume delete ...
  • docker system/volume prune

Your data should still be on your machine and retrievable.

Can you detail exactly how you performed the upgrade step by step? I.e the exact commands you ran and in which folders.

git pull
docker-compose pull
docker-compose down && docker-compose up -d
docker system prune -a --volumes

probably the last statement got executed when the container wasn’t up and the data then got deleted

Yes I would never ever recommend running that last prune command as it is very likely that it deleted all of your data. I’m not sure if it is recoverable :frowning: .

In the future we provide upgrade steps here: Install with Docker compose // Baserow and I also strongly recommend you backup your Baserow database using the provided instructions at Install with Docker compose // Baserow before any upgrade.

Thanks for all the details.