Setting up a local LAMP development environment on elementary OS

A local LAMP development environment on elementary OS gives you a private place to build and test websites before they meet a public server. It combines Linux, Apache, a MySQL-compatible database and PHP, covering the common needs of a small business site, content management system, dashboard or API. Running that path on your own machine removes hosting fees during development and makes iteration fast while preserving the familiar workflow you will later deploy.

elementary OS is a good base for this because it keeps the desktop approachable while exposing the full Ubuntu command line underneath. Terminal handles packages and services, a graphical text editor handles configuration, and the Files app keeps project material easy to find. The polished Pantheon desktop remains useful for ordinary work, so students, freelance developers and community contributors can use one machine for coursework, client work and tinkering without moving to a separate technical setup.

A useful setup is repeatable rather than a pile of half-remembered clicks. You should know which services run, where their settings live, how Apache reaches your code and how PHP finds the database. Local credentials, ports and permissions deserve deliberate treatment because a workstation may tolerate loose security that would cause trouble on a shared or production host.

Australian conditions add a few useful wrinkles. A busy NBN line may share household traffic during afternoon downloads, while Fixed Wireless or satellite service in regional Australia can make large updates slower, so substantial package fetches are easier outside peak periods. Server clocks should use an Australian IANA time zone and account for daylight saving. Community posts may say “arvo” or “no worries” without causing alarm, but timestamp errors in a deployment log certainly can.

What the LAMP stack provides

The letters describe four cooperating layers. Linux hosts the files, processes and access controls. Apache receives HTTP requests, serves static assets and hands dynamic pages to PHP. PHP executes the application, while MariaDB stores relational data through the MySQL protocol and query language supported by PHP's PDO and mysqli extensions. MariaDB is the usual database package on current Ubuntu releases, so it forms a practical Linux, Apache, MySQL and PHP stack without needing a separate virtual machine.

Everything communicates through local addresses and ports: Apache commonly listens on port 80, MariaDB on 3306 and PHP-FPM on a separate socket or port in some hosting arrangements. A clean local stack lets project.test resolve to 127.0.0.1, keeps test uploads off the internet and ensures one project's database cannot disturb another. The main limitation is that “works locally” does not guarantee “works on the host”. Compare PHP, MariaDB, extensions, document roots and URL-rewrite settings with the target server, and record the differences.

Preparing the desktop for work

Start with housekeeping rather than packages. Save open documents, confirm your user can use sudo, and check free disk space for package caches, dependencies, databases and backups. Update the package index and installed packages from Terminal, which is available from the applications grid. elementary OS is Ubuntu-based, so the package names and service conventions used in Ubuntu documentation apply.

sudo apt update
sudo apt upgrade
sudo apt install git curl unzip build-essential openssl composer

Install supporting tools for Git, Composer packages, archives and compiling source dependencies. Use an Australian IANA zone instead of a manual offset: Brisbane and several eastern states use different daylight-saving rules from Adelaide, while Perth and Darwin do not observe daylight saving at all. timedatectl can show the current clock and apply the correct zone.

sudo timedatectl set-timezone Australia/Brisbane
timedatectl status

Replace Australia/Brisbane with the location that matches your machine, such as Australia/Sydney, Australia/Adelaide, Australia/Perth or Australia/Darwin.

Installing Apache, MariaDB and PHP

Install Apache, MariaDB and PHP with the modules needed by common frameworks. The Apache module allows .php documents to run directly through the local server, while the command-line package supports scripts and Composer.

sudo apt install apache2 mariadb-server php libapache2-mod-php \
  php-cli php-mysql php-mbstring php-xml php-curl

Afterwards, inspect the two managed services. Start and enable them so they return automatically after a reboot, then check their logs if a status command reports a failure. Open http://localhost in the default browser; the Apache landing page proves that the web server is reachable before application code enters the picture.

sudo systemctl enable --now apache2 mariadb
systemctl status apache2 --no-pager
systemctl status mariadb --no-pager
sudo apache2ctl configtest

Serving a project through a local virtual host

The default document root at /var/www/html is suitable for a quick test, but it becomes messy when several applications are in progress. Create a dedicated tree for each application and keep user uploads outside the directory exposed as the public web root. Run sudo mkdir -p /var/www/portfolio/public /var/www/portfolio/src /var/www/portfolio/storage, then assign the project to your account and give Apache group access to the storage directory. This avoids the blunt chmod 777 shortcut.

Give the project a reserved .test hostname and point Apache at its public directory. The directory block permits the project and enables .htaccess overrides for frameworks that need them. Save this configuration as /etc/apache2/sites-available/portfolio.conf.

<VirtualHost *:80>
    ServerName project.test
    DocumentRoot /var/www/portfolio/public

    <Directory /var/www/portfolio/public>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

Add 127.0.0.1 project.test to /etc/hosts with sudoedit /etc/hosts. Then enable the virtual host, validate the syntax and reload Apache only when the test reports no errors.

sudo a2enmod rewrite
sudo a2ensite portfolio.conf
sudo apache2ctl configtest
sudo systemctl reload apache2

Creating the database and PHP connection

Run MariaDB's secure setup before creating application data. Use sudo mariadb-secure-installation, or sudo mysql_secure_installation if that is the command provided by your release, and answer its prompts. Keep the server bound to localhost unless remote access is genuinely required. The root administrative console uses the operating system's authentication, so opening it with sudo mariadb does not require storing the root password in the project.

Create a database and a dedicated application account. Generate a long random password with openssl rand -base64 24, then substitute it in the statement below.

CREATE DATABASE portfolio CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'portfolio_app'@'localhost'
  IDENTIFIED BY 'replace-with-a-long-random-password';
GRANT ALL PRIVILEGES ON portfolio.* TO 'portfolio_app'@'localhost';
EXIT;

Grant only the permissions the application needs on that schema; broad server-wide privileges are unnecessary for a simple site. Store the generated password in a local environment file or password manager, not in a committed PHP file. If the application uses PDO, its connection string should specify the schema and utf8mb4, while the username and password come from environment variables.

Finish by proving that PHP and MariaDB can talk. Run php -m and look for mysqli, pdo_mysql and the Apache module. A temporary phpinfo.php file in the document root can confirm the loaded configuration and timezone; visit it through Apache, then remove it because the page exposes details useful to attackers. Set date.timezone to the matching Australian zone in the active PHP configuration.

Connecting the project to everyday tools

Connect the stack to tools that improve the edit-test loop. VS Code offers PHP highlighting and Git integration, while Composer records PHP dependencies and autoloading rules in composer.json. Initialise a repository, ignore secrets and generated files, and keep a .env file local; the application can load it with a small environment library or variables exported by its launch script. These habits preserve portability when the project moves from a laptop to Australian hosting or a client's server.

When choosing later hosting, compare prices in AUD with any USD billing, remember that GST may apply to imported services, and decide whether a .com.au domain suits the intended audience. Australian providers may quote in AUD and include local support, while global platforms often use USD, so compare the total landed cost rather than the headline rate.

Front-end assets need the same discipline. Keep source files in structured directories, minimise production images and put only files intended for public access under the document root. When a community project needs a consistent photo collection, the organising images in Photos guide can help you select, rename and prepare files before moving chosen copies into public/images. Keep originals elsewhere and avoid exposing an entire camera folder.

Browser developer tools help inspect HTML, CSS, network requests and PHP responses, while the Apache access and error logs show requests that never reached the application. Keep the two views together: a blank browser page usually points toward Apache, the virtual host or file permissions, whereas a server error with valid markup points more often toward PHP or the database. This division saves a lot of blind changes.

Keeping the local server controlled and maintainable

A workstation may sit on café Wi-Fi, a shared office network or a home connection, so expose only what the project needs. Apache is the service that should accept web traffic. If you enable the Uncomulated Firewall, permit OpenSSH before switching it on so you do not sever a remote connection, and add Apache's profile. Keep MariaDB and PHP behind Apache instead of publishing their ports directly.

sudo ufw allow OpenSSH
sudo ufw allow 'Apache Full'
sudo ufw enable
sudo ufw status

Maintenance should be boring and regular. Update packages, review the Apache and MariaDB logs, export valuable test data and check that both services return after a reboot. Run mariadb-dump portfolio > portfolio.sql to create a portable database backup, while Git tracks intentional code changes; neither replaces the other because database contents and source files are different kinds of state.

When something fails, work through the request path in order: Apache service, virtual host and document root, file permissions, PHP module and error log, MariaDB service, then credentials and schema. One change at a time makes the cause visible. This method is particularly useful on a laptop that has been updated, restored from backup or used for several different projects.

A dependable local development environment is defined by a clear request path rather than a particular desktop theme. The browser should reach the intended project, PHP should run the right code, and MariaDB should return only the data that application is allowed to use. Once that path is understood, troubleshooting becomes a matter of locating the first broken link instead of changing everything at once.

The principle to remember is simple: keep services explicit, permissions narrow, credentials out of Git and production-like versions documented. A repeatable local LAMP stack turns each project into a controlled workspace rather than a fragile collection of settings.