natcave's avatar
Level 10

How can Mix use different production environment variables?

I set up 2 simple pusher channel apps, 1 for dev and 1 for production.

.env

PUSHER_APP_ID=pusher_app_id
PUSHER_APP_KEY=pusher_app_key
PUSHER_APP_SECRET=pusher_app_secret
PUSHER_APP_CLUSTER=pusher_app_cluster

MIX_PUSHER_APP_KEY="${PUSHER_APP_KEY}"
MIX_PUSHER_APP_CLUSTER="${PUSHER_APP_CLUSTER}"

bootstrap.js

import Echo from 'laravel-echo'

window.Pusher = require('pusher-js');

window.Echo = new Echo({
    broadcaster: 'pusher',
    key: process.env.MIX_PUSHER_APP_KEY,
    cluster: process.env.MIX_PUSHER_APP_CLUSTER,
    encrypted: true
});

This worked fine in dev, but when I compile and push up to production it keeps the dev .env file variable values.

Can someone tell me how to get mix to keep using the dev .env file variable values in dev but then use production .env file variable values in production?

I have a hunch the solution lies with npm run production and npm run dev and I may need to add some code to webpack.mix.js , but I'm not sure. I'm hoping someone ran into this issue already and can let me know.

Thanks!

0 likes
6 replies
diepaul's avatar

Ran into the same propblem. Have you found any solution so far?

eresources's avatar

I'm having the same issue and was wondering what the "official" solution to this is. I think one way to handle it would be to have separate .env files for dev and production, and then use a package like the following to switch between them based on what you're building for.

https://laravel-mix.com/extensions/env-file

The other option is to just use your production endpoint for Pusher, but prefix all channels with "local-" if you're running on local development. This would ensure that your local testing won't interact inadvertently with any of your live channels. Since Pusher bills you based on your account and not per app, it really doesn't matter if you use production or dev environments for testing.

1 like
JeffreyWay's avatar

Compile Mix on your production server, as part of your deploy.

3 likes
eresources's avatar

There are some reasons why we don't do this, but it is definitely another viable option. I actually just set up the laravel-mix env extension and it's working perfectly. A few lines of code and you get to choose which env to set for which build type.

chriscalifornia88's avatar

I did it this way:

Import Echo into a global variable in app js:

window DOT LaravelEcho = require('laravel-echo/dist/echo DOT common');

and then initialize Echo in your template:

<script>
    let Echo = new LaravelEcho({
        broadcaster: 'pusher',
        key: "{{ env('PUSHER_APP_KEY') }}",
        cluster: "{{ env('PUSHER_APP_CLUSTER') }}",
        forceTLS: true
    });
</script>

Sorry for the weird formatting. The comment box is detecting any dots as URLs, and blocking them.

matiaslauriti's avatar

@eresources You should not be doing so, because you are sharing production (or other important keys) and storing them in your Repository, so anyone can see that... You must compile on the server or somewhere else (a CI/CD tool) so you have jobs to compile files and they will use the right key depending on what job is running, hence what key secret value it is going to use...

Please or to participate in this conversation.