107

Since it automatically sets it for me in my .env file when I create the app, I'm not sure when I should run it.

In addition to that, if a second developer comes in, and clones the app, does he/she need to run php artisan key:generate ?

How do we know exactly when to run php artisan key:generate ?

Kevin fu
  • 222
  • 1
  • 4
  • 16
code-8
  • 54,650
  • 106
  • 352
  • 604
  • 3
    @tino.codes Incorrect. `APP_KEY` has nothing to do with hashing. Read more: https://tighten.co/blog/app-key-and-you – johnRivs Jul 13 '19 at 06:17
  • @johnRivs you're absolutely right. Four years ago I still believed this myth. – tino.codes Jul 16 '19 at 09:20
  • 1
    By default the `APP_KEY` is used within the `PasswordBrokerManager` class that comes with Laravel. If I am not incorrect, this is used for generating hashes for password recovery mails and validating these. If this is correct, all your active password links becomes invalid the second you generate a new application key. Not a big problem, but good to know. – Andrew Larsen Sep 06 '22 at 21:39

3 Answers3

158

php artisan key:generate is a command that sets the APP_KEY value in your .env file. By default, this command is run following a composer create-project laravel/laravel command. If you use a version control system like git to manage your project for development, calling git push ... will push a copy of your Laravel project to wherever it is going, but will not include your .env file. Therefore, if someone clones your project using git clone ... they will have to manually enter php artisan key:generate for their app to function correctly.

So, TL:DR the only time you need to call php artisan key:generate is following a clone of a pre-created Laravel project.

Side note: If you try to run a Laravel project with your APP_KEY set to SomeRandomString (which is the default in your .env.example file, you will actually get an error:

No supported encrypter found. The cipher and / or key length are invalid.

shock_gone_wild
  • 6,700
  • 4
  • 28
  • 52
Tim Lewis
  • 27,813
  • 13
  • 73
  • 102
  • Thanks a lot for your explanation. So with that being said, developer A and developer B might have different `APP_KEY` Will that be a problem in the future ? – code-8 Oct 27 '15 at 14:12
  • 1
    I don't believe so, but it is entirely possible. That being said, I haven't seen any cases in my year+ of development with Laravel. – Tim Lewis Oct 27 '15 at 14:14
  • That's fair enough for me. One last question, is it okay if Developer B leave that `APP_KEY` blank after cloning the project. Is it a big deal to leave that blank ? – code-8 Oct 27 '15 at 14:17
  • 1
    I just added a "Side Note" for that question. The answer is no, you will not be able to run the project without a key. – Tim Lewis Oct 27 '15 at 14:17
  • Thank-you. You seemed to answer all the doubt that I have about `php artisan key:generate` – code-8 Oct 27 '15 at 14:18
  • No problem. Glad I could help! – Tim Lewis Oct 27 '15 at 14:19
  • what if we commit .env file? – R0b1n May 24 '20 at 09:04
  • 1
    @Maven97 It's not a good idea to commit your `.env` file (unless you're 100% certain that the information contained within it is secure/you don't mind people seeing keys/passwords, etc), but if you do, then you don't need to call this command. – Tim Lewis May 25 '20 at 13:34
  • What is the idea behind that auto-generated key? Whats the whole point? – Adam Jul 27 '20 at 18:40
  • @Adam You can see here what the Application Key is used for: https://laravel.com/docs/7.x/installation (scroll down a little). It's used for session data, encryption, etc etc. – Tim Lewis Jul 27 '20 at 18:42
  • I want to ask about the opposite situation of the first comment: is it ok if developer A and developer B use the same APP_KEY? Would it be problem if I put it in .env.example file? – Adem Tepe Feb 07 '21 at 13:36
  • 2
    @AdemTepe Two developers can use the same APP_KEY, that's fine, and will actually allow sharing data between their two local databases (i.e. if one is corrupted, a restore from the other should work without modification). I'd still advise against putting it in `.env.example` though, simply for security reasons. An external storage, like AWS Secret Manager or similar, is a better solution for shared configuration like keys and whatnot. – Tim Lewis Feb 07 '21 at 19:50
  • @Adam, the generated APP_KEY can also be add in the app\config\app.php so even it is push it gitlab or github, it will not be needed again to generate as I know all ENV variables should also exist in config folder so there would no need for .env file in the production – espongha Jun 02 '22 at 06:56
  • ^ There's a lot wrong about that comment; putting the `APP_KEY` that's defined in `.env`, or any variable that is in `.env` that gets pulled into `config()` directly into their `config/{file}.php` counterpart is a gaping security hole. The point of putting things into `.env` and then pulling them to `config` is to prevent passwords/keys from being directly committed to the repo. Please don't do that unless you aren't concerned with security of those variables. – Tim Lewis Jun 02 '22 at 13:45
  • 2
    yes agree with Tim Lewis, you should never put environment variables in version control. – Adam Jun 03 '22 at 19:28
  • Yes agree with Tim lewis – Ishtiaq Ahmed Dec 09 '22 at 22:17
11

The most important thing to do when cloning a laravel project is to first run composer update then composer install. The composer install command installs any required dependencies for that laravel app.

The steps I took to clone a laravel project required the php artisan key:generate command. I can see in my .env file that there is an updated APP_KEY=base64:xxxxxxxxxxxxxxxxxxxx after running this command.

Erich Meissner
  • 205
  • 2
  • 5
  • 3
    This worked for me 1) composer update 2) composer install 3) php artisan key:generate It worked, thanks – Damilare Koiki Jan 04 '22 at 13:12
  • With a full stack Laravel app it's 1) git clone 2) composer update 3) composer install 4) php artisan key:generate 5) php artisan migrate --seed 6) npm install 7) npm run dev – Nilpo Oct 11 '22 at 13:33
  • @Nilpo `composer update` will potentially change the version of Composer itself, which could end up causing issues - so use with caution especially in cases where old code is still in use and the required version of Composer is fixed in the project config... – Peter Kionga-Kamau Feb 25 '23 at 16:42
8

If you need to generate a key manually, you can do so from any Laravel/artisan-enabled php cli using php artisan key:generate --show (supposedly this will not modify any of your existing settings). Then you can use that key string in your config (however you have your secrets saved). I.e. you don't need to run php artisan key:generate on the server you are setting up (this can be useful if you're deploying a docker image to a container host like Heroku or AWS App Runner.

Peter Kionga-Kamau
  • 6,504
  • 2
  • 17
  • 13