Add Shared Databases Across Environments to Licensing - #796
Open
djigoio wants to merge 2 commits into
Open
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
dstockton
reviewed
Aug 3, 2026
|
|
||
| ### Shared Databases Across Environments | ||
|
|
||
| Some deployment pipelines deploy a release to a preprod environment first, then promote the same release to production — both pointed at the same database, but with different `PUBLIC_URL` values. |
Contributor
There was a problem hiding this comment.
This reads like a very specific deployment problem. Should it be at the bottom of the page in a troubleshooting section or similar rather than here?
Member
Author
There was a problem hiding this comment.
Added a new troubleshooting section in the next commit 👍
|
|
||
| Since a license binds to your project (stored in the database) and its `PUBLIC_URL` (set per environment), using a **different `LICENSE_KEY` in each environment** causes the binding to conflict: whichever environment starts second will try to rebind the shared project to its own key and URL, and the licensing service will reject it. | ||
|
|
||
| Use the **same `LICENSE_KEY` value** across every environment that shares a database, varying only `PUBLIC_URL`. This is the same multi-activation model described above — each environment registers its own binding for its own URL, under one key. |
Contributor
There was a problem hiding this comment.
This reads confusingly to me... the first sentence almost infers the opposite (it's possible).
| 4. Start the other environment. With no license data left in the database, it activates fresh. | ||
|
|
||
| ::callout{icon="i-lucide-triangle-alert" color="warning"} | ||
| Don't clear `license_key` directly in the database to work around a binding conflict. This leaves the old activation stranded on the licensing service, still counted against your activation limit. Always deactivate through the Studio or API first. |
dstockton
reviewed
Aug 3, 2026
|
|
||
| Set the license through the `LICENSE_KEY` (or `LICENSE_TOKEN`) environment variable at the service or task level so that every replica inherits the same value automatically. New containers spun up by autoscaling pick up the license on start without any manual setup or per-container retrieval. | ||
|
|
||
| Using a different `LICENSE_KEY` per environment against a shared database causes the environments' bindings to conflict. See [Troubleshooting](#troubleshooting) below. |
Contributor
There was a problem hiding this comment.
It's very implementation detail specific. Are you sure we don't want to simply say...
Suggested change
| Using a different `LICENSE_KEY` per environment against a shared database causes the environments' bindings to conflict. See [Troubleshooting](#troubleshooting) below. | |
| Using separate `LICENSE_KEY`s but different `PUBLIC_URL`s with a shared database is not supported. See [Troubleshooting](#troubleshooting) below. |
|
|
||
| ## Troubleshooting | ||
|
|
||
| ### Binding conflicts across shared-database environments |
Contributor
There was a problem hiding this comment.
Does a customer know what a binding is? It sounds like internal implementation/AI language?
|
|
||
| ### Binding conflicts across shared-database environments | ||
|
|
||
| If environments that share a database are configured with **different** `LICENSE_KEY` values, whichever environment starts second tries to rebind the shared project to its own key and `PUBLIC_URL`. The licensing service rejects this, and that environment fails to start with a binding error. |
Contributor
There was a problem hiding this comment.
The licensing service rejects this this is very internal implementation specific language. The docs should be customer-facing language IMO
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Documents a shared-database deployment scenario (e.g. preprod-then-promote pipelines) where using different LICENSE_KEY values across environments pointed at the same database causes a license binding conflict. Adds guidance to use one key per shared database, plus recovery steps for instances already stuck in this state.