calcom
docker-compose port use .env variable or default :3000
make it possible to overwrite the :3000 port using .env instead of modifying docker-compose.yaml file
@wivaku thanks for the suggested change here!
If I use the port env variable which now also updates the host port in addition to the calendso service port, wouldn't the container port also need to be updated?
Not sure if I fully understand your question. In general the exposed and the internal port are separate. So, internally the container could still be based on the default :3000 port, and only the external port is changed.
In the past I have manually changed the docker-compose.yaml file (e.g. 3021:3000) and that worked. To be fair, I have not tested it recently for Calendso as I am having some trouble with the recent builds.
Not sure what the .env values should be in this case: the internal :3000 port or the changed external port.
I have not tested that.
E.g. this?
PORT=3021
# BASE_URL="http://localhost:3000"
BASE_URL="http://localhost:${PORT}"
# NEXT_PUBLIC_APP_URL="http://localhost:3000"
NEXT_PUBLIC_APP_URL="http://localhost:${PORT}"
Yea, that was a rough misunderstanding for me there, since most JS framework projects leverage that env pattern where PORT is used separately from the host URL, unlike the method used by calendso here. I hadn't considered that the port is hardcoded in the base_url for some reason.
In the case you show in your e.g., the internal port would no longer map to the process (which is where my thought process was)
Maybe we can also suggest a change upstream in calendso/calendso for the .env.example to use your pattern in the e.g. above? so that we have parity in the method used to change the port
As a next step it would definitely be interesting to modify the .env.example. Before that is done it would be good to do some more testing so that we have an actual working example of using a different port than :3000. This pull request is a safe first step.
Yea I think this is a good start. The way I approach this in internal projects is to leverage a load balancer in the docker-compose to keep the ingress configuration separate from the workload's. That way the frontend's port can be remain specific to the workload itself. Another piece for another day as well. Thanks for the discussion! let's keep this rolling