localhost:3000 everywhere

[siddjellali]

Hello team,

Could you please help me on that ?

Docker compose

  calendso:
    build:
      context: .
      dockerfile: Dockerfile
      args:
        - NEXT_PUBLIC_WEBAPP_URL=${NEXT_PUBLIC_WEBAPP_URL}
        - NEXT_PUBLIC_LICENSE_CONSENT=${NEXT_PUBLIC_LICENSE_CONSENT}
        - NEXT_PUBLIC_TELEMETRY_KEY=${NEXT_PUBLIC_TELEMETRY_KEY}
        - NEXTAUTH_SECRET=${NEXTAUTH_SECRET}
        - BASE_URL=${BASE_URL}
    container_name: calendso
    image: calendso/calendso:latest
    restart: always
    environment:
      NEXT_PUBLIC_LICENSE_CONSENT: $NEXT_PUBLIC_LICENSE_CONSENT
      DATABASE_URL: $DATABASE_URL
      NEXT_PUBLIC_WEBAPP_URL: $NEXT_PUBLIC_WEBAPP_URL
      GOOGLE_API_CREDENTIALS: $GOOGLE_API_CREDENTIALS
      NEXT_PUBLIC_TELEMETRY_KEY: $NEXT_PUBLIC_TELEMETRY_KEY
      EMAIL_FROM: $EMAIL_FROM
      EMAIL_SERVER_HOST: $EMAIL_SERVER_HOST
      EMAIL_SERVER_PORT: $EMAIL_SERVER_PORT
      EMAIL_SERVER_USER: $EMAIL_SERVER_USER
      EMAIL_SERVER_PASSWORD: $EMAIL_SERVER_PASSWORD 
      CALENDSO_ENCRYPTION_KEY: $CALENDSO_ENCRYPTION_KEY
      NODE_ENV: $NODE_ENV
      NEXT_PUBLIC_WEBSITE_URL: $NEXT_PUBLIC_WEBSITE_URL
      NEXT_PUBLIC_EMBED_LIB_URL: $NEXT_PUBLIC_EMBED_LIB_URL
      NEXTAUTH_URL: $NEXTAUTH_URL
      NEXTAUTH_SECRET: $NEXTAUTH_SECRET
      BASE_URL: $BASE_URL
      DOCKER_BUILDKIT: 0

I have all these variables configured in calcom docker

BASE_URL : https://agenda.xxxxxxx.com
NEXTAUTH_URL: https://agenda.xxxxxxx.com
NEXT_PUBLIC_APP_URL: https://agenda.xxxxxxx.com
NEXT_PUBLIC_WEBSITE_URL: https://agenda.xxxxxxx.com
NEXT_PUBLIC_WEBAPP_URL: https://agenda.xxxxxxx.com

What do i miss ?

+yellow: the license banner that won't go away (NEXT_PUBLIC_LICENSE_CONSENT: agree)

Thanks a lot for your support.

[nabilblk]

+1 Same here

[PeerRich]

@krumware i believe their .env is not being picked up correctly?

[krumware]

Are you building your own image or pulling and running the image directly from dockerhub?

To clarify: At this time, for all URLs to reflect a custom URL, and because of the nature of the static site build, the environmental variables must be provided at build time for a custom container image which can then be run to reflect the custom URLs

[siddjellali]

directly from dockerhub.

Do i need to create a fork and modify the variable below in the dockerfile ?
ARG NEXT_PUBLIC_WEBAPP_URL=http://localhost:3000

Why this variables cannot be modify as display in my docker compose above ?

[krumware]

You don't necessarily need to fork it, but you do need to tag and push your own image. This is a limitation of the nextjs build currently, as those variables are compiled into the frontend code at build time. The portions that are server side rendered or backend are able to use the variables, but not the files compiled into the static site.

[krumware]

@siddjellali were you able to find a path forward?

[wzrdtales]

@krumware Why don't you import a normal config file in the main project and overwrite a placeholder in there with the environment variable during the container boot. Then you can dynamically configure this. Using non runtime (those vars are compile time) env vars is a bad practice actually for frontends.

[siddjellali]

@siddjellali were you able to find a path forward?

Unfortunately not; I'm using portainer and submodule is not supported portainer/portainer#7240 (comment)

[krumware]

@krumware Why don't you import a normal config file in the main project and overwrite a placeholder in there with the environment variable during the container boot. Then you can dynamically configure this. Using non runtime (those vars are compile time) env vars is a bad practice actually for frontends.

This has been brought to the teams attention in the past but is not my decision. There is some contention in the nextjs community around this as well, even though I personally share your opinion.

If you can point to an example to follow on a similar stack, it may help the core team with the info they need to make those architecture decisions.

[wzrdtales]

this is so easy you can do it in 2 minutes...

This is not an architecture question as well. This is plain simply: how do I configure my environment.

It is done simply like that:

A static json loader either in the bootstrap of the frontend framework, or even before the frontend runs. Then you load a json document from the static assets which contains the config and make the parameters available on the window object, or if doing it in the bootstrap in any proper equivalent.

Another common strategy is just using the same domain that the frontend is being served on and having the API available at /api/*.

[wzrdtales]

here a plain simple init routine that we use in endless variations:

sed -i "s%^URL:.*$% URL: '$APIURL'%" public/ApiConstants.json;

that is it.

even simpler if you just have certain keyword to replace.

[krumware]

here a plain simple init routine that we use in endless variations:

sed -i "s%^URL:.*$% URL: '$APIURL'%" public/ApiConstants.json;

that is it.

even simpler if you just have certain keyword to replace.

I understand this method and have used it before as well, and I appreciate your passion for the issue.

Please open up an issue in https://www.github.com/calcom/cal.com with your recommendation and solution, and ideally a pull request related to the solution so that the core team can decide whether or not to implement this solution. There is existing discussion around runtime and static variable usage there as well.

If you feel this warrants a pull request solely in this repository, I'd be happy to review, test, and hopefully merge that as well.

[whallin]

Running into the same problems as @siddjellali since we also deploy our Docker services via Portainer.

Deploying cal.com by the instructions in the README is definitely an option, no doubt there, but having an "official" Docker image ready to go would be way easier. Especially for users, like me, with Docker Swarm setups looking for an easier way of high availability with their containers.

Hopefully, we'll see some update shortly which addresses this. :)

[wzrdtales]

I understand this method and have used it before as well, and I appreciate your passion for the issue.

Not mean to be unfriendly, but I am not passionate about this issue, more concerned and annoyed about how amateur the current "delivery" is. I understand that it is not really your priority, since you really only care about your own service and not about the actual open source deployments out there, though. Which is fair enough, your business model seems quite clear and open core always deviate into that direction, but little more love doesn't hurt.

If I find some spare time I wouldn't have a problem providing you with an implementation of it, but don't wait might take some weeks from now since I am too involved in other duties.