If you work with the PHP Framework Laravel, you know that installing your application in a default directory of a VPS account or a shared server, without changes, will force you to run the application leaving the root directory as it will need to access it by the subdirectory /public. For example: http://mydomain.com/public

In case of access to the root directory, in this example, the Laravel program PHP files will be exposed and accessible, including your setting file of environmental variables: .env, with database keys and passwords and APIs services.

You have some options to solve this problem, I will explain below according to the context of the server where you should perform the deploy, that is, the installation.

Installing Laravel PHP Application in Linux Cpanel server subdirectory

This is the option that I consider more secure and easier to perform to configure the entire production environment of your Laravel application to install it in a subdirectory when you have SSH Root access to the Linux server with CPANEL (or another server manager).

The goal is to change the configuration of the primary domain or main domain of the CPANEL USER ACCOUNT, from the conf Apache file of this account.

Follow the steps by changing the correct locations with the account username and the domain:

  1. Locate and open the Apache configuration file to the account user. In the example below change USERNAME by the name of the CPANEL and DOMAIN.COM for the correct domain, in my case would be mazer.dev:
nano /var/cpanel/userdata/USERNAME/DOMAIN.COM
  1. After opening the file look for the line that specifies the path of documentroot. In the following example:
documentroot: /home/USERNAME/public_html
  1. Modify the path of documentroot according to your need, the simplest will be to follow the structure of the Laravel application that installs your files on the “root” path and uses as the entry point the subdirectory /public. In this example I would change to something like the following (do not forget to save the file):
documentroot: /home/USERNAME/public_html/public
  1. Repeat the steps above to the SSL file (which sets up HTTPS secure access). The file name will be the same as step 2, plus _SSL, for example:
nano /var/cpanel/userdata/USERNAME/DOMAIN.COM_SSL
  1. Rebuilds the Apache config and restarts the Apache http service:
/scripts/rebuildhttpdconf
service httpd restart

Changes will be applied immediately, simply clean your web browser cache and force a page refresh!

Install adding .htaccess that points to subdirectory

This is a solution to the cases where you are using a shared server for the web or, for any other reason, has no root SSH access to your server to perform Apache conf settings.

Again, considering that the Laravel application structure installs your files on the “root” path of the application and uses as the input point the subdirectory /public, we will add a .htaccess file to the application root, and enter rules for requests to be redirected by Apache automatically to the subdirectory /public.

Create the file .htaccess on root /public_html with the following content:

<IfModule mod_rewrite.c> 
 RewriteEngine On 
 RewriteRule ^(.*)$ public/$1 [L] 
</IfModule> 

In this way, every requisition from a browser to its root domain will be redirected internally by Apache to /public, transparently without exposing this URL to the browser and without allowing the customer to access the files at the root of the Laravel application.

Conclusions

The strategies I have shown in this article for configuration and installation of Laravel system in production deploy for VPS servers, owners or shared servers do not take into account the need to perform the application in a subdomain or the execution of its application in parallel with another system such as WordPress.

The configurations presented consider a scenario where your entire “site” or system will run on the installation with all components of a single Laravel application.

It is important to note that in both options you will be able to use deploy with Git from the root of the application, respecting the flow of source code versioning of your project.