Fedora 44 is a strong choice when you want current packages, fast-moving security updates, and a clean base for web workloads. A LAMP stack on Fedora is still one of the most reliable ways to run PHP applications, WordPress sites, internal tools, and classic database-backed web apps, especially when you want a platform that stays close to upstream without dragging around years of stale defaults. On a fresh Fedora server, though, the setup is only “simple” if you know which pieces matter and which shortcuts will come back to bite you later.

That is the part many setup guides skip. They show package installation, maybe a phpinfo() check, and then move on as if every server behaves the same. In production, it never works that neatly. You have SELinux enforcing by default, firewalld active on most installs, PHP running through php-fpm rather than old mod_php behavior, and a database service that should be secured before a single application points at it. Add traffic spikes, permissions mistakes, and missing extensions, and even a perfectly valid command sequence can still leave you staring at a blank page or a 502 error.

This guide takes the practical path. You will install Apache, MariaDB, PHP, and PHP-FPM on Fedora 44, then lock down the obvious exposure points, confirm the services are working, and handle the issues that usually surface in real deployments. The commands are current for Fedora-based systems, while the same principles apply if you later need to reproduce the stack on Ubuntu, Debian, AlmaLinux, or Rocky Linux with package naming changes. Fedora’s documentation confirms MariaDB is installed from the distribution repositories with dnf, and Fedora 44 PHP guidance notes that PHP-FPM is the default way Apache handles PHP rather than legacy mod_php behavior.

If you are building a blog, a client site, or a small production application, this is the kind of setup that keeps life predictable. It is not just about making the stack work. It is about making it work cleanly, securely, and in a way that can survive the first real traffic burst without requiring a midnight rebuild.

What LAMP Means

LAMP stands for Linux, Apache, MariaDB, and PHP. Fedora provides a modern Linux base, Apache serves the HTTP traffic, MariaDB stores relational data, and PHP executes the application logic that powers most traditional CMS and custom PHP apps. Fedora packages PHP in a way that works naturally with PHP-FPM, which is the preferred model for performance and isolation on contemporary systems.

For WordPress, Laravel, Drupal, Joomla, phpMyAdmin, or a custom PHP app, this stack remains familiar and well-supported. It is also easier to troubleshoot than a more layered stack when you are on a time budget and need a stable path from request to database query. That matters in production, where a clean failure is far more useful than a mysterious one.

Before You Start

A fresh server is the best starting point. Update the system first so you are not mixing new packages with old libraries or partially patched dependencies. It is also smart to confirm you have sudo access, a stable hostname, and at least a basic DNS record if the server will be public-facing.

Use these commands to prepare the machine:

sudo dnf upgrade --refresh -y
sudo reboot

After reboot, log back in and confirm the OS release:

cat /etc/fedora-release
uname -r

If this is a remote host, make sure SSH access is working before touching the firewall. That sounds obvious, but it is one of those mistakes that still happens on busy days.

Install Apache

Apache is the web server layer in the stack. Fedora’s Apache package is httpd, and installation is straightforward:

sudo dnf install -y httpd

Enable and start the service:

sudo systemctl enable --now httpd

Check whether it is running:

sudo systemctl status httpd

At this point, Apache should be listening on port 80. If you open the server IP in a browser and see the Apache test page or a default welcome page, that is enough to confirm the service itself is live. Fedora documentation and Fedora-focused setup guides consistently use dnf install httpd and systemctl enable --now httpd as the standard flow.

Useful Apache checks

If Apache does not start, inspect the logs immediately:

sudo journalctl -u httpd -xe
sudo tail -n 50 /var/log/httpd/error_log

You should also check whether another service is already bound to port 80:

sudo ss -ltnp | grep ':80'

That kind of conflict is rare on a fresh Fedora installation, but on reused servers it happens more often than people admit.

Install MariaDB

MariaDB is the database backend in the traditional LAMP stack. Fedora docs recommend installing it from the distribution repositories, and the package name is mariadb-server. Install it like this:

sudo dnf install -y mariadb-server

Then enable and start it:

sudo systemctl enable --now mariadb

Verify the service:

sudo systemctl status mariadb

MariaDB should come up cleanly on local storage without manual initialization on a normal Fedora install. If you need a quick check that the socket is available:

sudo mysql

On modern Fedora/MariaDB setups, root login often works through local socket authentication, so sudo mysql is the right first test. MariaDB documentation notes that mysql_secure_installation still exists, and Fedora discussions confirm it is generally run with sudo rather than by unlocking the system root account.

Secure the database

Run the hardening script next:

sudo mysql_secure_installation

Typical choices for a production server:

• Set a strong root password if the installer asks for one.
• Remove anonymous users.
• Disallow remote root login.
• Remove the test database.
• Reload privilege tables.

The reason is simple: the default installation is meant to be usable, not final. A database open to anonymous access or remote root authentication is a liability waiting for a scanner to find it. Fedora’s MariaDB guidance recommends securing the installation after setup, and MariaDB’s own documentation explains that the tool is designed to remove anonymous users, test databases, and remote root access.

Create an application database

For real applications, avoid using the root database account. Create a dedicated database and user instead:

sudo mysql

Then in the MariaDB shell:

CREATE DATABASE appdb;
CREATE USER 'appuser'@'localhost' IDENTIFIED BY 'StrongPasswordHere';
GRANT ALL PRIVILEGES ON appdb.* TO 'appuser'@'localhost';
FLUSH PRIVILEGES;
EXIT;

That separation matters in production because an application should never need broad database privileges unless there is a very specific reason. If one app is compromised, the damage should stop at that app’s schema.

Install PHP and PHP-FPM

This is where Fedora 44 differs from older “copy-paste” tutorials that still assume mod_php. Fedora 44 guidance indicates PHP-FPM is configured by default, and Apache starts php-fpm through a service dependency when needed. That is a good thing. PHP-FPM gives you better process control, better isolation, and a cleaner path to tuning on busier servers.

Install PHP and common extensions:

sudo dnf install -y php php-fpm php-mysqlnd php-cli php-common php-gd php-mbstring php-xml php-opcache php-json php-curl

Start and enable PHP-FPM:

sudo systemctl enable --now php-fpm

Check its status:

sudo systemctl status php-fpm

If you want to confirm the installed PHP version:

php -v

Fedora package data shows php-fpm as the PHP FastCGI process manager, which is especially useful for busier sites because it scales more cleanly than a simple embedded model.

Why these PHP packages matter

• php-mysqlnd lets PHP talk to MariaDB efficiently.
• php-opcache reduces repeated PHP compilation and helps performance.
• php-xml and php-mbstring are common requirements for CMS platforms.
• php-gd covers image manipulation in many web apps.
• php-curl is useful for APIs, payment gateways, and external integrations.

If you are deploying WordPress, omitting php-mbstring or php-xml is one of those small mistakes that causes outsized frustration later.

Connect Apache to PHP

On Fedora 44, Apache and PHP-FPM work together through the packaged defaults rather than old inline PHP handling. The Fedora 44 documentation and package notes point to PHP-FPM as the current path, and server-side examples show that restarting Apache can be enough once PHP-FPM is in place.

Check whether Apache already has the needed PHP-FPM configuration:

ls /etc/httpd/conf.d/ | grep -E 'php|fpm'

If your installation already provides the correct glue, you may not need custom handler configuration. On a current Fedora system, that is often the case. If you are using a minimal or customized Apache layout, verify that PHP files resolve correctly by creating a test file:

echo '<?php phpinfo(); ?>' | sudo tee /var/www/html/info.php

Then reload Apache:

sudo systemctl restart httpd

Open:

http://your-server-ip/info.php

If the PHP information page appears, PHP execution is working. Remove the file after testing because phpinfo() exposes sensitive configuration details:

sudo rm -f /var/www/html/info.php

That cleanup step is not optional on a public server.

Open the Firewall

Fedora usually ships with firewalld, and that means the stack can be installed perfectly while still being unreachable from the network. The fix is to allow HTTP and HTTPS explicitly. Fedora firewall guidance and Fedora-adjacent configuration references show the standard service-based method using firewall-cmd.

Allow web traffic permanently:

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

Verify the active services:

sudo firewall-cmd --list-services

If you are setting this up on a public server, open only what you need. HTTP and HTTPS are enough for most web workloads. Keep SSH restricted to trusted sources if you can.

Check the zone

Sometimes the interface is attached to a non-default zone. Confirm it:

sudo firewall-cmd --get-active-zones

Then, if needed, apply rules to the correct zone explicitly:

sudo firewall-cmd --permanent --zone=public --add-service=http
sudo firewall-cmd --permanent --zone=public --add-service=https
sudo firewall-cmd --reload

That small detail is easy to miss when you are moving fast.

SELinux Considerations

Fedora’s SELinux defaults are part of what makes it a good server platform, but they also explain why “it works on my machine” sometimes fails on Fedora. When Apache needs to read standard web content under /var/www/html, SELinux typically allows it. Problems show up when you move files into custom directories, mount shared storage, or let PHP write to paths it should not touch.

If you must use custom document roots, label them correctly:

sudo semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?"
sudo restorecon -Rv /srv/www

For writeable application directories, use a more appropriate label rather than disabling SELinux. That is the difference between a controlled exception and an unnecessary reduction in server security.

To inspect denials:

sudo ausearch -m avc -ts recent
sudo journalctl | grep -i avc

A lot of Fedora server issues are not Apache issues at all. They are SELinux policy mismatches that need a proper label change, not a blanket disable.

Production Tuning

A default install is fine for a single test site. Production is different. Under real load, you want to think about process count, memory use, database behavior, caching, and disk latency instead of only whether the service starts.

Apache tuning

If the workload is mostly PHP, keep Apache lean and let PHP-FPM do the heavy lifting. On higher-traffic systems, use event MPM rather than the older prefork-style approach when possible, because it handles connections more efficiently. Fedora examples and older tuning notes show the pattern of aligning Apache with PHP-FPM and tuning worker counts based on hardware capacity.

Useful commands for inspection:

apachectl -M
httpd -V

For performance-sensitive deployments, watch:

• MaxRequestWorkers.
• ServerLimit.
• ThreadsPerChild.
• Keep-alive behavior.
• Compression and caching headers.

The exact values depend on RAM and traffic shape. There is no universal “best” setting. A site that serves mostly static pages behaves very differently from a logged-in CMS with lots of PHP and database calls.

PHP-FPM tuning

PHP-FPM is where you usually win or lose memory efficiency. On a busy server, tune the pool settings in /etc/php-fpm.d/www.conf or your custom pool file. Pay attention to:

• pm = dynamic or pm = ondemand.
• pm.max_children.
• pm.start_servers.
• pm.min_spare_servers.
• pm.max_spare_servers.

If your server has limited RAM, ondemand can reduce idle memory use. If it serves constant traffic, dynamic can respond more smoothly. There is no magic number; profile actual traffic.

You can also enable and tune OPcache in /etc/php.ini or the relevant PHP config directory. OPcache is one of the easiest real-world performance wins for PHP applications because it avoids recompiling scripts on every request.

MariaDB tuning

MariaDB performance is usually about memory and storage more than raw CPU. If the machine is small, avoid over-allocating buffer pools. If it hosts only one application, a well-sized innodb_buffer_pool_size often pays off quickly. For disk-bound systems, SSDs help far more than people expect, especially on write-heavy CMS sites.

Useful tools:

top
htop
vmstat 1
iostat -xz 1
ss -tulpn
mysqladmin processlist

On production servers, these tools tell you where the bottleneck lives before you start guessing.

Common Troubleshooting

This is the part that saves time at 2 a.m. when a deployment “should work” but does not.

Apache starts, but the site fails

Check the Apache error log first:

sudo tail -n 100 /var/log/httpd/error_log

Then verify the virtual host or document root path. A wrong DocumentRoot or typo in a config file is still one of the most common failures.

PHP shows as plain text

That usually means Apache is not passing .php files to PHP-FPM correctly, or the handler configuration is missing. Confirm PHP-FPM is running:

sudo systemctl status php-fpm

Also check Apache modules and config snippets:

apachectl -M
sudo httpd -t

502 Bad Gateway

That is often a PHP-FPM issue, not Apache itself. Check:

sudo journalctl -u php-fpm -xe
sudo tail -n 100 /var/log/php-fpm/error.log

Typical causes include pool misconfiguration, socket permission problems, or an overloaded pool with too few children.

Database connection errors

Confirm MariaDB is active:

sudo systemctl status mariadb

Then test local access:

sudo mysql -u appuser -p -h localhost appdb

If the app cannot connect, check credentials, database name, host permissions, and SELinux labels if the app uses custom socket or data paths.

Firewall blocks the site

Test the local service first:

curl -I http://127.0.0.1

Then test from another machine. If local works but remote does not, the firewall or upstream network is the problem. Recheck firewalld zone assignment and service permissions.

Security Hardening

A functional stack is not enough. A production stack needs guardrails.

• Keep the system updated regularly with dnf upgrade.
• Use strong database passwords and separate application users.
• Remove test files like info.php immediately after checking PHP.
• Keep only required firewall services open.
• Use HTTPS with a valid certificate as soon as the site is public.
• Restrict SSH access when possible.
• Store secrets outside web-readable directories.

For TLS, Certbot is still a common operational choice on Apache-based Linux servers. Even if you later automate certificates another way, the principle remains the same: never leave a public login page, admin panel, or checkout flow on plain HTTP longer than necessary.

You should also be careful with PHP settings in production:

• display_errors = Off.
• Use logging instead.
• Disable risky functions only when you understand application impact.
• Keep file permissions tight, especially for uploads and cache directories.

The goal is not to make the server paranoid. The goal is to make it resilient.

Real-World Use Cases

A Fedora 44 LAMP stack fits a lot of practical jobs.

• WordPress hosting for content sites and SEO projects.
• Internal dashboards for monitoring or reporting.
• Legacy PHP applications that are not ready for containerization.
• Staging environments for testing plugin or theme changes.
• Small business databases with a simple web front end.

For SEO work, this stack is especially useful when you want full control over headers, redirects, logs, and caching behavior. Apache still makes sense when you need readable .htaccess behavior in managed CMS environments or fast per-directory rule changes without reloading a global reverse proxy layer.