"It is unsafe to run Dusk in production." error when trying to deploy

Update: it appears our server updated, so our opcache version was incorrect and seemed to have caused the issue somehow.

How did you fix it? tell me more please.

@fotoizzet so we eventually removed Dusk all together because no matter what we did, our deploy script would fail saying:

It is unsafe to run Dusk in production.

I suppose we could have changed the env variable to be staging or something just for deployment, but that is not ideal.

Even after removing Dusk and all code referencing it it, we kept running into the following error

Class 'Laravel\Dusk\DuskServiceProvider' not found   

We believe the issue was Op-cache, and was related to the fact that our server had automatically updated Op-cache from 7.0 to 7.1.5 a few days prior.

The way we ended up fixing it was to revert our server back to a snapshot before the op-cache update, clear op-cache, and run the deploy script again.

We still need to investigate further this week, but it at least got us back up and running temporarily.

So after getting stuck on this repeatedly, we narrowed down the solution to manually deleting the bootstrap/cache folder on the server

The exception

It is unsafe to run Dusk in production.

means you had Dusk being bootstrapped in your production environment, which means anybody could authenticate any of your users by going through the Dusk routes.

@Deleu, i understand what the exception means, however we had removed ALL traces of Dusk from the application and were still unable to deploy due to the exception. Ultimately our problem had to do with cacheing.

Even still, I had followed the documentation when installing dusk and was only registering the service provider when in staging/local, and was still receiving that error when the env variable was set to "production", which I still find odd.

In our case, this Exception was fired since DuskServiceProvider::classwas missing in config/app.php.

For anyone scratching their head upgrading from 5.4 to 5.5 and getting this error, it was solved for us by adding the dont-discover portion to our composer.json file as detailed here:

https://medium.com/@taylorotwell/package-auto-discovery-in-laravel-5-5-ea9e3ab20518

Sounds like the docs need to be updated, or at least made a little more obvious.

Also, it should be noted, that we kept the same service provider registration as documented in the installation instructions for dusk in 5.4

https://laravel.com/docs/5.4/dusk#installation

In addition of @agencylabs said, also delete bootstrap/cache/package.php

Thanks to @agencylabs for getting my live deploy up and running this morning :)

I was able to get up and running by excluding dusk from autodiscovery. However, after a bit more thought, I think that the real issue here is that dusk doesn't even need to exist on your production deploy. For me, the issue was that in my composer.json I had laravel/dusk (and a few other things) inside the require block, rather than require-dev.

Moving those dev-only packages into require-dev, and making sure my deploy didn't install dev pacakages (composer install --no-dev) sorted this without having to resort to disable auto-discovery for those packages (as well as cutting down on the amount of code deployed to production)

Hope that helps someone else!

Thanks, everyone! I had the same issues after upgrading to Laravel 5.5. Solved with everyone's suggestions here.

To be 100 percent explicit, I added the following to my composer.json:

"extra": {
  "laravel": {
    "dont-discover": [
      "laravel/dusk"
    ]
  }
},

To add to this a bit, I fixed this by adding in a missing .env file to my project root, which was absent after a git clone of my repo on a new machine. This file specified APP_DEBUG=true, effectively telling Dusk that we aren't in the production environment.

@virtualpain The bootstrap/cache has caused me all sorts of pain in the past which is why I added the following to my composer.json

"scripts": {
    "pre-install-cmd": [
        "php -r \"unlink('bootstrap/cache/services.php');\"",
        "php -r \"unlink('bootstrap/cache/config.php');\""
    ]
}

When I add laravel/dusk to my dont-discover array, I am no longer able to run dusk in my local dev environment.

Also, just putting it in the require-dev section and adding --no-dev to the composer install is not an option on Forge when you are deploying for the first time. It isn't until after you've successfully added your repository does it give you the option to edit the Deploy Script.

Am I missing any steps?

I fixed this issue by adding

APP_ENV=local

To the file:

.env

@DominikS1 if you did that on production you've opened up a whole can of worms. It is not safe to run Dusk on production. Anyone could log in as any user of your application using the Dusk routes.

I had the same issue and for some reason my default forge deployment script did not have --no-dev when installing composer dependancies.

Adding APP_ENV=local does not fix this issue. In fact it is dangerous!

I thought that maybe @DominikS1 was saying to set it to local temporarily so that you can get that initial deploy. Since Forge doesn't allow you to edit the deployment script before the first deploy so that you can add --no-dev, this might be a way to get around it. After that initial deploy, you can edit the deployment script and change your APP_ENV to production.

I haven't tried it yet. Waiting for the next time I need to set up a server.

I can now confirm that temporarily setting APP_ENV=local before the initial repository install does not work. I think it overwrites the .env file. I still get the "unsafe in production" error.

So now I'm faced with changing my composer.json to dont-discover dusk (which breaks it for testing locally). Then after the initial repository has been installed, change the deploy script to --no-dev. Then removing the dont-discover on the composer.json.

Anyone find a better way?

For anyone who's still wondering, check the default value in your config/app file. We have a dev server where we do want to enable dusk, however, our deployment script runs composer install before the .env file is generated, and in config/app the env is default to 'production', so we get the it is unsafe to run dusk in production error.

So you either change your deployment script to generate the .env file first or change your default value to local.

PS: obviously don't do this on the real production server.

Thanks @jaewun for the hat-tip on the forge deployment script! I just assumed the forge default settings would be optimized to include this.

You saved me from having to manually remember to comment out the dont-discover section every time I wanted to run Dusk!!!

This helped me catch that the --no-dev flag I had set in an ebextension wasn't working.

If you use EBS try this:

option_settings:
  - namespace:  aws:elasticbeanstalk:container:php:phpini
    option_name: composer_options
    value: --no-dev

Fixed it for me..

.. and development dependencies shouldn't be installed on your production environment in the first place for auto-discovery to initilize.

the method in Amazon's documentation for setting composer_options didn't seem to to work. http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create_deploy_PHP.container.html#php-namespaces

I took the following two steps to solve the problem:

1. Disable auto-discover for Dusk by following https://medium.com/@taylorotwell/package-auto-discovery-in-laravel-5-5-ea9e3ab20518 and .
2. Conditionally load 'Laravel\Dusk\DuskServiceProvider' by environment by following https://mattstauffer.com/blog/conditionally-loading-service-providers-in-laravel-5/

Below is the snippet for Step 2 in the AppServiceProvider.php file

public function register()
{
    if (!$this->app->environment('production')) {
        $this->app->register('Laravel\Dusk\DuskServiceProvider');
    }
}

I had this issue and simply solved it by adding a --no-dev flag to my composer install command in forge deployment script:

composer install --no-interaction --prefer-dist --optimize-autoloader --no-dev

@LEEWILLIS77

composer install --no-dev

is the right solution here

Thanks, this helped!

I was still getting the error when deploying on laravel forge. But removing bootstrap/cache/packages.php solved it.