PHP 8 on Synology DSM 6.2 – Run WordPress on PHP 8.3 with Docker

Synology DSM 6.2’s Package Center stops at PHP 7.4. Instead of upgrading DSM, I kept DSM and Web Station as they are and now run the same WordPress folder and database in the official wordpress:php8.3-apache Docker image. The only change on the NAS is one proxy_pass line in DSM’s nginx, and one command switches back to PHP 7.4.

The scripts and config files are on GitHub: dsm6-wordpress-homeserver (php8-docker/ folder, MIT license).

At a glance

Problem: Package Center on DSM 6.2 only goes up to PHP 7.4, which stopped getting security updates in November 2022
How: run the existing WordPress folder and MariaDB in wordpress:php8.3-apache, mounted at the same paths
What changes: one proxy_pass line in DSM’s nginx (Web Station → container)
Watch out: Web Station rewrites its nginx file and silently puts you back on 7.4, so a Task Scheduler job fixes it every 10 minutes
Rollback: one command back to PHP 7.4; the site stays up the whole time
Code: php8-docker on GitHub (wp-php8.sh, docker-compose.yml, Apache and PHP config)

Why I needed PHP 8

WordPress 7.x still accepts PHP 7.4, so nothing was broken yet. But the next time WordPress raises its minimum PHP version, updates would simply stop. It was already happening with plugins: the lightbox plugin I wanted (Meow Lightbox) requires PHP 8.1 and refused to install.

On a genuine Synology the answer is DSM 7. My NAS has to stay on DSM 6.2, so Docker was the realistic way around it.

How it works: nginx just points somewhere else

Normally the container answers; if it stops, Web Station takes over.

DSM nginx keeps handling HTTPS and the certificate, exactly as before.
The WordPress folder and the MariaDB 10 database stay where they are. The container mounts them at the same paths.
Web Station with PHP 7.4 stays installed as the fallback.

What you need

DSM 6.2 with the Docker package from Package Center
SSH access and an admin account that can use sudo
A WordPress site currently running on Web Station
A backup first: the database, wp-config.php, .htaccess and /etc/nginx/app.d/server.webstation-vhost.conf

Setup with the scripts from GitHub

Install Docker from Package Center.
Copy the php8-docker folder to the NAS, then cp .env.example .env and edit it: WordPress path, web user uid/gid (id http), local port and the MariaDB socket folder.
Edit the settings block at the top of wp-php8.sh: your domain, the install folder, and the Web Station backend port it switches away from.
Run sudo sh wp-php8.sh install. It copies everything to the install folder, starts the container and checks that /wp-login.php and / answer 200. The site is not switched yet.
Run sudo sh <install folder>/wp-php8.sh switch. It changes proxy_pass and reloads nginx only if nginx -t passes.
In DSM, Control Panel → Task Scheduler → Create → Scheduled Task → User-defined script: user root, daily, every 10 minutes, running /bin/sh <install folder>/wp-php8.sh ensure.

# .env (from .env.example)
WP_DIR=/volume1/web/wordpress
WEB_UID=1023          # Web Station's web user: check with  id http
WEB_GID=1023
HOST_PORT=8083        # container listens on 127.0.0.1 only
MYSQL_SOCKET_DIR=/run/mysqld
TZ=Asia/Seoul

Command	What it does
`status`	Container state, PHP version, a test request, and where nginx points
`switch` / `rollback`	Send the site to PHP 8.3 / back to PHP 7.4 (rollback stays until the next switch)
`ensure`	For Task Scheduler: re-apply the switch after Web Station rewrites nginx, or fall back if the container stops
`update`	Pull the newest PHP 8.3 image (security fixes) and restart
`fixowner`	Give files created as root back to the web user
`logs`	PHP error log and Apache log

The important parts of the configuration

docker-compose.yml

The image’s own WordPress setup step is skipped (custom entrypoint), so it serves the files already on the NAS. The port is bound to 127.0.0.1, so only nginx on the NAS can reach it.

services:
  web:
    image: wordpress:php8.3-apache
    restart: unless-stopped
    entrypoint: ["docker-php-entrypoint"]   # skip the image's WordPress copy step
    command: ["apache2-foreground"]
    user: "${WEB_UID}:${WEB_GID}"            # run as Web Station's web user, never root
    ports:
      - "127.0.0.1:${HOST_PORT}:8080"        # reachable from the NAS only
    volumes:
      - ${WP_DIR}:${WP_DIR}                  # same path inside and outside
      - ${MYSQL_SOCKET_DIR}:${MYSQL_SOCKET_DIR}
      - ./php/zz-custom.ini:/usr/local/etc/php/conf.d/zz-custom.ini:ro
      - ./apache/ports.conf:/etc/apache2/ports.conf:ro
      - ./apache/000-default.conf:/etc/apache2/sites-available/000-default.conf:ro
      - ./apache/remoteip.conf:/etc/apache2/conf-available/remoteip.conf:ro

Mounting the WordPress folder at the same path matters: some plugins store absolute paths, and they break in odd places if the path changes. For the database, the container gets the MariaDB socket folder, so the socket path already in wp-config.php (localhost:/run/mysqld/mysqld10.sock on DSM 6.2 with MariaDB 10) keeps working.

Visitor IP and HTTPS (remoteip.conf)

From the container’s point of view every request comes from nginx on the NAS. Without this, every visitor has the same IP and WordPress doesn’t know the request was HTTPS. Like Web Station does, it trusts the headers from nginx only when they come from the Docker network.

RemoteIPHeader X-Real-IP
RemoteIPInternalProxy 172.16.0.0/12
SetEnvIf X-Forwarded-Proto "^https$" HTTPS=on

The one nginx line

In the Web Station virtual host file DSM generates (/etc/nginx/app.d/server.webstation-vhost.conf), only the site’s proxy_pass changes. Check the current port in that file first; mine pointed to Web Station’s Apache on 915.

# Web Station (PHP 7.4) → container (PHP 8.3)
sed -i 's|proxy_pass  http://127.0.0.1:915;|proxy_pass  http://127.0.0.1:8083;|g' /etc/nginx/app.d/server.webstation-vhost.conf
nginx -t && nginx -s reload

wp-php8.sh switch does exactly this, after checking that the container answers, and puts the line back if nginx -t fails.

Three problems I ran into

1. After a reboot it was quietly back on PHP 7.4

Web Station rewrites its nginx file on reboots, setting changes and certificate renewals. That resets the proxy_pass line, and the site keeps working on PHP 7.4, so you don’t notice. The 10-minute ensure job switches it back, and if the container stops answering, it falls back to PHP 7.4 by itself.

2. The container ran as root and changed file owners

At first I only set Apache’s run user, but the container itself still ran as root. The site worked, but 2,706 files created in the meantime (plugin installs and so on) ended up owned by root. Running the whole container as the web user (user: "1023:1023") fixed it. A non-root Apache can’t bind port 80, so it listens on 8080 inside. wp-php8.sh fixowner gives root-owned files back to the web user.

3. WP-CLI on the host is still PHP 7.4

The command-line WP-CLI on the NAS still uses DSM’s PHP 7.4. That’s fine for most tasks, but plugins that require PHP 8 have to be installed from wp-admin instead.

One more thing: WordPress email (contact form notifications and so on) wasn’t leaving the NAS before either, because DSM’s mail relay was empty. Switching PHP doesn’t change that; use an SMTP plugin if you need mail.

Rolling back

Web Station and PHP 7.4 are still there, so going back is one command. A rollback stays in place until you run switch again; the 10-minute job won’t undo it.

sudo sh /volume1/ops/wp-php8/wp-php8.sh rollback   # back to PHP 7.4
sudo sh /volume1/ops/wp-php8/wp-php8.sh switch     # PHP 8.3 again
sudo sh /volume1/ops/wp-php8/wp-php8.sh update     # newest PHP 8.3 image

These scripts run as root, so read them before you use them, and back up first.

Frequently asked questions

Is there a PHP 8 package for DSM 6.2?

Not in my DSM 6.2 Package Center; PHP 7.4 was the last one. If you have to stay on DSM 6, Docker is the most practical route. On a genuine Synology, upgrading to DSM 7 comes first.

Is WordPress slower in Docker?

I didn’t run benchmarks, but time to first byte from within Korea stayed at about 0.3–0.5 seconds, the same as before. nginx and the container talk inside the same NAS, so there is almost no added delay.

Do I have to move my files or database?

No. The container uses the same folder and the same database, which is also why rolling back is just one nginx line.

Does it work on DSM 7?

The scripts are written for DSM 6.2’s Web Station and nginx layout and are only tested there. On DSM 7, Web Station already offers PHP 8.

Docker on the NAS has been handy for other things too, like the Minecraft Forge server I ran for friends.

This is a translation of my original Korean article: DSM 6.2에서 PHP 8 쓰기 – 도커로 워드프레스 PHP 8.3 전환. Last checked: 25 October 2026 (WordPress 7.1, PHP 8.3).