DEV Community: SᕼᗩᕼIᗪ KᗩᖇIᗰI

How to Install Moodle 5 on Ubuntu 24.04 (Nginx, PHP 8.3 and PostgreSQL)

SᕼᗩᕼIᗪ KᗩᖇIᗰI — Sat, 31 Oct 2026 16:45:12 +0000

Moodle is the most widely used open-source learning platform, and Moodle 5 changed how it is installed. Since Moodle 5.1, the code is split into a web-facing public/ directory and private files above it, third-party libraries come from Composer, and the web server must be configured for Moodle's router. Most Moodle tutorials online predate all three changes.

This guide installs Moodle 5.1 or 5.2 on Ubuntu 24.04 LTS with Nginx, PHP 8.3 and PostgreSQL 16 — all from Ubuntu's own archive, no third-party repositories needed — and covers the parts that decide whether Moodle runs well: moodledata, file permissions, max_input_vars, cron and HTTPS.

In short: install Nginx, PHP 8.3-FPM with Moodle's extensions and PostgreSQL; clone the Moodle stable branch and run composer install --no-dev --classmap-authoritative; create moodledata outside the web root; point Nginx's root at Moodle's public/ directory with a fallback to r.php; finish the installer; set $CFG->routerconfigured = true;; and run Moodle's cron every minute.

Moodle 5 requirements

Component	Moodle 5.1	Moodle 5.2	On Ubuntu 24.04
PHP	8.2 – 8.4	8.3 or newer	PHP 8.3 is the default — fits both
PostgreSQL	14 or newer	16 or newer	PostgreSQL 16 is the default
MariaDB / MySQL	MariaDB 10.11 / MySQL 8.4	Check the release notes	MariaDB 10.11 is the default
PHP `max_input_vars`	5000 or more	5000 or more	Default is 1000 — must be raised
Web server	Document root = `public/`	Document root = `public/`	Nginx or Apache

PHP 8.3 and PostgreSQL 16 from Ubuntu 24.04 satisfy both Moodle 5.1 and 5.2, which is why this guide uses them. Before upgrading or installing a newer branch, check Site administration → Server → Environment or the release notes on moodle.org.

PostgreSQL is Moodle's best-tested database and the one Moodle HQ recommends; MariaDB works too.

Step 1: install Nginx, PHP 8.3 and PostgreSQL

sudo apt update && sudo apt upgrade -y
sudo apt install nginx postgresql git unzip composer \
  php8.3-fpm php8.3-cli php8.3-pgsql php8.3-curl php8.3-gd php8.3-intl \
  php8.3-mbstring php8.3-xml php8.3-zip php8.3-soap php8.3-opcache

Raise the PHP limits Moodle checks, in both /etc/php/8.3/fpm/php.ini and /etc/php/8.3/cli/php.ini (cron and the CLI tools use the second one):

max_input_vars = 5000
memory_limit = 256M
upload_max_filesize = 100M
post_max_size = 100M
opcache.enable = 1
opcache.memory_consumption = 128

sudo systemctl restart php8.3-fpm

Step 2: create the database

sudo -u postgres psql

CREATE USER moodle WITH PASSWORD 'a-long-random-password';
CREATE DATABASE moodle WITH OWNER moodle ENCODING 'UTF8' TEMPLATE template0;

PostgreSQL on Ubuntu listens only on localhost by default, which is exactly what a single-server Moodle wants.

Step 3: download Moodle and install its dependencies

Use Git so later updates are a git pull rather than a re-download. Pick the newest stable branch listed on moodle.org — MOODLE_502_STABLE for Moodle 5.2, for example:

sudo git clone --depth 1 --branch MOODLE_502_STABLE https://github.com/moodle/moodle.git /var/www/moodle
cd /var/www/moodle
sudo composer install --no-dev --classmap-authoritative

The Composer step is new in Moodle 5.1: a Git checkout no longer contains the vendor/ directory, and Moodle refuses to run without it.

Keep the code owned by root and not writable by the web server. Moodle never needs to write to its own code; if PHP cannot modify it, an attacker who finds a vulnerability cannot either:

sudo chown -R root:root /var/www/moodle
sudo chmod -R a+rX /var/www/moodle

Step 4: create moodledata outside the web root

moodledata holds uploaded files, caches and sessions. It must never be reachable over HTTP:

sudo mkdir /var/moodledata
sudo chown www-data:www-data /var/moodledata
sudo chmod 0770 /var/moodledata

Step 5: configure Nginx for the public directory and the router

Since Moodle 5.1, Nginx must serve /var/www/moodle/public — not the repository root — and send requests for paths that are not files to Moodle's router, r.php. Create /etc/nginx/sites-available/moodle:

server {
    listen 80;
    server_name lms.example.com;

    root /var/www/moodle/public;
    index index.php;
    client_max_body_size 100M;

    location / {
        try_files $uri $uri/ /r.php$is_args$args;
    }

    location ~ [^/]\.php(/|$) {
        fastcgi_split_path_info ^(.+\.php)(/.*)$;
        if (!-f $document_root$fastcgi_script_name) {
            return 404;
        }
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        fastcgi_read_timeout 300;
    }

    # Hidden files (.git, .env and friends) are never served.
    location ~ /\. {
        deny all;
    }
}

The PATH_INFO lines keep Moodle's "slash arguments" URLs (such as /pluginfile.php/12/…) working.

sudo ln -s /etc/nginx/sites-available/moodle /etc/nginx/sites-enabled/
sudo rm /etc/nginx/sites-enabled/default
sudo nginx -t && sudo systemctl reload nginx

Step 6: add HTTPS

Point lms.example.com at the server, then:

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d lms.example.com

Do this before running the installer, so Moodle records an https:// address as its wwwroot from the start.

Step 7: run the installer

Open https://lms.example.com and follow the web installer:

Data directory: /var/moodledata.
Database driver: PostgreSQL (native/pgsql), host localhost, database moodle, user moodle.
Because the code is not writable by PHP, the installer shows the contents of config.php instead of writing it. Save that text as /var/www/moodle/config.php — in the base directory, above public/, not inside it.
Continue: Moodle checks the environment, installs its tables and asks you to create the first administrator.

Then enable the router in config.php, above the require_once line at the end of the file:

$CFG->routerconfigured = true;

The flag tells Moodle that the web server sends unknown paths to r.php. The Nginx rule and the flag must agree: with the rule but not the flag, routed pages return 404s.

Step 8: schedule Moodle's cron

Moodle's cron sends notifications, runs scheduled and ad-hoc tasks, and cleans up caches. Run it every minute as the web server user:

sudo crontab -u www-data -e

* * * * * /usr/bin/php8.3 /var/www/moodle/public/admin/cli/cron.php > /dev/null

On Moodle 5.1 and later the CLI scripts live under public/admin/cli/; on Moodle 5.0 and earlier the path has no public/. Run ls /var/www/moodle/public/admin/cli/cron.php once to confirm it on your installation. Check Site administration → Notifications after a few minutes — Moodle warns there if cron has not run recently.

Step 9: production hardening

Caching: a Redis-compatible store (Redis or Valkey) for the application cache and sessions makes a large difference once more than a handful of people use the site. Configure it under Site administration → Plugins → Caching.
Backups: back up the PostgreSQL database and /var/moodledata together; one without the other cannot be restored.
Updates: cd /var/www/moodle && sudo git pull && sudo composer install --no-dev --classmap-authoritative, then complete the upgrade at Site administration → Notifications or with the CLI upgrade script.
Email: configure outgoing SMTP under Site administration → Server → Email, or users never receive password resets.

Running Moodle next to your other PHP apps

Moodle is not yet a one-click application in Hanoo — today's catalogue covers Laravel, WordPress, Magento, Drupal and plain PHP. If your team runs those alongside an LMS, Hanoo can manage them on servers you own with PHP 8.0–8.5 side by side, per-application users and PHP-FPM pools, MariaDB, domains with automatic HTTPS, cron jobs and Git deploys — while Moodle follows the manual setup above.

Frequently asked questions

Which PHP version should I use for Moodle 5?

PHP 8.3. It is supported by both Moodle 5.1 (PHP 8.2–8.4) and Moodle 5.2 (PHP 8.3 and newer), and it is the default PHP on Ubuntu 24.04, so no extra repository is needed.

What is the public directory in Moodle 5.1?

From Moodle 5.1, files that browsers may request live in public/, while config.php, vendor/ and other private files stay in the directory above it. The web server's document root must point at public/, which keeps configuration and dependencies out of reach of HTTP requests.

Why does Moodle show 404 errors after installing on Nginx?

Usually the router is not configured. Make sure Nginx's location / block ends with try_files $uri $uri/ /r.php$is_args$args;, that the PHP location passes PATH_INFO, and that config.php contains $CFG->routerconfigured = true;.

Should I use PostgreSQL or MariaDB for Moodle?

Both are supported. PostgreSQL is Moodle's most thoroughly tested database and is a good default for new installations; on Ubuntu 24.04, PostgreSQL 16 from the default archive meets Moodle 5's requirements.

Why must moodledata be outside the web root?

It contains every uploaded file, cached data and session. If it were inside the web root, those files could be downloaded directly, bypassing Moodle's permission checks entirely.

How often should Moodle cron run?

Every minute. Moodle decides internally which scheduled tasks are due, so a one-minute cron keeps notifications, forum emails and background tasks timely without overloading the server.

Originally published on the Hanoo blog.

How to Install PHP 8.5 on Ubuntu 24.04 — and Run Several PHP Versions Side by Side

SᕼᗩᕼIᗪ KᗩᖇIᗰI — Sat, 31 Oct 2026 16:44:48 +0000

PHP 8.5 was released in November 2025 and is now the newest supported PHP. Ubuntu 24.04 LTS, though, ships PHP 8.3 in its own archive — so getting PHP 8.5 means adding a package source, and running real applications usually means keeping several PHP versions installed side by side: Magento on 8.5, a Laravel app on 8.4, a legacy site on 8.3.

This guide installs PHP 8.5 and PHP-FPM on Ubuntu 24.04, runs it next to other versions without conflicts, gives each site its own PHP-FPM pool, and keeps everything patched.

In short: add the ppa:ondrej/php repository, install php8.5-fpm plus the extensions your app needs, and create one FPM pool per site pointing at the PHP version that site needs. Versions install side by side under /etc/php/<version>/; the php command is chosen with update-alternatives, but scripts and cron jobs should call php8.5 explicitly.

Which PHP versions are supported in 2026?

Each PHP release gets two years of active support followed by two years of security fixes, ending on 31 December:

Version	Released	Active support until	Security fixes until
PHP 8.5	November 2025	31 Dec 2027	31 Dec 2029
PHP 8.4	November 2024	31 Dec 2026	31 Dec 2028
PHP 8.3	November 2023	Ended	31 Dec 2027
PHP 8.2	December 2022	Ended	31 Dec 2026
PHP 8.1 and older	—	Ended	Ended — upgrade

For new projects, choose PHP 8.4 or 8.5. Check your framework first: Magento 2.4.9 wants 8.4 or 8.5, Laravel 13 needs 8.3 or newer, WordPress recommends 8.4 or 8.5, and Moodle 5.1 stops at 8.4.

What's new in PHP 8.5

The pipe operator |> passes a value through a chain of callables left to right, replacing deeply nested calls.
A built-in URI extension parses and normalises URLs according to RFC 3986 and the WHATWG URL standard, instead of the loose parse_url().
array_first() and array_last() finally return the first and last values of an array without moving its internal pointer.
clone with property overrides, which makes "with-er" methods on readonly classes much simpler.
#[\NoDiscard] warns when the return value of a function that must be checked is ignored.

$slug = '  Hello World  '
    |> trim(...)
    |> strtolower(...)
    |> (fn (string $value): string => str_replace(' ', '-', $value));
// "hello-world"

Step 1: add the PHP repository

The Ondřej Surý PPA is the de-facto source of current PHP builds for Ubuntu and Debian; it is maintained by a long-standing Debian PHP packager and carries every supported version for each Ubuntu LTS.

sudo apt update
sudo apt install software-properties-common
sudo add-apt-repository ppa:ondrej/php
sudo apt update

Step 2: install PHP 8.5 and PHP-FPM

Install the FPM service, the command-line binary and the extensions your application needs. A broad set that covers most frameworks and CMSs:

sudo apt install php8.5-fpm php8.5-cli php8.5-common php8.5-mysql php8.5-pgsql \
  php8.5-curl php8.5-gd php8.5-intl php8.5-mbstring php8.5-xml php8.5-zip \
  php8.5-bcmath php8.5-soap php8.5-opcache php8.5-redis

Check the result:

php8.5 -v
systemctl status php8.5-fpm

In PHP 8.5, OPcache is always compiled in rather than being a separately loaded extension, so a php8.5-opcache package may not be needed. If apt reports it does not exist, OPcache is already there — confirm with php8.5 -i | grep opcache.enable.

Step 3: install other versions side by side

Every version lives in its own directories and runs its own service, so installing another one never replaces the first:

sudo apt install php8.4-fpm php8.4-cli php8.4-mysql php8.4-mbstring php8.4-xml php8.4-curl

You now have:

/etc/php/8.4/fpm/   → php8.4-fpm.service → /run/php/php8.4-fpm.sock
/etc/php/8.5/fpm/   → php8.5-fpm.service → /run/php/php8.5-fpm.sock

Each version has its own php.ini for FPM and CLI, and its own extensions. Installing php8.5-redis does nothing for PHP 8.4.

Step 4: give each site its own PHP-FPM pool

The default www pool runs every site as www-data. That means one compromised site can read every other site's files and secrets. Give each site a pool of its own, running as its own user, on the PHP version it needs. For a shop running on PHP 8.5, create /etc/php/8.5/fpm/pool.d/shop.conf:

[shop]
user = shop
group = shop
listen = /run/php/php8.5-fpm-shop.sock
listen.owner = www-data
listen.group = www-data

pm = dynamic
pm.max_children = 12
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 5
pm.max_requests = 500

php_admin_value[memory_limit] = 512M
php_admin_value[open_basedir] = /srv/shop:/tmp
php_admin_flag[expose_php] = off

sudo adduser --system --group --home /srv/shop shop
sudo systemctl reload php8.5-fpm

Then point the site's web server at that socket — fastcgi_pass unix:/run/php/php8.5-fpm-shop.sock; in Nginx, or php_fastcgi unix//run/php/php8.5-fpm-shop.sock in Caddy. Moving the site to another PHP version later means creating the same pool under the other version and switching the socket path.

Sizing `pm.max_children`

Each FPM worker holds a full PHP process in memory. A practical starting point is:

pm.max_children ≈ (RAM you can give this site) ÷ (average worker memory)

Measure the average with ps -o rss= -u shop | awk '{ s += $1 } END { print s / NR / 1024 " MB" }' under normal traffic. 60–120 MB per worker is typical for WordPress and Laravel; Magento workers are larger.

Step 5: choose the default `php` command

The plain php command points to one version through Debian's alternatives system:

sudo update-alternatives --config php

This affects only the CLI. FPM pools, cron jobs and deploy scripts should name the version explicitly (php8.5 artisan …, php8.4 wp-cli.phar …) so a change to the default never silently moves an application to another PHP.

Step 6: keep PHP patched

Ubuntu's unattended-upgrades installs security updates from Ubuntu's own archive, but not from PPAs unless you allow them. Add the PPA's origin in a file such as /etc/apt/apt.conf.d/52unattended-upgrades-php:

Unattended-Upgrade::Allowed-Origins:: "LP-PPA-ondrej-php:${distro_codename}";

PHP patch releases come out roughly monthly and regularly include security fixes; leaving PHP on a PPA without automatic updates is one of the most common ways self-managed servers fall behind.

Multiple PHP versions with Hanoo

Hanoo manages exactly this setup on Ubuntu servers you own. It installs PHP 8.0 through 8.5 side by side on Ubuntu 22.04, 24.04 and 26.04 LTS — from the same PPA on 22.04 and 24.04, and from Ondřej Surý's packages.sury.org repository on 26.04, where the PPA publishes no builds — and adds that source to unattended upgrades, so PHP security releases arrive automatically. Every application gets its own Linux user and its own PHP-FPM pool on the version you pick when you create it, and pool settings — process manager, max_children, memory limit, upload size — are editable as structured fields in the dashboard rather than raw config files. Cron jobs and workers run as the application's user, so a Magento store on PHP 8.5 and a legacy app on PHP 8.1 share a server without sharing a single file permission.

Frequently asked questions

Does Ubuntu 24.04 include PHP 8.5?

No. Ubuntu 24.04's own archive provides PHP 8.3. PHP 8.4 and 8.5 for Ubuntu 24.04 are installed from the ppa:ondrej/php repository.

Can I run PHP 8.3, 8.4 and 8.5 on the same server?

Yes. Each version installs into its own directories with its own FPM service and socket, so they coexist. Point each site's web server configuration at the FPM socket of the version it needs.

How do I change the default PHP version on Ubuntu?

Run sudo update-alternatives --config php and choose the version. This changes the php command only; web requests use whichever PHP-FPM socket the web server is configured with.

Is PHP 8.5 stable enough for production?

Yes. PHP 8.5 is a general-availability release with active support until the end of 2027. The real question is whether your application and its dependencies support it — Magento 2.4.9 does, for example, while Moodle 5.1 stops at PHP 8.4.

Should every site have its own PHP-FPM pool?

Yes. A separate pool per site, running as a separate user, isolates sites from each other, lets you size and tune each one independently, and makes it possible to run different PHP versions per site.

How do I enable OPcache in PHP 8.5?

OPcache is built into PHP 8.5. Make sure opcache.enable=1 in the FPM php.ini and give it enough memory with opcache.memory_consumption; on a production server, also consider opcache.validate_timestamps=0 with an FPM reload after every deploy.

Originally published on the Hanoo blog.

How to Install Magento 2.4.9 on Ubuntu 24.04 (with OpenSearch 3 and PHP 8.5)

SᕼᗩᕼIᗪ KᗩᖇIᗰI — Sat, 31 Oct 2026 16:44:19 +0000

Magento Open Source 2.4.9 is the most demanding PHP application most teams will ever self-host. A working store needs a specific PHP version with a long list of extensions, a supported MariaDB or MySQL, a running OpenSearch cluster, Composer, a web server that understands Magento's pub/ layout, production-mode compilation, static content deployment and a cron job that runs every minute.

This guide covers both routes on Ubuntu 24.04 LTS: what a manual installation involves step by step, and how to get the same store running from a single form with Hanoo on a server you own. Either way, you end up with a real Magento store on your own infrastructure — no shared hosting, no proprietary platform.

In short: Magento 2.4.9 needs PHP 8.4 or 8.5, OpenSearch 3, a recent MariaDB or MySQL, Composer 2 and at least 2 CPU cores and 3 GB of RAM in practice. With Hanoo you pick Magento Open Source when creating an application, and the platform installs PHP 8.5, MariaDB 11.8, OpenSearch 3.8, Magento itself and HTTPS for you.

Magento 2.4.9 system requirements

Adobe tests each Magento release against a specific set of services. For 2.4.9, the release that went generally available in May 2026, the stack looks like this:

Component	What Magento 2.4.9 expects	What Hanoo installs
Operating system	Any supported Linux	Ubuntu 22.04, 24.04 or 26.04 LTS (amd64 or arm64)
PHP	8.4 or 8.5 (8.3 only to upgrade older stores)	PHP 8.5 with its own FPM pool
Database	MySQL 8.4 or a supported MariaDB release	MariaDB 11.8, one private database per store
Search	OpenSearch 3 (Elasticsearch is no longer supported)	OpenSearch 3.8, bound to 127.0.0.1 only
Web server	Nginx or Apache	Caddy, serving `pub/` as the document root
Composer	Composer 2	Handled during installation
Hardware	2 GB RAM is the documented floor; real stores need more	Asks for 2 CPU cores, 3 GB RAM and 20 GB disk, and warns before installing on less

Always check Adobe's own system requirements page for the exact database version matrix before a production launch — Adobe supports only the combinations it tests.

Why OpenSearch matters

Since Magento 2.4, a search engine is mandatory: catalog search, layered navigation and even some admin grids query it. Magento 2.4.9 targets OpenSearch 3. OpenSearch runs on the JVM, so it is the single largest memory consumer on a small Magento server — the most common reason a Magento installation fails on a 1 GB or 2 GB VPS is OpenSearch never finishing its start-up.

Option 1: install Magento 2.4.9 manually on Ubuntu 24.04

The manual route is worth understanding even if you never take it, because it shows exactly what has to be true on the server. The outline below assumes a fresh Ubuntu 24.04 server and a user with sudo.

1. Install PHP 8.5 and the extensions Magento needs

Ubuntu 24.04 ships PHP 8.3, which Magento 2.4.9 does not support for new stores. PHP 8.5 comes from the widely used Ondřej Surý PPA:

sudo add-apt-repository ppa:ondrej/php
sudo apt update
sudo apt install php8.5-fpm php8.5-cli php8.5-bcmath php8.5-curl php8.5-gd \
  php8.5-intl php8.5-mbstring php8.5-mysql php8.5-soap php8.5-xml \
  php8.5-zip php8.5-sockets php8.5-opcache

Then raise the limits Magento's installer checks, in /etc/php/8.5/fpm/php.ini and /etc/php/8.5/cli/php.ini:

memory_limit = 2G
max_execution_time = 1800
zlib.output_compression = On
realpath_cache_size = 10M
realpath_cache_ttl = 7200

2. Install the database

Create a dedicated database and user. Never let Magento connect as root:

CREATE DATABASE magento CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'magento'@'127.0.0.1' IDENTIFIED BY 'a-long-random-password';
GRANT ALL PRIVILEGES ON magento.* TO 'magento'@'127.0.0.1';
FLUSH PRIVILEGES;

Make sure the MariaDB version you install is one Adobe lists for 2.4.9; the version in Ubuntu's own archive is usually older than Magento wants, so most teams add MariaDB's official repository.

3. Install and tune OpenSearch 3

Install OpenSearch 3 from the official OpenSearch APT repository, then keep it private and sized for the machine:

# /etc/opensearch/opensearch.yml
cluster.name: magento
network.host: 127.0.0.1
http.port: 9200
discovery.type: single-node
plugins.security.disabled: true

Set the JVM heap explicitly (for example -Xms512m and -Xmx512m on a small store, more on a large catalogue), raise vm.max_map_count to 262144, then sudo systemctl enable --now opensearch and confirm curl http://127.0.0.1:9200 answers with a 3.x version. Disabling the security plugin is only acceptable because the service listens on 127.0.0.1 — never expose an unauthenticated OpenSearch port to the internet.

4. Download Magento and install its dependencies

Download the 2.4.9 release (from Adobe's Composer repository with your access keys, or the tagged source archive on GitHub), place it under a directory owned by a dedicated, unprivileged user, and run composer install --no-dev inside it.

5. Run the Magento installer

php8.5 bin/magento setup:install \
  --base-url=https://shop.example.com/ \
  --db-host=127.0.0.1 --db-name=magento --db-user=magento --db-password='…' \
  --search-engine=opensearch --opensearch-host=127.0.0.1 --opensearch-port=9200 \
  --language=en_US --currency=USD --timezone=UTC \
  --use-rewrites=1 --document-root-is-pub=1 \
  --admin-firstname=Store --admin-lastname=Owner \
  --admin-email=you@example.com --admin-user=storeadmin --admin-password='…'

6. Switch to production mode

php8.5 bin/magento deploy:mode:set production --skip-compilation
php8.5 bin/magento setup:di:compile
php8.5 bin/magento setup:static-content:deploy -f en_US
php8.5 bin/magento cache:flush

Compilation alone can take several minutes and well over a gigabyte of memory.

7. Configure the web server for `pub/`

Point the document root at Magento's pub/ directory, not the project root. Magento's sample Nginx file (nginx.conf.sample) shows the rules it expects, including the static.php and get.php fallbacks for versioned static assets and media. Skipping those fallbacks is the classic cause of a storefront that loads but looks completely unstyled.

8. HTTPS, file permissions and cron

Finally: issue a certificate, make sure only the Magento user can write to var/, generated/, pub/static/ and pub/media/, and add Magento's cron (bin/magento cron:run) to run every minute. Without cron, indexers, emails and scheduled tasks silently stop.

That is eight stages, each with its own failure modes. The rest of this guide shows the shorter path.

Option 2: install Magento 2.4.9 with Hanoo

Hanoo is a control plane for PHP servers you own. You connect a clean Ubuntu server once, and from then on applications, domains, certificates, databases and services are managed from the dashboard — while everything on the server stays standard Ubuntu, Caddy, PHP-FPM and MariaDB.

Step 1: connect an Ubuntu server

Create a server at any provider — DigitalOcean, Hetzner, AWS, Vultr or your own hardware — with Ubuntu 22.04, 24.04 or 26.04 LTS, at least 2 CPU cores, 3 GB of RAM and 20 GB of disk. 4 GB of RAM or more is a comfortable starting point for a real catalogue.

In the Hanoo dashboard, choose Connect server and run the one-time command it shows on the server:

curl -fsSL https://app.hanoo.io/api/v1/install.sh \
  | sudo bash -s -- --url https://app.hanoo.io/api --token hne_••••••

The command installs a small agent that connects out to Hanoo over mutually authenticated TLS. No inbound management port is opened, and no root password or private key is shared. Review the server's details and approve it in the dashboard.

Step 2: create a Magento application

Open Applications → Create application and choose Magento Open Source. Give the store a name and pick the server you just connected. PHP 8.5 is selected for you, because it is the version this Magento release is installed with.

When you create the application, Hanoo's agent on your server:

Checks the server against Magento's minimums and warns you up front if the install is likely to fail.
Installs OpenSearch 3.8, bound to 127.0.0.1 with a fixed JVM heap and the kernel setting it needs, and waits until it answers.
Creates an isolated Linux user and a dedicated PHP 8.5-FPM pool for the store.
Creates a private MariaDB 11.8 database and user, and keeps the password out of process lists and logs.
Downloads the pinned Magento 2.4.9 release, verifies its checksum and installs its dependencies.
Runs setup:install, switches the store to production mode, compiles dependency injection and deploys static content.
Configures Caddy to serve pub/ with Magento's static and media fallbacks, and refuses PHP execution inside pub/media and pub/static.

You can follow every phase live on the application's page; the whole run typically takes several minutes, most of it Magento's own compilation. If a step fails, the page names the step and the reason — not just "installation failed".

The store is immediately reachable on its temporary Hanoo address over HTTPS.

Step 3: create your admin user

The installer does not invent an admin password for you. Create the first admin account yourself over SSH, as the store's own user. Add your public key under the application's Access tab, connect, and run:

cd /srv/hanoo/apps/<application-id>/current
php8.5 bin/magento admin:user:create \
  --admin-user=storeadmin --admin-password='a-long-unique-password' \
  --admin-email=you@example.com --admin-firstname=Store --admin-lastname=Owner
php8.5 bin/magento info:adminuri

info:adminuri prints the admin path. Magento enables two-factor authentication for the admin by default and emails the setup link, so configure outgoing mail before your first sign-in on a production store.

Step 4: add your domain and switch the base URL

Under the application's Domains tab, add shop.example.com. Hanoo checks that its DNS points at your server, issues a Let's Encrypt certificate and serves the store on it.

Magento stores its own base URLs in the database, so tell it about the new domain once:

php8.5 bin/magento config:set web/unsecure/base_url https://shop.example.com/
php8.5 bin/magento config:set web/secure/base_url https://shop.example.com/
php8.5 bin/magento config:set web/secure/use_in_frontend 1
php8.5 bin/magento config:set web/secure/use_in_adminhtml 1
php8.5 bin/magento cache:flush

Step 5: schedule Magento's cron

Open the application's Cron jobs tab and add an entry that runs every minute (* * * * *):

php8.5 bin/magento cron:run

Cron jobs run as the store's own user, in its current release directory, and by default a run is skipped while the previous one is still going, so a slow run is never stacked on top of itself. You can run the entry on demand and see its last result and output in the dashboard.

Troubleshooting a Magento 2.4.9 installation

The installer stops at OpenSearch

Almost always memory. OpenSearch needs its heap plus headroom, and Magento's compile step runs alongside it. On a 1-core, 1 GB server OpenSearch never answers; give the server at least 3 GB of RAM (Hanoo warns you before installing on anything smaller, and names the memory problem if OpenSearch does not start) and avoid running other heavy services on it.

The storefront loads without any styling

Static assets are requested with a versioned prefix such as /static/version1760000000/…. If the web server does not route missing files under pub/static to static.php, every stylesheet request returns a 404 page. Hanoo configures these routes for you; on a manual setup, copy them from Magento's nginx.conf.sample.

"There has been an error processing your request"

Look in var/report/ for the report number shown on the page, and in var/log/exception.log. After any code or configuration change in production mode, re-run setup:di:compile and setup:static-content:deploy.

Indexers say "Reindex required"

Cron is not running. Check the cron job's last run in the dashboard, or run php8.5 bin/magento indexer:status to see which indexers are behind.

Frequently asked questions

Can I install Magento 2.4.9 on Ubuntu 24.04?

Yes. Ubuntu 24.04 LTS is a solid base for Magento 2.4.9, but its built-in PHP 8.3 is not supported for new 2.4.9 stores, so you need PHP 8.4 or 8.5 from another source, plus OpenSearch 3 and a supported database. Hanoo installs all of these for you on Ubuntu 22.04, 24.04 or 26.04.

How much RAM does Magento 2.4.9 need?

Adobe documents 2 GB as a minimum, but that leaves no room for OpenSearch and compilation. Plan for at least 3 GB on a small store and 4–8 GB once you have real traffic and a larger catalogue.

Does Magento 2.4.9 still support Elasticsearch?

No. Magento 2.4.9 uses OpenSearch, with OpenSearch 3 as the target version. If you are upgrading from a store that used Elasticsearch, migrate to OpenSearch first.

Which PHP version should I use for Magento 2.4.9?

PHP 8.4 or 8.5. PHP 8.3 is only meant as a stepping stone when upgrading an older store. Hanoo installs Magento 2.4.9 with PHP 8.5.

Is it safe to run Magento on my own VPS instead of managed Magento hosting?

Yes, if the basics are right: a dedicated unprivileged user per store, search and database bound to localhost, HTTPS everywhere, admin two-factor authentication, and timely security patches. Running on a server you own also means no platform lock-in — with Hanoo, your store keeps running even if you stop using the dashboard.

How do I find my Magento admin URL?

Run php8.5 bin/magento info:adminuri in the store's directory. The admin path is randomised at installation so it is not trivially guessable.

Originally published on the Hanoo blog.

How to Install WordPress on Ubuntu 24.04 with Caddy, PHP 8.4 and MariaDB

SᕼᗩᕼIᗪ KᗩᖇIᗰI — Sat, 31 Oct 2026 16:43:51 +0000

WordPress still powers a huge share of the web, and the cheapest way to run it well is on a server you control. This guide installs WordPress 7.1 on Ubuntu 24.04 LTS with the stack the WordPress Hosting Team recommends today — PHP 8.4, MariaDB and HTTPS — served by Caddy, the web server that obtains and renews TLS certificates on its own.

You will see every command for a manual install, the security settings most tutorials skip, and how to get the same result in a few minutes with Hanoo.

In short: install PHP 8.4-FPM with WordPress's extensions, create a MariaDB database and user, download WordPress, write wp-config.php with unique salts, give the site its own PHP-FPM pool and Linux user, and let Caddy serve it with automatic HTTPS. Then block wp-config.php and PHP inside uploads/, and add an object cache.

WordPress requirements in 2026

WordPress's minimum requirements are deliberately low (PHP 7.4 still runs it), but minimums are not what you want for a new site. The WordPress Hosting Team's recommendations for WordPress 7.1 are:

Component	Recommended for new sites	Notes
PHP	8.4 or 8.5	8.3 works; PHP 8.2 reaches end of life on 31 December 2026
Database	MariaDB 10.11, 11.4 or 11.8, or MySQL 8.4	Ubuntu 24.04's own `mariadb-server` is 10.11
Web server	Any server with HTTPS	Caddy, Nginx or Apache
PHP extensions	`mysqli`, `curl`, `gd` or `imagick`, `intl`, `mbstring`, `xml`, `zip`	Plus OPcache for performance

Option 1: install WordPress manually on Ubuntu 24.04

1. Update the server and create a site user

Each site should run as its own Linux user, so a compromised plugin on one site cannot read another site's files:

sudo apt update && sudo apt upgrade -y
sudo adduser --system --group --home /srv/blog blog

2. Install PHP 8.4 and WordPress's extensions

Ubuntu 24.04 ships PHP 8.3. For PHP 8.4, add the Ondřej Surý PPA:

sudo add-apt-repository ppa:ondrej/php && sudo apt update
sudo apt install php8.4-fpm php8.4-mysql php8.4-curl php8.4-gd php8.4-intl \
  php8.4-mbstring php8.4-xml php8.4-zip php8.4-imagick php8.4-opcache

Give the site its own PHP-FPM pool, running as the site's user, in /etc/php/8.4/fpm/pool.d/blog.conf:

[blog]
user = blog
group = blog
listen = /run/php/php8.4-fpm-blog.sock
listen.owner = caddy
listen.group = caddy
pm = dynamic
pm.max_children = 10
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 4
php_admin_value[upload_max_filesize] = 64M
php_admin_value[post_max_size] = 64M
php_admin_value[memory_limit] = 256M

Then sudo systemctl reload php8.4-fpm.

3. Create the database

sudo apt install mariadb-server
sudo mariadb

CREATE DATABASE blog CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'blog'@'127.0.0.1' IDENTIFIED BY 'a-long-random-password';
GRANT ALL PRIVILEGES ON blog.* TO 'blog'@'127.0.0.1';
FLUSH PRIVILEGES;

4. Download WordPress

cd /srv/blog
sudo -u blog curl -fsSLO https://wordpress.org/wordpress-7.1.tar.gz
sudo -u blog tar -xzf wordpress-7.1.tar.gz --strip-components=1
sudo -u blog rm wordpress-7.1.tar.gz

WordPress publishes checksums next to every release; compare the SHA-1 or MD5 of the archive with the one on wordpress.org before extracting it on a production server.

5. Write `wp-config.php`

Copy wp-config-sample.php to wp-config.php, fill in the database name, user, password and DB_HOST of 127.0.0.1, and replace the eight AUTH_KEY … NONCE_SALT lines with fresh values from https://api.wordpress.org/secret-key/1.1/salt/. Add two hardening lines above the "That's all, stop editing!" comment:

define('DISALLOW_FILE_EDIT', true); // no theme/plugin code editor in wp-admin
define('WP_DEBUG', false);

Make the file readable only by the site user and the web server: chmod 640 wp-config.php.

6. Install Caddy and serve the site

Install Caddy from its official repository (the version in Ubuntu's archive is older), then describe the site in /etc/caddy/Caddyfile:

blog.example.com {
    root * /srv/blog
    encode zstd gzip

    # Never serve the config file, and never run PHP someone managed to upload.
    @sensitive path /wp-config.php /readme.html /license.txt
    respond @sensitive 404
    @uploaded_php path_regexp (?i)^/wp-content/uploads/.*\.php$
    respond @uploaded_php 404

    php_fastcgi unix//run/php/php8.4-fpm-blog.sock
    file_server
}

sudo systemctl reload caddy. As soon as blog.example.com resolves to the server, Caddy obtains a Let's Encrypt certificate and redirects HTTP to HTTPS — no Certbot, no renewal cron.

7. Run the famous five-minute install

Open https://blog.example.com and complete WordPress's installer: site title, admin username (not admin), a strong password and your email. That's it — WordPress is live.

8. Add an object cache

Every WordPress page load runs dozens of database queries; a persistent object cache keeps their results in memory between requests. Install Redis or Valkey, bind it to localhost with a password, add the PHP extension and an object-cache plugin, and point the plugin at the server.

Option 2: install WordPress with Hanoo

Hanoo does all of the above on your own server, from one form.

Step 1: connect an Ubuntu server

Any provider works. WordPress needs Ubuntu 22.04, 24.04 or 26.04 LTS with at least 1 CPU core, 1 GB of RAM and 10 GB of disk. Run the install command from Connect server; the agent connects out over mutually authenticated TLS, opens no inbound management port, and asks you to approve the server.

Step 2: create a WordPress application

Choose Create application → WordPress, name it, pick the server and a PHP version (8.4 is recommended; 8.3 and 8.5 are available). Hanoo then:

downloads the pinned official WordPress 7.1 release from wordpress.org and verifies its checksum;
creates an isolated Linux user and a dedicated PHP-FPM pool for the site;
creates a private MariaDB database and user;
writes wp-config.php with the database credentials and eight unique salts, DISALLOW_FILE_EDIT on and debug output off;
keeps wp-content/uploads in a shared directory that survives updates and clones;
configures Caddy to refuse wp-config.php, readme.html, license.txt and any PHP file under uploads/.

The site is immediately reachable on its temporary Hanoo address with HTTPS. Open it and finish WordPress's own five-minute installer to create your admin account.

Step 3: add your domain

Under the application's Domains tab, add blog.example.com. Hanoo checks that its DNS points at your server, issues the certificate and switches the site over with zero downtime. Then update Settings → General → WordPress Address and Site Address in wp-admin to the new domain.

Step 4: optimize

The application's Optimize WordPress tab scans the site for common slowdowns and measures time to first byte. From there you can turn on a per-site Valkey object cache in one click — Hanoo installs Valkey if the server does not have it yet — and enable compression and browser caching for static files. Every change is reversible from the same tab.

Step 5: staging and backups

Need a staging copy? Clone the application onto the same server or another one; the copy gets its own database. Backups and SSH/SFTP access per application are on the application's own tabs.

WordPress security checklist

One Linux user and PHP-FPM pool per site.
wp-config.php not web-readable; no PHP execution in uploads/.
DISALLOW_FILE_EDIT on, so a stolen admin session cannot edit PHP from wp-admin.
Unique admin username, strong password and two-factor authentication via a plugin.
Automatic minor-version updates left on; plugins and themes updated weekly.
Database bound to 127.0.0.1, never exposed publicly.
Regular off-server backups of the database and wp-content.

Frequently asked questions

Which PHP version is best for WordPress?

PHP 8.4 for new sites. The WordPress Hosting Team recommends PHP 8.4 or 8.5 for WordPress 7.1; PHP 8.3 still works, and PHP 8.2 reaches end of life at the end of 2026.

Is Caddy good for WordPress?

Yes. Caddy serves PHP through PHP-FPM just like Nginx, and it obtains and renews HTTPS certificates automatically. WordPress's pretty permalinks work with php_fastcgi without extra rewrite rules.

MariaDB or MySQL for WordPress?

Either. MariaDB 10.11 or newer and MySQL 8.4 are both recommended. On Ubuntu 24.04, mariadb-server from the default archive is MariaDB 10.11, which is fine for WordPress.

How much RAM does a WordPress server need?

1 GB runs a small site comfortably. Plan for 2 GB or more if you run WooCommerce, page builders or an object cache alongside the database on the same server.

Can I run several WordPress sites on one server?

Yes — give each its own Linux user, PHP-FPM pool, database and database user so they are isolated from each other. Hanoo does this automatically for every application.

What is an object cache and do I need one?

An object cache stores the results of repeated database queries in memory (Redis or Valkey) between requests. It noticeably speeds up wp-admin, WooCommerce and logged-in traffic, and is worth enabling on any site with dynamic content.

Originally published on the Hanoo blog.

How to Deploy Laravel 13 to Production on Your Own Ubuntu Server

SᕼᗩᕼIᗪ KᗩᖇIᗰI — Sat, 31 Oct 2026 16:43:15 +0000

Running php artisan serve on your laptop is easy. Running a Laravel 13 application in production — with HTTPS, zero-downtime deploys, migrations that don't take the site down, queue workers that survive reboots and a scheduler that actually fires — is where most teams reach for a PaaS and its bill.

You don't have to. This guide walks through a production-grade Laravel 13 deployment on a single Ubuntu 24.04 server you own: first the moving parts and how to wire them by hand, then the same result with Hanoo, where a git push becomes a built, verified and reversible release.

In short: Laravel 13 requires PHP 8.3 or newer (8.4 is a good default). A production setup needs PHP-FPM, a web server pointing at public/, a database, Composer, Node.js for Vite builds, an atomic release layout, a queue worker under a process supervisor, the scheduler running every minute, and HTTPS.

What Laravel 13 needs in production

Laravel 13 was released in March 2026 and raised the minimum PHP version to 8.3. A typical production stack looks like this:

Piece	Recommended choice	Why
PHP	8.4 (8.3–8.5 supported)	Laravel 13's minimum is 8.3; 8.4 is the mature, fast default
Web server	Caddy or Nginx with PHP-FPM	Serves `public/`, hands PHP to FPM, terminates TLS
Database	MariaDB / MySQL or PostgreSQL	Bound to `127.0.0.1` on a single-server setup
Cache, sessions, queues	Valkey (Redis-compatible) or the database	`file` and `sync` drivers do not scale past one request
Assets	Node.js 22 or 24 with npm, pnpm or Yarn	`vite build` produces the files in `public/build`
Processes	Supervisor	Keeps `queue:work` running and restarts it on failure
Scheduler	Cron, every minute	Runs `schedule:run`, which runs your scheduled tasks

The zero-downtime release layout

The single most important production habit is to never build in the directory that is serving traffic. Instead, every deploy gets its own directory, and a symlink decides which one is live:

/srv/app/
├── releases/
│   ├── 20261015-142210/
│   └── 20261016-091503/    ← new release, built here
├── shared/
│   ├── .env                ← linked into every release
│   └── storage/            ← logs, sessions, uploads: survive deploys
└── current -> releases/20261016-091503

A deploy clones the commit into a new release directory, links shared/.env and shared/storage into it, installs dependencies, builds assets, runs migrations, and only then repoints current. Switching a symlink is atomic, so visitors either get the old release or the new one — never a half-built mix. Rolling back is pointing current at the previous release.

Option 1: deploy Laravel 13 by hand

1. Install PHP 8.4, Composer and Node.js

Ubuntu 24.04 ships PHP 8.3, which meets Laravel 13's minimum. For PHP 8.4, use the Ondřej Surý PPA:

sudo add-apt-repository ppa:ondrej/php && sudo apt update
sudo apt install php8.4-fpm php8.4-cli php8.4-mysql php8.4-mbstring php8.4-xml \
  php8.4-curl php8.4-zip php8.4-bcmath php8.4-intl php8.4-redis php8.4-opcache

Install Composer 2 from getcomposer.org (verify the installer's checksum), and Node.js 22 or 24 from NodeSource or a version manager.

2. Create a deploy user and the database

Run the application as its own unprivileged user — never as root and never as www-data shared with other sites:

sudo adduser --system --group --home /srv/app laravel

Create a dedicated database and user that can connect only from 127.0.0.1.

3. Point the web server at `current/public`

With Nginx, the essential bits are:

server {
    server_name app.example.com;
    root /srv/app/current/public;
    index index.php;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.4-fpm-laravel.sock;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        fastcgi_param DOCUMENT_ROOT $realpath_root;
    }
}

Note $realpath_root: it resolves the current symlink, so OPcache and FPM see the new release immediately after the switch instead of serving stale paths. Give the site its own PHP-FPM pool running as the laravel user, then add HTTPS with Certbot or switch to Caddy, which obtains certificates automatically.

4. Write a deploy script

The core of every Laravel deploy script:

set -euo pipefail
RELEASE=/srv/app/releases/$(date +%Y%m%d-%H%M%S)
git clone --depth 1 --branch main git@github.com:acme/shop.git "$RELEASE"
ln -s /srv/app/shared/.env "$RELEASE/.env"
rm -rf "$RELEASE/storage" && ln -s /srv/app/shared/storage "$RELEASE/storage"
cd "$RELEASE"
composer install --no-dev --prefer-dist --optimize-autoloader --no-interaction
npm ci && npm run build
php8.4 artisan migrate --force
php8.4 artisan optimize
ln -sfn "$RELEASE" /srv/app/current
sudo systemctl reload php8.4-fpm
php8.4 artisan queue:restart

Add release pruning, a health check after the switch, and a rollback path, and you have the beginnings of a deployment tool.

5. Queue workers with Supervisor

[program:laravel-queue]
command=php8.4 /srv/app/current/artisan queue:work --sleep=3 --tries=3 --max-time=3600
directory=/srv/app/current
user=laravel
numprocs=2
process_name=%(program_name)s_%(process_num)02d
autostart=true
autorestart=true
stopwaitsecs=3600

--max-time makes each worker exit periodically so Supervisor starts a fresh one, which picks up new code and releases memory. queue:restart in the deploy script tells running workers to finish their current job and exit.

6. The scheduler

* * * * * cd /srv/app/current && php8.4 artisan schedule:run >> /dev/null 2>&1

Install it in the laravel user's crontab, not root's.

Option 2: deploy Laravel 13 with Hanoo

Hanoo runs the release flow above for you, on your own server, with every step visible in the dashboard.

Step 1: connect your server

Run the one-time install command from Connect server on a clean Ubuntu 22.04, 24.04 or 26.04 LTS server. The agent connects out over mutually authenticated TLS — no inbound management port, no root password shared — and you approve the server in the dashboard. Laravel applications need at least 1 CPU core and 2 GB of RAM.

Step 2: create the application from your repository

Choose Create application, select Laravel and point it at your repository on GitHub, GitLab or Bitbucket. The server generates a read-only deploy key; you add its public half to the repository, and the private half never leaves your server. Pick PHP 8.4 (8.3–8.5 are available) and tick the database option if you want a private MariaDB database.

Hanoo creates an isolated Linux user and PHP-FPM pool for the application, and writes its .env from your .env.example — with APP_ENV=production, APP_DEBUG=false, APP_URL set to the application's address, the database credentials filled in when you asked for a database, and a freshly generated APP_KEY. That file lives in the application's shared directory and is linked into every release.

Step 3: what happens on every deploy

Each deploy:

Fetches the selected commit into a new, immutable release.
Detects your toolchain from the repository — composer.lock means Composer; pnpm-lock.yaml, package-lock.json or yarn.lock picks the JavaScript package manager — and installs checksum-verified versions of Composer and Node.js (20, 22 or 24).
Runs composer install and your asset build as the application's own user.
Links the shared .env and storage/ into the release and validates it.
Runs your deploy pipeline — steps such as php artisan migrate --force, cache warm-up or queue restarts, grouped into build, before activation and after activation phases.
Activates the release atomically, reloads PHP-FPM, and checks the site responds. A failed health check reverts to the previous release automatically.

Every step is timed and its output is shown, so a failed build tells you why without an SSH session. A failed build never touches the running site, and any retained release can be restored with one-click rollback.

Step 4: domain and HTTPS

Add app.example.com under the application's Domains tab. Hanoo checks that DNS points at your server, issues a Let's Encrypt certificate and switches the site over with zero downtime.

Step 5: queues and the scheduler

The default .env uses QUEUE_CONNECTION=sync, which runs jobs inside the web request. For real background processing:

Install Valkey from the server's Manage Services (it is Redis-compatible, so Laravel's redis driver works unchanged), or use the database queue driver. Then set QUEUE_CONNECTION and, if you use Valkey, CACHE_STORE and SESSION_DRIVER in .env over SSH as the application user.
Add a Supervisor program for the application running php8.4 artisan queue:work --sleep=3 --tries=3 --max-time=3600. Programs run as the application's user in its current release; you can start, stop and restart them and read their logs from the dashboard.
Add an entry under the application's Cron jobs tab running php8.4 artisan schedule:run every minute. You can run it on demand and see the latest result and output.

Production checklist for Laravel 13

APP_ENV=production and APP_DEBUG=false — debug mode leaks environment variables in error pages.
php artisan optimize after each deploy to cache config, routes, views and events.
OPcache enabled; with an atomic symlink layout, resolve paths with realpath so new releases are picked up.
Sessions, cache and queues on Valkey/Redis or the database — not file once you have more than one worker.
storage/ and .env outside the release directory, shared across releases.
Migrations that are backwards compatible with the previous release, so a rollback does not break.
Queue workers restarted on every deploy, with --max-time as a safety net.
Scheduler running every minute as the application user.
Off-server backups of the database and storage/app.

Frequently asked questions

What PHP version does Laravel 13 require?

Laravel 13 requires PHP 8.3 or newer and supports PHP 8.3, 8.4 and 8.5. PHP 8.4 is a sensible production default today.

How do I deploy Laravel without downtime?

Build each release in its own directory, share .env and storage/ between releases, run migrations before the switch, then atomically repoint a current symlink at the new release and reload PHP-FPM. Hanoo does exactly this on every deploy and reverts automatically if the new release fails its health check.

Do I need Laravel Forge or a PaaS to host Laravel?

No. Any Ubuntu server with PHP-FPM, a web server, a database and Supervisor can run Laravel in production. Tools like Hanoo automate the setup and the release flow while the server and code stay entirely yours.

How do I run Laravel queue workers in production?

Run php artisan queue:work under a process supervisor such as Supervisor, as the application's user, with --max-time so workers recycle, and call php artisan queue:restart after each deploy so they load the new code.

How do I run the Laravel scheduler on a server?

Add one cron entry that runs php artisan schedule:run every minute from the application's current directory. Laravel decides which scheduled tasks are due on each run.

Can I use Valkey instead of Redis with Laravel?

Yes. Valkey is an open-source fork of Redis that speaks the same protocol, so Laravel's redis cache, session and queue drivers work with it unchanged.

Originally published on the Hanoo blog.

DEV Community: SᕼᗩᕼIᗪ KᗩᖇIᗰI

How to Install Moodle 5 on Ubuntu 24.04 (Nginx, PHP 8.3 and PostgreSQL)

Moodle 5 requirements

Step 1: install Nginx, PHP 8.3 and PostgreSQL

Step 2: create the database

Step 3: download Moodle and install its dependencies

Step 4: create moodledata outside the web root

Step 5: configure Nginx for the public directory and the router

Step 6: add HTTPS

Step 7: run the installer

Step 8: schedule Moodle's cron

Step 9: production hardening

Running Moodle next to your other PHP apps

Frequently asked questions

Which PHP version should I use for Moodle 5?

What is the public directory in Moodle 5.1?

Why does Moodle show 404 errors after installing on Nginx?

Should I use PostgreSQL or MariaDB for Moodle?

Why must moodledata be outside the web root?

How often should Moodle cron run?

How to Install PHP 8.5 on Ubuntu 24.04 — and Run Several PHP Versions Side by Side

Which PHP versions are supported in 2026?

What's new in PHP 8.5

Step 1: add the PHP repository

Step 2: install PHP 8.5 and PHP-FPM

Step 3: install other versions side by side

Step 4: give each site its own PHP-FPM pool

Sizing pm.max_children

Step 5: choose the default php command

Step 6: keep PHP patched

Multiple PHP versions with Hanoo

Frequently asked questions

Does Ubuntu 24.04 include PHP 8.5?

Can I run PHP 8.3, 8.4 and 8.5 on the same server?

How do I change the default PHP version on Ubuntu?

Is PHP 8.5 stable enough for production?

Should every site have its own PHP-FPM pool?

How do I enable OPcache in PHP 8.5?

How to Install Magento 2.4.9 on Ubuntu 24.04 (with OpenSearch 3 and PHP 8.5)

Magento 2.4.9 system requirements

Why OpenSearch matters

Option 1: install Magento 2.4.9 manually on Ubuntu 24.04

1. Install PHP 8.5 and the extensions Magento needs

2. Install the database

3. Install and tune OpenSearch 3

4. Download Magento and install its dependencies

5. Run the Magento installer

6. Switch to production mode

7. Configure the web server for pub/

8. HTTPS, file permissions and cron

Option 2: install Magento 2.4.9 with Hanoo

Step 1: connect an Ubuntu server

Step 2: create a Magento application

Step 3: create your admin user

Step 4: add your domain and switch the base URL

Step 5: schedule Magento's cron

Troubleshooting a Magento 2.4.9 installation

The installer stops at OpenSearch

The storefront loads without any styling

"There has been an error processing your request"

Indexers say "Reindex required"

Frequently asked questions

Can I install Magento 2.4.9 on Ubuntu 24.04?

How much RAM does Magento 2.4.9 need?

Does Magento 2.4.9 still support Elasticsearch?

Which PHP version should I use for Magento 2.4.9?

Is it safe to run Magento on my own VPS instead of managed Magento hosting?

How do I find my Magento admin URL?

How to Install WordPress on Ubuntu 24.04 with Caddy, PHP 8.4 and MariaDB

WordPress requirements in 2026

Option 1: install WordPress manually on Ubuntu 24.04

1. Update the server and create a site user

2. Install PHP 8.4 and WordPress's extensions

3. Create the database

4. Download WordPress

5. Write wp-config.php

6. Install Caddy and serve the site

7. Run the famous five-minute install

8. Add an object cache

Option 2: install WordPress with Hanoo

Sizing `pm.max_children`

Step 5: choose the default `php` command

7. Configure the web server for `pub/`

5. Write `wp-config.php`

3. Point the web server at `current/public`