When to generate a new Application Key in Laravel?

Question

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 ?

Solution 1

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.

Solution 2

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.

Comments

[johnRivs]

@tino.codes Incorrect. APP_KEY has nothing to do with hashing. Read more: tighten.co/blog/app-key-and-you

[tino.codes]

@johnRivs you're absolutely right. Four years ago I still believed this myth.

[code-8]

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 ?

[Tim Lewis]

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.

[code-8]

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 ?

[Tim Lewis]

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.

[code-8]

Thank-you. You seemed to answer all the doubt that I have about php artisan key:generate

[Tim Lewis]

No problem. Glad I could help!

[R0b1n]

what if we commit .env file?

[Tim Lewis]

@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.

[Adam]

What is the idea behind that auto-generated key? Whats the whole point?

[Tim Lewis]

@Adam You can see here what the Application Key is used for: laravel.com/docs/7.x/installation (scroll down a little). It's used for session data, encryption, etc etc.

[Adem Tepe]

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?

[Tim Lewis]

@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.

[Damilare Koiki]

This worked for me 1) composer update 2) composer install 3) php artisan key:generate It worked, thanks