calcom
Feature request: Runtime configurability of frontend variables
One of the current restrictions of the cal.com project is the embedding of variables like the NEXT_PUBLIC_WEBAPP_URL strictly into the static build. For CDN-based deployments or other managed deployment mechanisms like Vercel, this is acceptable and helpful. But for container-based and other selfhosted workloads, this adds complexity to the deployment pipeline. It is understood that the usage of the type of next.js variables that require a static build are advantageous to site speed, but the problem is still relevant and limits the usability/deployability of the software.
Currently the build flow is as follows:
- Check out this repository
- Change variables
- Set up a database
- Build an image
- Push the image to an image registry (requiring its own hosting)
- Set up deployment with configured variables & custom registry/image:tag path, which pulls and runs image
Desired flow would be as follows
- Set up deployment with configured variables & official registry/image:tag path, which pulls and runs image
Currently the desired flow is only available for running localhost, or by running the react dev server.
Other restrictions to account for:
- Building the static site at runtime creates multi-instance scalability and potential file share/hashing challenges
- Building the static site at runtime requires too many resources
- Building the static site at runtime requires too long of a startup time
This is an often-requested feature, created this for easier tracking by the core team
I added a simple PR to attempt to fix this issue (#162). This fix does not require the site to be built at runtime, it simply does a string search and replace for placeholder value in the pre-built static files (fast).
This only addresses the NEXT_PUBLIC_WEBAPP_URL variable specifically. NEXT_PUBLIC_LICENSE_CONSENT still needs to be set to "agree" at build-time, as there is no easy way to auto-replace this value at runtime. I don't believe there are any other frontend variables that could/should be addressed as well?
Feedback appreciated.
