Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
Hi all!
I'm building a new project for my workplace which uses a little bit of reverb. I've been building it on a local/dev server which is working great, and I'm now trying to nail down and document the setup process for a production server. My hope is to have a process documented, effectively (but obviously not exhaustively..):
composer installWhere I'm getting stuck currently is with how the production server will get its config for reverb.
So obviously the git repo won't have an active .env file so none of the REVERB_APP_ID, REVERB_APP_KEY, etc values will be set, and neither will it have the reverb.pem certificate file. I haven't been able to figure out how to get these generated fresh for a new production server.
I've tried running php artisan install:broadcasting --reverb (on my example "prod" instance), but from what I can see it doesn't seem to be generating a new certificate or filling out the .env values. (possibly because the broadcast.php config file already exists, and/or the composer dependency already exists)?
Am I going about this the wrong way? What would be the correct way to have Reverb configured on a (let's assume "fresh") production server?
Thanks!
If you need the installation to be automatic with script executing each step one by one, you can write bash script and generate the reverb environment values from it.
I already did this with a project with Laravel and docker, the bash script executed all commands.
Use a service like Doppler to store your ENV configurations and then pull those values in with the CLI tool as part of the build/deployment pipeline.
This kind of setup can (and should) then be used for all of your ENV vars for the application, with the benefit of being able to configure vars for different environments (and different developers for local dev).. also helps you share those local version ENV vars with devs in the team.
Thanks for the replies.
I don't necessarily need it fully scripted/pipelined - just documented for the next guy, mainly in the eventuality that they need to re-build the web server for some reason (were not using docker or anything like that at this stage).
I guess my question is really "Am I supposed to use the same Reverb config on both my dev and prod servers?" - If not, how do I get a new config generated on the prod server?
Obviously I can simply specify that the dev .ENV variables and the reverb.pem file just need to be stored/set on the prod server and that would work (and could be done via something like Doppler). But if I should be able to have separate configs, I am just struggling to get a new config generated...
(Note: I thought that maybe, on the prod server, after cloning the repo and doing composer install, etc, that running php artisan install:broadcasting --reverb or php artisan install:broadcasting --reverb --force would do a fresh setup (set new .ENV variables and generate a new reverb.pem file), but at least on the "prod" server that I'm working this out on, that doesn't seem to be doing anything. So at this stage I am leaning towards just re-using the dev config, but I wanted to check if that is the expected process or not..)
I personally wouldn't use the same credentials for local dev and production. That's asking for trouble at some point.
Looking in the source code for Reverb, this is what Laravel uses on install:
$appId = random_int(100_000, 999_999);
$appKey = Str::lower(Str::random(20));
$appSecret = Str::lower(Str::random(20));
You can set whatever random values you like.. there's nothing "clever" involved with this.. the broadcast:install command uses the above and then adds these to you're .env file with a standard read/write process.
Thanks @ian_h, that's perfect. I had a look too, and realised that the private key I was worried about was likely from a tutorial that I was following when I first started playing with reverb, so I think I can ignore that, and I'll just document the actual ENV variables that are needed, keeping in mind the format that they use in the source code.
Cheers!
Please or to participate in this conversation.