Laravel Recipe Dangerous & Incorrect behaviour causing APP_KEY regeneration

[Okipa]

Deployer Version

v7.5.4

Target OS

Unbuntu 22.04

Which PHP version are you using?

PHP 8.3

Content of deploy.php or deploy.yaml

<?php

namespace Deployer;

require 'recipe/laravel.php';
require_once 'contrib/npm.php';
require_once 'contrib/cachetool.php';

// Config //////////////////////////////////////////////////////////////////////

set('repository', '****');
set('keep_releases', 3);
set('cachetool_url', 'https://github.com/gordalina/cachetool/releases/latest/download/cachetool.phar');
set('ssh_arguments', ['-o StrictHostKeyChecking=no', '-o UserKnownHostsFile=/dev/null']);
set('new_deployment', false);
add('shared_files', ['auth.json']);
add('shared_dirs', []);
add('writable_dirs', []);

// Hosts ///////////////////////////////////////////////////////////////////////

$envs = [
    'preprod' => [
        'host' => '****',
        'port' => ****,
        'branch' => 'develop',
        'deploy_path' => '****',
        'remote_user' => '****',
        'http_user' => '****',
        'http_group' => '****',
        'private_identity' => '~/.ssh/id_rsa_deployer',
        'cachetool' => '/var/run/php/php8.3-fpm.sock',
    ],
    'production' => [
        'host' => '****',
        'port' => ****,
        'branch' => 'main',
        'deploy_path' => '****',
        'remote_user' => '****',
        'http_user' => '****',
        'http_group' => '****',
        'private_identity' => '~/.ssh/id_rsa_deployer',
        'cachetool' => '/var/run/php/php8.3-fpm.sock',
    ],
];

foreach ($envs as $env => $config) {
    host($env)
        ->setHostname($config['host'])
        ->setPort($config['port'])
        ->setRemoteUser($config['remote_user'])
        ->setDeployPath($config['deploy_path'])
        ->setIdentityFile($config['private_identity'])
        ->set('http_user', $config['http_user'])
        ->set('http_group', $config['http_group'])
        ->set('branch', $config['branch'])
        ->set('cachetool', $config['cachetool']);
}

// Tasks ///////////////////////////////////////////////////////////////////////

task('npm:build', fn () => run('cd {{release_path}} && {{bin/npm}} run prod'));

// Hooks ///////////////////////////////////////////////////////////////////////

after('deploy:vendors', 'npm:install');
after('npm:install', 'npm:build');
after('npm:build', 'artisan:queue:restart');
after('artisan:queue:restart', 'artisan:horizon:terminate');
after('deploy:symlink', 'cachetool:clear:opcache');
after('deploy:failed', 'deploy:unlock');

Steps to reproduce

Deploy to existing server with previous deployer deployements after upgrading the package.

The test if (test('[ ! -f .env ] && [ -f {{dotenv_example}} ]')) in the env.php (command deploy:env) seems to never detect that a .env file already exists as it is a symbolic link.

As a result, the .env.example is never copied but the variable new_deployment is set to true, even if it is not a new deployment. Then the command artisan:create_key does generate a new APP_KEY, which is a very dangerous behavior as it replaces the previous encryption key with no way to retrieve the previous one if no backup has been executed before. Laravel is then not able to decrypt all encrypted data from previous key anymore and the app is totally broken.

I would recommend to improve to the detection of the .env with another condition which verifies if a symbolic link exists. OR to exclude this step from the deployment recipe, as it is rather a environment installation task than a deployment task IMHO.

[antonmedv]

Yes!
Looks like a very serious bug!

Could you please try this task with -e instead?

[ ! -e .env ]

[Okipa]

Yes it works with [ ! -e .env ].

However, would you consider to remove the common deploy:env and the Laravel artisan:create_key tasks from the default recipe ? They are indeed not deployment tasks and should rather be considered as installation tasks, executed manually. It is IMHO to dangerous too automatize and include this behavior during deployment.

[antonmedv]

My motivation for those tasks was to simplify the first deploy and automatically create app key.

Also copy .env.example too.

[jyrkidn]

This change caused in all our projects the key being regenerated, thus invalidating all sessions on every deploy.
Which seems something for a major version instead of minor or patch (and not even being documented in the release notes).

Fix for us was to exclude .env.example from being deployed.

[Okipa]

On my end, I fixed this issue by overriding the deploy:prepare task, to prevent the deploy:env subtask from running.

I really think this new, very risky behavior should be entirely offloaded to a new install task and should not be included in the deployment in any way.

This is far too risky and is a task that every technical lead of a Laravel project knows they must perform when installing the project. Documenting this as an installation task would be much better.

[antonmedv]

I agree. Probable better not to automate this task.

[markovic-nikola]

+1 🐞
Would be nice to see this hot fixed, thank you.

[antonmedv]

Fixed.

[Okipa]

Thanks to you 🙏