When you create a new laravel project using composer create-project laravel/laravel, composer will generate an app key for your app after renaming .env.example to .env and write it as the value for APP_KEY. IF you install by another means, this key may not get generated and you will get the ‘no supported encrypter found’ error. This will make you like many others before you very unhappy.
The good news is that this problem is easily fixed. To manually generate it, just run php artisan key:generate and you’re all set. However, if you are using Laravel Forge or Envoyer or, perhaps, DeployBot, you need to be sure that your .env file can be read. Since we know it’s bad juju to store our .env file in a source control repository, we have to get that file into our /public folder somehow. Let’s start with Forge.
You have two choices to get your production .env file onto your Forge server. The first is to copy the file over and the second is to use the forge interface. Using the interface is super convenient and once added can be edited directly. Log in and navigate to your server and click the icon under Manage. Then choose the tab labeled Environment and click the button labeled Edit Environment. Paste your varables into the overlay and click save. Your changes will be saved to your project’s root as .env. You’re all set.
If you use Forge, chances are you may decide you want a more fully featured deployment solution. That’s where Envoyer comes in. Like Forge, you can manage your environment variables directly from the interface. And, really, if you’re using Envoyer this becomes compulsory. More about that in a second. First, lets get our varialbes stored. From your dashboard, click the Servers tab and then the Manage Environment button. You will be prompted for a key. If this is the first time you’ve accessed it, you supply the key so create a password and save it and then enter it in box provided. You will then be able to paste in your variables and save them. When you do, you will see that they are being synced to the server(s) you specified.
Now, when you deploy, your .env file will be symlinked into your /current folder and you should be all set. Unlike Forge, the deployment has to happen because your .env file is stored one level below /current just like /storage and is the symlinked to /current. I actually learned this the hard way and that’s why I’m sharing it with you today. Watch the video series Taylor Otwell did on Laracasts for all of the details about using Envoyer.
I’ve seen some people saying they like DeployBot, so I’ll throw that in here for good measure. When you set up your server, you’ll go through a long checkilist of items relative to your deployment. During this process you’ll be given the option to include a previously uploaded file or create one on the spot. You can either create a file with the name .env or upload your production .env from your computer. If you do the former, be prepared to start from the beginning when stetting up your deployment and you are not referred back to the set up process gracefully after creating your file. Which brings up another note, DeployBot takes some configuration work on your part–especially if use or have tried Forge. But, you get one repository for free if you’re willing to put in the effort.
Oh come on, just don’t. The tools available today make doing this foolish. Forget about all the nags you hear about security. The time savings you get with having automatic deployments is substantial. Plus, if you use Envoyer you get to deploy with zero downtime. If you still feel like you want to push a button, that’s fine too. You don’t have to turn on automatic deployments for any of the services listed about. You can always push a button or use an API. If there are more than one of you pushing to your production branch, automatic deployment can be annoying at best and dangerous at worst.
Do you use a continuous deployment service other than those listed above? We’d love to hear about how well you think it works for your Laravel projects!