New NEXT_PUBLIC_WEBAPP_URL not taken over for static files

Hi,
I initially build calcom image with the localhost:3000 url and changed it now to my correct URL, but still in the app or at some links still the localhost:3000 base url is taken.

How to force calcom to take the new URL? In the documentation is written, it's taking some time.

Thanks,

Problem confirmed and also present when using official Docker images. It seems that a lot of things are statically set and cannot be changed at run time, which is a very bad design... The bottom line is that these variables shouldn't be needed to build the application 😅

@zomars

Hello @zomars @PeerRich,
sorry to ping you, as you're the main contributors to this repository, could you please have a look to this issue please ? 😉
Thanks for all the amazing work you do ! 🚀

Looks like the issue persists, I reported in calcom/cal.diy#20078

I have some issues related to 'localhost:3000' but I do not find it anywhere.

It produces the errors below:

agenda  | @calcom/web:start:   ▲ Next.js 13.5.7
agenda  | @calcom/web:start:   - Local:        http://localhost:3000
agenda  | @calcom/web:start:
agenda  | @calcom/web:start:  ✓ Ready in 4.1s
agenda  | @calcom/web:start:
agenda  | @calcom/web:start:  ⚠ metadata.metadataBase is not set for resolving social open graph or twitter images, using "http://localhost:3000". See https://nextjs.org/docs/app/api-reference/functions/generate-metadata#metadatabase
agenda  | @calcom/web:start: 00:25:29:387 [WARN] orgDomains.ts Org support not enabled for hostname without "." {
agenda  | @calcom/web:start:   hostname: 'localhost:3000'
agenda  | @calcom/web:start: }

Also, when I set confirmation required for a boking, when I click the confirmation link to e-mail message, it confirms properly but redirects to localhost:3000, for example:

Link on email message: https://mydomain.com/api/link/?token=a8b5bc90681fb###############################7d7ef68c&action=accept
Redirect page: https://localhost:3000/booking/u16################T6XS

I am running image calcom/cal.com:main directly, already tried to find the issue on database, eliminated the image and pulled it again but the issue persists.

My docker-compose.yml:

name: agenda

services:
  calcom:
    image: calcom/cal.com:main
    container_name: agenda
    ports:
      - 3000:3000
    env_file: .env
    extra_hosts:
      - host.docker.internal:host-gateway
    restart: unless-stopped

My .env

NEXT_PUBLIC_WEBAPP_URL=https://mydomain.com
ALLOWED_HOSTNAMES='"mydomain.com"'
NEXTAUTH_URL=https://mydomain.com
NEXT_PUBLIC_CONSOLE_URL=https://mydomain.com
NEXT_PUBLIC_APP_URL=https://mydomain.com
NEXT_PUBLIC_WEBSITE_URL=https://mydomain.com
NEXT_PUBLIC_API_V2_URL=http://localhost:5555/api/v2
NEXTAUTH_SECRET=i20O4######################FMYo=
CALENDSO_ENCRYPTION_KEY=54a######################39dc9
POSTGRES_USER=agenda
POSTGRES_PASSWORD=1D######################hI
POSTGRES_DB=agenda
DATABASE_HOST=host.docker.internal:5432
DATABASE_URL=postgresql://${POSTGRES_USER}:${POSTGRES_PASSWORD}@${DATABASE_HOST}/${POSTGRES_DB}
DATABASE_DIRECT_URL=${DATABASE_URL}
GOOGLE_API_CREDENTIALS={"web":{"client_id":"8256######################t8c.apps.googleusercontent.com","project_id":"mydomain","auth_uri":"https://accounts.google.com/o/oauth2/auth","token_uri":"https://oauth2.googleapis.com/token","auth_provider_x509_cert_url":"https://www.googleapis.com/oauth2/v1/certs","client_secret":"G######################su","redirect_uris":["https://mydomain.com/api/integrations/googlecalendar/callback","https://mydomain.com/api/auth/callback/google"]}}
GOOGLE_LOGIN_ENABLED=false
CALCOM_TELEMETRY_DISABLED=1
MS_GRAPH_CLIENT_ID='3f######################ef5'
MS_GRAPH_CLIENT_SECRET='te######################Tn'
EMAIL_FROM='noreply+agenda@mydomain.com'
EMAIL_SERVER_HOST='email-smtp.sa-east-1.amazonaws.com'
EMAIL_SERVER_PORT='587'
EMAIL_SERVER_USER='A######################U'
EMAIL_SERVER_PASSWORD='BG######################Abr'
NODE_ENV=production
NEXT_PUBLIC_APP_NAME='Agenda'
NEXT_PUBLIC_SUPPORT_MAIL_ADDRESS='suporte@mydomain.com'
NEXT_PUBLIC_COMPANY_NAME='mydomain'
VIRTUAL_HOST=mydomain.com
LETSENCRYPT_HOST=mydomain.com

Same here.

Issue persists on version v.5.3.0-sh, my setup requires me to confirm the booking, when I click on confirmation link (example) https://subdomain.example.com/api/link/?token=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&action=accept

It redirects to https://localhost:3000/booking/xxxxxxxxxxxxx.

The booking is confirmed properly, this redirect to localhost happens after confirmation being received and recorded on server.

How could we fix it?

@zomars

Hello @zomars @PeerRich @krumware, can you please help ? :)
Thanks in advance

Error persists on version v.5.3.4-sh

Issue persists on v.5.4.0-sh (Docker image calcom/cal.com:main)

When I set confirmation required for a booking, when I click the confirmation or rejection buttons on e-mail message, it hits server and records properly the action, but redirects to localhost:3000 after that, for example:

Links on email message:
Confirm button: https://mydomain.com/api/link/?token=a8b5bc90681fb###############################7d7ef68c&action=accept
Reject button: https://agenda.icc.gg/api/link/?token=a8b5bc90681fb###############################7d7ef68c&action=reject

Redirect page: https://localhost:3000/booking/u16################T6XS

When I try to follow redirects using httpstatus.io, I get this error, maybe because it hoops directly to localhost because I have no issue with SSL:

write EPROTO 00789EF8477F0000:error:0A00010B:SSL routines:ssl3_get_record:wrong version number:../deps/openssl/openssl/ssl/record/ssl3_record.c:354:

Requesting assignment for this one

Issue persists on v.5.5.0-sh

When I set confirmation required for a booking, when I click the confirmation or rejection buttons on e-mail message, it hits server and records properly the action, but redirects to localhost:3000 after that, for example:

Links on email message:
Confirm button: https://mydomain.com/api/link/?token=a8b5bc90681fb###############################7d7ef68c&action=accept
Reject button: https://mydomain.com/api/link/?token=a8b5bc90681fb###############################7d7ef68c&action=reject

Redirect page: https://localhost:3000/booking/u16################T6XS

Issue persists on v.5.4.19-sh

This is being looked into. There is varying usage of the URL variables in the core code and it looks like the redirect page uses the orgSlug, whilst the other pages use the WEBAPP_URL.
This may be related to: calcom/cal.diy#12201

Hi everyone, I just created this account specifically to post about this issue. First of all, I'd like to clarify that I'm not a developer, programmer, or anything like that, just an engineer delving into AI. So, please excuse me if I say anything technically incorrect or inaccurate, but I hope to contribute something with my comment.

It turns out I've also been trying to get Calcom to work by self-hosting it within a VPS, and I ran into the issue discussed in this thread and other problems pointed out within the community:

—Redirection to localhost:3000 instead of the correct domain.
—[next-auth][error][CLIENT_FETCH_ERROR] message: 'Unexpected token p in JSON at position 4'.
—Match of WEBAPP_URL with ALLOWED_HOSTNAME failed { WEBAPP_URL: 'http://localhost:3000, ALLOWED_HOSTNAMES: [] }

Apparently, the program survives with the last two errors, although it's difficult to be sure without being able to test all its features, but the first error is certainly critical.

Anyway, the point is that I've been deploying the latest version of Calcom, 5.5.1, through Dokploy, but after trying dozens and dozens of different configurations to avoid these errors, I gave up and decided to simply deploy the version that Dokploy includes in its default image, which is 2.7.6. I noticed that when deploying this version, the first thing that appears in the logs is a script:

scripts/replace-placeholder.sh http://localhost:3000/ https://my.domain.com/

With Claude's help I was able to find the file and it says the following:

 1  FROM=$1
 2  TO=$2
 3
 4  if [ "${FROM}" = "${TO}" ]; then
 5      echo "Nothing to replace, the value is already set to ${TO}."
 6
 7      exit 0
 8  fi
 9
10  # Only peform action if $FROM and $TO are different.
11  echo "Replacing all statically built instances of $FROM with $TO."
12
13  find apps/web/.next/ apps/web/public -type f |
14  while read file; do
15      sed -i "s|$FROM|$TO|g" "$file"
16  done

From what I understand, this script is changing all URL instances from localhost:3000 to my.domain.com. Without this script, it seems that all URL variables within Calcom are hardcoded to localhost:3000, regardless of what is specified in the yaml or .env file. I came to this conclusion since I've tried changing WEBAPP_URL a lot of times but I always get WEBAPP_URL: 'http://localhost:3000 doesn't match ALLOWED_HOSTNAME.

At least version 5.5.1 of Calcom doesn't seem to come with this script integrated, and this could explain some of the errors reported in the latest versions.

I would have liked to have tested adding the script to the latest version, but I imagine it will likely need to be tweaked to work properly, considering it was written for a much older version of the program. I'd rather leave that to those more knowledgeable.

I hope this insight is helpful and that someone takes a look into it.

Regards

Thanks for the input.
We're updating the install instructions and reworking the dockerfile.
The above was required to add runtime configurability to the application, which was already compiled to a static site during the docker build. A script like this wouldn't be included in the core Calcom.

You can see the usage here: https://github.com/calcom/docker/blob/main/scripts/start.sh#L6
and then https://github.com/calcom/docker/blob/main/Dockerfile#L65
Effectively, http://localhost:3000 is the default URL. If the script is run without updating NEXT_PUBLIC_WEBAPP_URL, then you will simply be replacing all usages of http://localhost:3000 with http://localhost:3000.

Unfortunately, there's some new variable complexity, so using the runtime variable replacement may no longer cover all cases.

But regardless, there have been significant updates to the .env.example in the calcom/docker versus the .env.example in the calcom/cal.com repo, and we're working through those changes now. I expect if you selectively merge the calcom/cal.com env file into your calcom/docker's (or at least pull these over: https://github.com/calcom/cal.com/blob/ee073cdf350e605c5ae8ca44211e89fdc5fa7102/.env.example#L69-L72) and then build your own image, you'll have luck here.

That's not a satisfactory thing for users who need to just pull and run the image on their own - which is part of the extra work required to make these images reasonably configurable.

@krumware

Awesome work @krumware !

I am one of these guys that pull image and run it instead of building locally :p one day I will clone the repo and build an image here on github, I do not like to build images in my small server

I am waiting for this solution for months but I understand that's not easy to solve

Thank you again

Thanks for the input. We're updating the install instructions and reworking the dockerfile. The above was required to add runtime configurability to the application, which was already compiled to a static site during the docker build. A script like this wouldn't be included in the core Calcom.

You can see the usage here: https://github.com/calcom/docker/blob/main/scripts/start.sh#L6 and then https://github.com/calcom/docker/blob/main/Dockerfile#L65 Effectively, http://localhost:3000 is the default URL. If the script is run without updating NEXT_PUBLIC_WEBAPP_URL, then you will simply be replacing all usages of http://localhost:3000 with http://localhost:3000.

Unfortunately, there's some new variable complexity, so using the runtime variable replacement may no longer cover all cases.

But regardless, there have been significant updates to the .env.example in the calcom/docker versus the .env.example in the calcom/cal.com repo, and we're working through those changes now. I expect if you selectively merge the calcom/cal.com env file into your calcom/docker's (or at least pull these over: https://github.com/calcom/cal.com/blob/ee073cdf350e605c5ae8ca44211e89fdc5fa7102/.env.example#L69-L72) and then build your own image, you'll have luck here.

That's not a satisfactory thing for users who need to just pull and run the image on their own - which is part of the extra work required to make these images reasonably configurable.

I build locally the image using ALLOWED_HOSTNAMES, RESERVED_SUBDOMAINS variables and got same issue 😢

Fow now I got a workaround rewriting proxy_redirect in my nginx reverse proxy to solve the redirect failure when accept or reject an invite approval 🎉

  location @reverse_proxy {

  ### BEGIN fix redirect cal.com ###
    proxy_redirect https://localhost:3000/ https://mycalcomdomain/;
    proxy_redirect http://localhost:3000/ https://mycalcomdomain/;
  ### END fix redirect cal.com ###

    # ...other proxy settings...
  }

Also, about orgDomains, this solution works fine: #434 (comment)

Navigation Menu

Repository navigation

New NEXT_PUBLIC_WEBAPP_URL not taken over for static files #319

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

New NEXT_PUBLIC_WEBAPP_URL not taken over for static files #319

Description

Activity

tigerblue77 commented on Nov 20, 2024

tigerblue77 commented on Feb 26, 2025

ivancarlosti commented on Mar 14, 2025

itsNeutron commented on Mar 23, 2025

ivancarlosti commented on May 15, 2025

tigerblue77 commented on May 16, 2025

ivancarlosti commented on May 26, 2025

ivancarlosti commented on Jun 16, 2025

krumware commented on Jun 16, 2025

ivancarlosti commented on Jun 30, 2025

ivancarlosti commented on Jul 11, 2025

krumware commented on Jul 11, 2025

raulakio commented on Jul 28, 2025

krumware commented on Jul 28, 2025

ivancarlosti commented on Jul 30, 2025

ivancarlosti commented on Aug 5, 2025

ivancarlosti commented on Aug 6, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions