<@U02BS9YFFL7> do we want to include any specific ...
# docker
c
@zomars do we want to include any specific default values for NEXTAUTH_SECRET or CALENDSO_ENCRYPTION_KEY? Also, for CALCOM_LICENSE_KEY is there a default license we should use on the base image, for tracking purposes? or just leave it blank?
z
• No default values • And blank license key
Each user should generate their own
And if you're not planning to use enterprise features there's no need to use a license key
c
If we don't use some sort of default for the next_auth and encryption_key then the image won't build. If I just pick a random value like
secret
will that work ok for image pulling for demonstration/trialing?
z
It could yeah. I think it fallback to ‘secret’
c
👍 I'll roll with that
@zomars is CALCOM_LICENSE_KEY required for build time, or only runtime? (or both)
might be obvious, just doing a sanity check
z
I... don't think it's needed at build time
c
here's what I have for build-time var requirments:
i'm sure someone will ask about the functional difference between nextauth_secret and calendso_encryption_key
for runtime, I have
Copy code
* CALCOM_LICENSE_KEY
* NEXTAUTH_SECRET
* DATABASE_URL
z
the first is for cookie encryption, the second is to encrypt saved credentials in the DB
c
awesome, thanks for the clarification
tagged you for review but I can pull it manually if needed https://github.com/calcom/docker/pull/131
1
interesting on the telemetry key, I hadn't caught that. Referencing its removal from .env.example, if users do want telemetry, can they still use the NEXT_PUBLIC_TELEMETRY_KEY to embed their own key or is the key hardcoded now?
z
It is hardcoded, that telemetry was intended to report usage to
<http://cal.com|cal.com>
for bookings, etc. We may enable telemetry for third parties in the future as an enterprise feature
c
ok cool, I'll get that updated
good to go for a final review @zomars
1