I've dug into the licensing internals again, and I tried to solve this problem already in the past:
// Store license status indexed by fingerprint hash to support common WordPress
// deployment workflows where sites get pushed between prod/staging/dev environments.
// This way, each environment maintains its own valid license status without requiring
// reactivation when moving between environments.
// In practice, this allows one WordPress database to hold license status for production and staging.
// We use a fingerprint because the plain domain name is likely to be overwritten by hosting companies
// "search and replace" scripts during migrations.
$all_activations[fingerprintBlake2b($fingerprint)] = [
'first_connected' => time(),
// Connection key can't be used for "write actions".
// It's not sensitive and only used for potential reconciliation.
'connection_key' => $response_body['connection_key'],
// Store the original fingerprint as well,
// so that we could later display which "domains" have been activated on this site.
// Though note that this can change during "search and replace scripts",
// so we will need to match it against the array index key.
'maybe_original_fingerprint' => $fingerprint,
];
How it's supposed to work ideally:
You activate the license once, on dev.domain.com , your wp_options commandui_activations now has the license information for that domain.
Now, you push to staging.domain.com, and there is no license information yet, but you should be able to activate the new domain (either via wp-cli, or in the settings) without adding a new license key, or changing anything inside the license server dashboard.
Thats the theory, at least. Maybe some information is getting lost inside the staging/dev pushes, or the database is not pushed?
It would be helpful if you can provide the content of the commandui_activations option after a staging push.
