Laravel Application Environments without Hostnames

Update 4/25: Luke Armstrong pointed out in the comments that I was totally inconsistent in my server variable naming scheme. Thanks for the assist, Luke!

Forgive me if this is old news, but hostname-based environment switching (e.g. myapp.dev is in development mode while myapp.com is production) isn’t as nice as it could be. I like using *.dev for my development environments (for example, this site’s hostname on my laptop is stevegrunwell.dev), but other people I know like  *.development, *.local, etc. The more developers you have working on a project the higher chance you run of the application being run at a variety of hostnames. Perhaps it’s not an issue in a company (where a manager/lead developer can say “hey, we’re using this standard”) but in the open source world it can get out of hand quickly.

Fortunately, Laravel doesn’t force us into using hostname-based environment switching. At work we’ve developed this little workflow, and it seems to be working really well. First, add the following to bootstrap/start.php in the “Detect the Application Environment” section:

This accomplishes two things:

  1. If there’s a APP_ENVIRONMENT value set on the server, use that to determine the environment…
  2. …or if there’s a bootstrap/environment.php file, load that to determine the environment.

Setting the environment as a server variable

Under Apache, setting the variable is as simple as adding the following to your virtual host:

Afterwards, be sure to restart Apache!

Setting the environment via environment.php

First, you’ll want to make sure that environment.php never gets checked into the repository. If it were to get in your production app may suddenly think it’s in development mode and start spewing stack traces everywhere when something goes wrong. Before creating the file, open up your app’s .gitignore file and add:

Excluded? Good. Now create bootstrap/environment.php with the following:

How simple is that? Now, anytime you clone the application, simply define APP_ENVIRONMENT in your vhost or create bootstrap/environment.php and Laravel will automatically pick up on your application environment, no hostnames needed.

10 comments on "Laravel Application Environments without Hostnames"

  1. Luke Armstrong 4 years ago

    Thanks for the article, I understand what you mean, but others may not.

    You mention three different names for this environment variable. “APPLICATION_ENVIRONMENT” “APP_ENVIRONMENT” and “SERVER_ENVIRONMENT”.

    Obviously they should all be the same.

    I’m going to go with calling my variable “APP_ENVIRONMENT” as the function in Laravel to return the environment is called App::environment().

    • Steve 4 years ago

      Yup, you’re totally right. I’ve updated the post, conforming to “APP_ENVIRONMENT” (I agree, I like that one too). Thanks for catching that!

  2. Bijan 4 years ago

    Man, you totally rock! It’s a while that I have set up my sub domains in routes.php and was looking for the best configuration to support production/development domain names in routes.php

  3. Jared Eitnier 4 years ago

    Most people ought to know this but you may want to mention to restart apache after you set the environment in the vhost. Thanks – helped a bunch!

    • Steve 4 years ago

      That’s a very good point. I’ve updated the instructions accordingly, thank you!

  4. Jayant 4 years ago

    Thanks a lot for sharing this. Really helpful!

  5. Robert 3 years ago

    I understand the point here, as I was facing the same situation in defining the environment when staging and production are on the same machine (i.e. same hostname).
    However, the above solution seems to be an either/or situation. Either choose to use the SetEnv or choose to include an environment file. No need for both really.
    The optimal is the environment.php file since it will allow you to run artisan migrate commands without passing in –env.
    That said… if you are going to create a separate file just for the environment, and edit it for every install, then simply edit the start.php file and be done with it. No need for an extra files or editing Apache hosts.

  6. Danquah Bernard White 3 years ago

    Pls, How do i restart Apache on the online domain Server. I am using Cpanel Shared Hosting. Is it really needed?

    • Steve 3 years ago

      That process would be entirely dependent upon your host. It’s possible they’re automatically restarting Apache every few hours, but it may also require filing a ticket requesting that Apache is restarted. I’d recommend doing a quick Google search for “restart Apache +(YOUR SHARED HOST)”, as cPanel installations will vary greatly across hosts.

      As an aside, shared hosting environments usually make application development difficult (you sacrifice performance and control in exchange for major cost savings and not having to maintain the server yourself), so you might consider looking into a Virtual Private Server (VPS). These cost more than shared hosting, but also give you way more flexibility when deploying your application.

Leave a Reply