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

CC BY-SA 4.0
2022-06-16T18:54:17.037Z
2022-06-16T18:54:17.037Z
Darryl Hein
<p>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.</p>
<p><a href="https://craftcms.com/docs/3.x/config/#craft-license-key" rel="nofollow noreferrer">https://craftcms.com/docs/3.x/config/#craft-license-key</a></p>
<p>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.</p>
<p>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.</p>
<p>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.</p>

CC BY-SA 4.0
2022-06-25T08:46:17.930Z
2022-06-25T08:59:30.950Z
2022-06-25T08:59:30.950Z
James White
<p>We're using &quot;atomic&quot; deploys where we symlink to the new version. Each time we do this, Craft thinks it's unlicensed. As we have <code>allowAdminChanges</code> set to <code>false</code>, 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 <code>allowAdminChanges</code> to true again.</p>
<p>In point form, the deploy script:</p>
<ul>
<li>upload files excluding the <code>vendor</code> dir (and others that don't need to be on the server) to server in a new release dir (ie, <code>releases/XXX</code>)</li>
<li>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.</li>
<li>moves the <code>/storage/rebrand</code> folder from the uploaded files from git into the shared (between releases) dir</li>
<li>symlink the <code>/storage</code> and <code>/public/assets</code> dir from shared to their correct places in the current release</li>
<li>copy over the <code>.env</code> file</li>
<li>symlink to the new release</li>
<li>run the following craft commands: <code>craft migrate/all</code>, <code>craft project-config/apply</code> &amp; <code>craft clear-caches/all</code></li>
</ul>
<p>The relevant commands are here: <a href="https://github.com/xmmedia/starter_craft/blob/master/.gitlab-ci.yml#L88-L99" rel="nofollow noreferrer">https://github.com/xmmedia/starter_craft/blob/master/.gitlab-ci.yml#L88-L99</a></p>
<p>Is there a command to reactivate the license from the CLI? Or is there something in that list that's screwing things up?</p>

CC BY-SA 4.0
2022-11-30T22:56:29.547Z
In our case craft is writing over the license file with a completely different license as the first request comes in after deploy. Haven't been able to figure this one out.
Dan
<deployment><license>
Craft loses license after deploy
# Craft loses license after deploy

(Asked by: username_0 on 2022-06-09)

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?

**Tags:** deployment, license

> **Comments:**
> **username_1**: In our case craft is writing over the license file with a completely different license as the first request comes in after deploy. Haven't been able to figure this one out.  

---

## 2 answers

### Answer by username_0 on 2022-06-16. Score: 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 by username_2 on 2022-06-25. Score: 1

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.


---

