Craft loses license after deploy

Question

We're using "atomic" deploys where we symlink to the new version. Each time we do this, Craft thinks it's unlicensed. As we have allowAdminChanges set to false, this requires manually changing the general config file, going through the reactivation process (in the store). Clicking Reactivate resolves the issue and then we can set allowAdminChanges to true again.

In point form, the deploy script:

• upload files excluding the vendor dir (and others that don't need to be on the server) to server in a new release dir (ie, releases/XXX)
• installs composer packages (we would typically do this on the docker instance, but Craft seems to install/make changes within the vendor dir, so that doesn't work, thus we install on directly on the server.
• moves the /storage/rebrand folder from the uploaded files from git into the shared (between releases) dir
• symlink the /storage and /public/assets dir from shared to their correct places in the current release
• copy over the .env file
• symlink to the new release
• run the following craft commands: craft migrate/all, craft project-config/apply & craft clear-caches/all

The relevant commands are here: https://github.com/xmmedia/starter_craft/blob/master/.gitlab-ci.yml#L88-L99

Is there a command to reactivate the license from the CLI? Or is there something in that list that's screwing things up?

Answer 1

The issue is that the config files say solo thus when purchasing or activating the license, it switched to pro. Each time it deploys, it switches back to solo. Changing the config to pro seems to resolve the issue.

Answer 2

If it helps, you can move your Craft license key to environment variable, rather than the licence key file if it's being lost or causing issues with your deployment.

https://craftcms.com/docs/3.x/config/#craft-license-key

Depending on your hosting environment and .env handling, the special characters may cause issues trying to be assigned as a string value, alternatively, you can base64 encode the licence key value (not for security) just so it's an easier string for use in a environment variable but you'd then need to call base64_decode around the value in your web/index.php.

There is a debate that typically the licence.key shouldn't be committed to source control, as it's a sensitive key, but there are various protections i.e. locked to a specific top level domain and in a lot of cases if you are using Git, changes are it's a private repository, but for best practice, keep any keys out of source control is usually a good idea and Craft supports it, it's just not as well known.

Although once the edition is saved in project config it shouldn't really be being lost, providing the state is kept consistent on each deploy.