Apache configuration essentials for Laravel apps

• How to configure Apache for Laravel
• Apache requirements Laravel expects
  • Enable the rewrite module
  • Allow htaccess overrides in the project directory
• Default Laravel htaccess in the public directory
• Apache virtual host for a single Laravel application
  • Adding an https virtual host for Laravel
• Local development virtual host for Laravel
• Multiple Laravel applications on one Apache server
• Serving Laravel from a subdirectory
  • Using an alias for the subdirectory
  • Using htaccess in the main document root
• Apache configuration when you only control htaccess
• Conclusion

How to configure Apache for Laravel

In this guide you will configure Apache so it serves a Laravel application correctly through the public index.php front controller. You will see how this works for a single domain, multiple projects, subdirectories, and shared hosting environments. Everything happens at the Apache level using virtual host files and htaccess rules, not php artisan serve. By the end you can point a browser at your domain and hit Laravel routes without touching the public path in the url.

Apache requirements Laravel expects

Laravel does not need exotic Apache modules, but it does rely heavily on url rewriting and htaccess support. Here is the minimal Apache setup you should have before worrying about virtual hosts.

Enable the rewrite module

On Debian or Ubuntu based systems you usually enable the rewrite module with:

sudo a2enmod rewrite
sudo systemctl reload apache2

Run these commands in the server terminal as a user with sudo access. On other distributions make sure the rewrite module is loaded in the main Apache configuration file, for example /etc/httpd/conf/httpd.conf, using a LoadModule directive. Without rewrite support Laravel routes will not work and every non existing file request will return a raw Apache 404.

Allow htaccess overrides in the project directory

Laravel ships with a public/.htaccess file that contains its rewrite rules. Apache must be allowed to read and use that file. In a typical Debian or Ubuntu configuration you adjust the main directory block inside /etc/apache2/apache2.conf:

<Directory /var/www/>
    Options Indexes FollowSymLinks
    AllowOverride All
    Require all granted
</Directory>

The important line here is AllowOverride All which tells Apache to honor htaccess files under that path. If this is set to None then Laravel rewrite rules will be ignored even if the module is enabled.

If your Laravel project lives somewhere else, for example in /var/www/myapp, you can scope the rule more tightly by adding a dedicated block to apache2.conf or your main Apache config:

<Directory /var/www/myapp/public>
    Options Indexes FollowSymLinks
    AllowOverride All
    Require all granted
</Directory>

Default Laravel htaccess in the public directory

Laravel expects Apache to point to the public directory as the document root. Inside that directory it uses htaccess to route requests into index.php. Create or edit the file public/.htaccess in your Laravel project and put this inside it:

<IfModule mod_rewrite.c>
    RewriteEngine On
 
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^ index.php [L]
</IfModule>

This does three things:

• Turns the rewrite engine on for that directory.
• If the requested path is not an existing directory and not an existing file, it rewrites the request to index.php.
• Lets Apache serve real files and directories directly without touching Laravel.

As long as Apache has AllowOverride All for the public directory and the rewrite module is enabled, you normally do not need to change this file.

Apache virtual host for a single Laravel application

This is the most common production setup: one domain pointing to one Laravel application. The key is to make Apache serve the public directory as the document root, never the project root.

Example virtual host on a Debian or Ubuntu Apache install. Create a new site file such as /etc/apache2/sites-available/example.conf and put this inside it:

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
 
    DocumentRoot /var/www/example/current/public
 
    <Directory /var/www/example/current/public>
        AllowOverride All
        Require all granted
    </Directory>
 
    ErrorLog ${APACHE_LOG_DIR}/example_error.log
    CustomLog ${APACHE_LOG_DIR}/example_access.log combined
</VirtualHost>

Important parts in this configuration:

• You save this virtual host in a site file such as /etc/apache2/sites-available/example.conf and enable it with sudo a2ensite example.conf.
• DocumentRoot points to the Laravel public directory, not to the project root.
• The Directory block for that path allows htaccess so the Laravel rewrite rules are active.
• ServerName and ServerAlias tell Apache which host headers should hit this application.

On Debian or Ubuntu you typically save this file as /etc/apache2/sites-available/example.conf, enable it, then reload:

sudo a2ensite example.conf
sudo systemctl reload apache2

For other distributions the file location and helper commands differ, but the VirtualHost content is the same.

Adding an https virtual host for Laravel

If you have an ssl certificate for your domain, you pair the http virtual host with an https one. The only Laravel specific detail is that the document root and directory rules are identical.

Add a second VirtualHost block to the same site definition file, for example /etc/apache2/sites-available/example.conf:

<VirtualHost *:443>
    ServerName example.com
    ServerAlias www.example.com
 
    DocumentRoot /var/www/example/current/public
 
    <Directory /var/www/example/current/public>
        AllowOverride All
        Require all granted
    </Directory>
 
    SSLEngine on
    SSLCertificateFile    /etc/ssl/certs/example.crt
    SSLCertificateKeyFile /etc/ssl/private/example.key
 
    ErrorLog ${APACHE_LOG_DIR}/example_ssl_error.log
    CustomLog ${APACHE_LOG_DIR}/example_ssl_access.log combined
</VirtualHost>

As long as both virtual hosts share the same document root and directory rules, Laravel does not care whether the request came in over http or https.

Local development virtual host for Laravel

For local work you may want a clean domain like myapp.test instead of using php artisan serve or appending /public to URLs. The structure is almost identical to the production virtual host, just with a development oriented path and domain.

Example on a typical Linux workstation:

Create a new virtual host file such as /etc/apache2/sites-available/myapp.test.conf and place this inside it:

<VirtualHost *:80>
    ServerName myapp.test
 
    DocumentRoot /home/username/dev/myapp/public
 
    <Directory /home/username/dev/myapp/public>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

Enable the site and reload Apache, for example with sudo a2ensite myapp.test.conf and sudo systemctl reload apache2.

Then add an entry to your local hosts file so the domain resolves locally. On Linux and macOS edit /etc/hosts, on Windows edit C:\Windows\System32\drivers\etc\hosts, and add:

127.0.0.1   myapp.test

After reloading Apache you can browse to http://myapp.test and hit your Laravel routes directly.

Multiple Laravel applications on one Apache server

If you host several Laravel projects on the same Apache instance, you usually create one virtual host per domain or subdomain so that each application stays isolated. The only Laravel specific rule stays the same each time: document root must be the public directory.

Example with two applications on the same server, each defined in its own site file under /etc/apache2/sites-available or inside a single vhosts file, depending on your layout:

<VirtualHost *:80>
    ServerName crm.example.com
    DocumentRoot /var/www/crm/current/public
    <Directory /var/www/crm/current/public>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>
 
<VirtualHost *:80>
    ServerName shop.example.com
    DocumentRoot /var/www/shop/current/public
    <Directory /var/www/shop/current/public>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

Each Laravel application is isolated, has its own logs, and can be deployed independently while Apache keeps the rules simple.

Serving Laravel from a subdirectory

Sometimes you cannot dedicate a full domain or subdomain to Laravel. Instead you might need to serve it under a path like example.com/app. Laravel is fine with this as long as Apache routes that path into the public directory.

Using an alias for the subdirectory

A clean approach is to keep the main site document root as is and use an alias for the Laravel path. Edit the existing VirtualHost definition for example.com, usually in /etc/apache2/sites-available/example.conf or the equivalent file, and adjust it like this:

<VirtualHost *:80>
    ServerName example.com
    DocumentRoot /var/www/html
 
    Alias /app /var/www/app/current/public
 
    <Directory /var/www/app/current/public>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

Here is what happens:

• Requests to example.com still hit the main document root /var/www/html.
• Requests whose path starts with slash app are internally mapped to the Laravel public directory.
• The directory block again allows htaccess so the framework rewrite rules run correctly.

Laravel will see the application at the /app path, so route URLs will automatically include that prefix when you use URL helpers.

Using htaccess in the main document root

If you do not want or cannot edit the main virtual host, you can place rewrite rules in the document root htaccess file that forward a specific path to Laravel. This is common when a control panel manages Apache and only exposes htaccess.

Example htaccess placed in the main document root that sends /app requests into Laravel. Create or edit the .htaccess file in your main document root, for example /var/www/html/.htaccess or public_html/.htaccess, and add:

RewriteEngine On
 
RewriteCond %{REQUEST_URI} ^/app
RewriteRule ^app/(.*)$ /app/public/$1 [L]

Combined with the default Laravel htaccess inside the public directory, this lets users access the application at example.com slash app without ever seeing the public segment.

Apache configuration when you only control htaccess

On many shared hosting environments you do not have direct access to Apache virtual host files. Instead you upload files into a document root such as public_html and control behavior with htaccess. You can still run Laravel this way while keeping public as the web entry point.

Assume the host gives you a document root at /home/user/public_html and you have installed Laravel directly inside that directory. You will end up with a public_html/public directory that contains index.php and assets. The goal is to hide the public segment from visitors.

Create or edit /home/user/public_html/.htaccess with rules that pass everything into the Laravel public directory:

RewriteEngine On
 
RewriteCond %{REQUEST_URI} !^/public
RewriteRule ^(.*)$ public/$1 [L]

Then ensure the Laravel public directory keeps its own .htaccess file, using the minimal rules shown earlier. The flow looks like this:

• The root htaccess rewrites all requests to the public directory.
• Once the request lands in public, Laravel rewrite rules send non file and non directory requests to index.php.
• You do not touch or move the framework core files out of their default locations.

If Laravel is installed in a subdirectory of the hosting document root, adjust the target path inside the rule accordingly.

Conclusion

Apache only needs a small amount of configuration to serve a Laravel application correctly. The central idea in every setup is that the document root or rewrite target must always be the Laravel public directory. You can reach that goal with direct virtual host files, alias rules, or htaccess only setups on shared hosting. Once Apache is pointing at public and rewrite support is active, Laravel takes over routing and your application behaves the same in every environment.