At , we use to host websites like our , our , and our . While this doesn’t mean we have to use Apache to run the sites locally, using a similar stack for development and production is generally a good idea. This means setting up a development environment with Apache. Tower Apache learning platform blog main product site On macOS, which is what we use, for the most part, there are quite a few options. We could set up Apache in a virtual machine, perhaps controlled using . We could use to run Apache in a container. There are also solutions with graphical user interfaces like . However, a convenient and simple solution is to just set up Apache running natively in macOS — no wrappers, no virtual machines, no containerization. In this post, we’ll go through how to set up Apache and PHP, using versions installed using the for macOS. Vagrant Docker MAMP Homebrew package manager macOS comes with built-in versions of Apache and PHP, and we could easily use those. However, there are a few drawbacks to this approach. We don’t have control over the exact versions used, and the version available might not be up to date. I’ve had problems where OS updates have overwritten my configuration for the built-in Apache server. Finally, running to check the version of the built-in PHP gives a warning message stating that PHP will be removed from future versions of macOS — in fact, in the upcoming macOS Monterey, PHP . Instead of using the built-in versions, we’ll install Apache and PHP using Homebrew. php -v seems to be gone We'll look at how to set up a local development environment using these and, as usual, we’ll try to cover the “why” as well as the “what”; in addition to just presenting the configuration, we'll go over the purpose of each directive and command. Here are the steps we'll take: Installing Apache and PHP Configuring Development URLs Apache Configuration PHP Configuration Virtual Host Setup Up and Running 1. Installation Instructions for how to install Homebrew itself can be found on . Assuming Homebrew is installed, all you need to do in order to install Apache and PHP is to run the following command: ( refers to the Apache webserver). the official Homebrew website brew install httpd php httpd A word regarding paths: on a Mac with Apple Silicon, Homebrew will use as its prefix. The prefix is sort of a base directory; a directory under which Homebrew will put various files belonging to the packages it installs. Binary files will go in , configuration files in , and so on. On an Intel-based Mac, this base directory will likely be instead. /opt/homebrew /opt/homebrew/bin /opt/homebrew/etc/ /usr/local In this article, I’ll refer to paths using a Homebrew prefix of . If your prefix is different, please change the paths accordingly. To find out which base directory Homebrew is using on your machine, run . /opt/homebrew brew --prefix 2. Development URLs Before we get started on Apache and PHP configuration, let’s touch on the topic of development URLs briefly. I think a nice setup for local development is to use a specific TLD like , accessing my various projects through URLs like , , and so on. In this guide we’ll simply use the file to point our “fake” domains at our local web server. If there’s interest, a future post might cover how to set up a service like to automatically grab all requests to hosts ending with and send them to our local development server. .test my-first-project.test my-second-project.test /etc/hosts dnsmasq .test is a reserved top-level domain and so, using this, you shouldn’t run into problems such as the people using for development environments did when TLD. .test .dev Google acquired the .dev The file provides a convenient way to associate hostnames with IP addresses. Normally, when we visit a URL like , the actual IP address of the server has to be determined through something called the Domain Name System, or DNS for short. The file gives us an easy way to override this. /etc/hosts https://www.git-tower.com/ /etc/hosts For the purposes of this article, let’s say we’re working with a project called , which we want served at the URL . We’ll add this line at the bottom of : my-project my-project.test /etc/hosts 127.0.0.1 my-project.test After saving the file, visiting in a browser will result in the request being sent to the IP address for our own machine. my-project.test 3. Apache Configuration Next, let’s get to work on the actual Apache configuration. In my case, the main Apache configuration file is located at (again, on an Intel-based Mac, this is likely to be ). In this file, there are a few changes to make: /opt/homebrew/etc/httpd/httpd.conf /usr/local/etc/httpd/httpd.conf Listen 8080 This line tells Apache to listen for traffic on the port 8080. Accessing ports with numbers lower than 1024 require root privileges and so, listening on port 8080 lets users run Apache without being root. However, as HTTP traffic goes to port 80 by default, we want to listen on that port instead: Listen 80 Chances are, you want to run multiple websites on your computer, with several hostnames in . However, all of these will hit the same Apache server. To serve multiple sites from one Apache server, Apache can look at the hostname of the incoming request and pass the request to one of multiple . Virtual host support has to be enabled by removing the in front of the line below, turning it from a comment into an Apache directive that loads the virtual hosts configuration from the file in question: /etc/hosts virtual hosts # #Include /opt/homebrew/etc/httpd/extra/httpd-vhosts.conf We’ll uncomment another line in order to load the module. This module is used to rewrite incoming URLs. For example, many web frameworks use it to enable “pretty URLs”, letting site visitors use URLs like while translating them into URLs like for the back-end. This module will likely be useful, so let’s enable it by removing the below: mod_rewrite /posts/2021/some-post-title/ /index.php?p=697 # #LoadModule rewrite_module lib/httpd/modules/mod_rewrite.so Apache comes with configuration for a default site, with a document root of . We won’t be using this site, as we’ll use virtual hosts instead. As it stands, everything would work, but Apache would emit a warning every time it started, stating that it can’t determine the hostname to use for this default site. We’ll set the hostname on a per-virtual host basis later. However, to silence the warning message, we’ll uncomment the default directive in (or just enter any hostname you want): /opt/homebrew/var/www ServerName httpd.conf ServerName www.example.com:8080 4. PHP Configuration We want PHP to be available on our server. For this, we’ll add another directive after the other ones, loading a module provided by PHP as installed through Homebrew earlier (on an Intel-based Mac, change to ): LoadModule /opt/homebrew /usr/local LoadModule php_module /opt/homebrew/opt/php/lib/httpd/modules/libphp.so This loads the PHP module. There is some additional configuration required. Let’s add further PHP configuration in a separate file in the directory, just like with the virtual hosts configuration. We need to include it explicitly from the main configuration file, so find the section with Include directives and add this after the last one: extra # PHP settings
Include /opt/homebrew/etc/httpd/extra/httpd-php.conf The rest of our PHP configuration goes in the file : /opt/homebrew/etc/httpd/extra/httpd-php.conf <IfModule php_module> 
  <FilesMatch .php$>
    SetHandler application/x-httpd-php
  </FilesMatch>

  <IfModule dir_module>
    DirectoryIndex index.html index.php
  </IfModule>
</IfModule> We start by checking if the PHP module is available, which might seem redundant as we just added it in the file. However, these files may get edited independently of each other, so let’s follow the convention of the other files in the extra directory and check that the modules we use are available. We’ll look for files ending in , and set their handler to — a handler provided by the PHP module. A handler in Apache represents an action to take for a file. While most files are just served using a built-in handler, the PHP files have to be interpreted by PHP before being served. httpd.conf .php application/x-httpd-php Some guides use the directives here, which take parameters for the file extensions they apply to. These can as they check their configured extensions against every extension of a file. For example, a web application may allow users to upload files. However, if a user uploads a file with a name ending in , this file might be executed as PHP if the above directives are used. Therefore, we use the directive along with . Not that we're likely to encounter these issues when we're running Apache locally for ourselves, but we might as well set things up properly. AddType or AddHandler introduce security issues .jpeg .php.jpeg FilesMatch SetHandler The directive makes sure that if a URL for a directory is requested, and the directory contains an file (or an file), that file will be served. DirectoryIndex index.php index.html 5. Virtual Host Setup We’ve now set up Apache to support PHP and virtual hosts. We still need to add configuration for each virtual host separately. Earlier, we uncommented a line in order to include the file ( on an Intel-based Mac). Now, let’s edit it to actually configure a virtual host. /opt/homebrew/etc/httpd/extra/httpd-vhosts.conf /usr/local/etc/httpd/extra/httpd-vhosts.conf <VirtualHost *:80>
    ServerName my-project.test
    DocumentRoot /path/to/my-project

    <Directory /path/to/my-project>
        Require all granted
        AllowOverride All
    </Directory>
</VirtualHost> This configures a virtual host on port 80. sets the hostname for the virtual site. When we visit in the browser, the change we made to will make sure the request is sent to the local Apache server. Apache will find the virtual host with the corresponding hostname and serve that site. The directive specifies the location on the file system where the files to be served exist. Make sure to change this path, along with the other instance of it in the directive, to the actual path of your website on your machine! ServerName my-project.test /etc/hosts DocumentRoot Directory The directive has to do with permissions. In the file, there’s a section which denies access to any resource by default. Access to anything that should be public has to be specifically allowed. So, for the files in our site root, we give everyone access to all resources through the directive. The directive controls which directives can be overridden in a file. A file can be used for per-directory configuration — many CMSes use this file together with the module mentioned earlier to set up their URLs, for example. Here, we allow all directives to be overridden. Directory httpd.conf Require AllowOverride .htaccess .htaccess mod_rewrite While we’re at it, we can go ahead and remove or comment out the existing dummy virtual hosts existing in this file, otherwise Apache will emit some warnings on startup, as the document roots for these sites likely don’t exist. 6. Up and Running That’s all the configuration done! All that remains is to start the server. If you want Apache to start automatically with your computer, you can use Homebrews’ command to start the server and enable it for autostart at the same time: services sudo brew services start httpd will then both turn off the server and disable autostart for it. sudo brew services stop httpd Personally, I tend to just use Apache’s built-in “server control interface” to start the server as I need it: will start the server and will stop it. sudo apachectl start sudo apachectl stop Hopefully, after starting the server, visiting your chosen hostname in your browser will result in your site being served correctly! That’s about all for today! I hope you found this guide useful. Of course, we’ve only covered Apache and PHP — there are many additions you may want to make to this stack, such as the . If you’re interested in a future article covering this or any other aspect of an Apache-based hosting stack, please ! MySQL database server let us know Also Published Here

Apache

Apple

Google

Intel

Twitter

5 Simple Tips to Become a Better Programmer

How to Really Use Git: 10 Rules to Make Git More Useful

Get Tower, the most powerful Git client for Mac and Windows!

Nominated for 2022 - Software Developer of the Year

Nominated for 2022 - HackerNoon Contributor of the Year - Testing

Nominated for 2022 - HackerNoon Contributor of the Year - Github

Nominated for 2022 - HackerNoon Contributor of the Year - Git

Nominated for 2022 - HackerNoon Contributor of the Year - Product Management

Nominated for 2022 - HackerNoon Contributor of the Year - Php

Nominated for 2022 - HackerNoon Contributor of the Year - Software Engineering

Too Long; Didn't Read

Make resilience your competitive advantage

Setting Up Apache and PHP from Homebrew on macOS

Setting Up Apache and PHP from Homebrew on macOS

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

5 Simple Tips to Become a Better Programmer

8 Essential Maven Plugins Beyond The Core

A Comprehensive Guide to Apache Cassandra Architecture

A Detailed Guide To Using Apache Storm

ACID Transactions Are Coming To Apache Cassandra: Here's Why We're Excited

5 Simple Tips to Become a Better Programmer

8 Essential Maven Plugins Beyond The Core

A Comprehensive Guide to Apache Cassandra Architecture

A Detailed Guide To Using Apache Storm

ACID Transactions Are Coming To Apache Cassandra: Here's Why We're Excited

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps