`AH00534: More than one MPM loaded` on start — root cause is Railway injecting `mpm_event.load`, and a fix that lets you use 1.10.3**

Posting this for anyone hitting the YOURLS one-click template and getting an immediate crashloop. **TL;DR:** The crash seems to be Railway-platform-specific (not getting it with local docker container test deploy), the upstream YOURLS Apache image is innocent, and the fix is a one-line `startCommand` on the `yourls` service. My deploy is now running `yourls:1.10-apache` (currently 1.10.3 / Apache 2.4.66 / PHP 8.5.5 / Debian 13) cleanly on Railway with this fix.

**Symptom**

In the `yourls` service logs:

The service never reaches a listening state. The template deploys fine; it's just Apache refusing to start.

**Root cause**

The upstream `yourls:1.10.3-apache` image is not broken. On plain `docker run` (both arm64 and `--platform linux/amd64`), Apache starts cleanly:

On Railway, the same image's `/etc/apache2/mods-enabled/` ends up with both `mpm_prefork.load` AND `mpm_event.load` at container start. I ran a diagnostic container that captures mods-enabled state at three moments:

1. During `docker build` (via a `RUN ls ... > snapshot.txt` step).
2. As PID 1 (by overriding `ENTRYPOINT` to my own script, running before `container-entrypoint.sh`).
3. After manually invoking `container-entrypoint.sh` myself.

Results on Railway:

- Build-time: only `mpm_prefork.*`.
- PID 1: `mpm_prefork.*` AND `mpm_event.*` already present.
- After entrypoint: identical to PID 1 — the image's entrypoint adds nothing.

Diff between build and PID 1:

Also: in the started container, `/etc/apache2/` (the parent directory) has mtime of the current day, while every symlink inside it has the image-layer mtime. Something writes to `/etc/apache2/` between pull and CMD.

This is identical to the issue that seemed to hit many WordPress deployments on Railway mid December, 2025, discussed at <https://station.railway.com/questions/urgent-all-wordpress-sites-deployed-to-07dee2ef>. Same platform injection, same class of `php:*-apache` image, same fix.

Older tag `yourls:1.10.2-apache` tolerates the injection (older Debian/Apache/PHP combo was apparently less strict about multiple MPM symlinks). In my initial testing downgrading to 1.10.2 resulted in a successful deployment.

Full diagnostic write-up on the YOURLS containers repo: <https://github.com/YOURLS/containers/issues/512#issuecomment-4305964008>.

**Fix for anyone deploying the template**

Add a `Start Command` to the `yourls` service (Settings → Deploy → Start Command) that undoes the injection just before Apache reads its config:

Redeploy. Apache will start, YOURLS will be reachable at the service's public domain, admin UI at `/admin/`.

**Confirmed working on current image**: my production is running `yourls:1.10-apache` (floating tag, currently 1.10.3) with exactly this startCommand. Runtime log:

Another options is a 4-line Dockerfile on top of `yourls:1.10-apache` strips the `mpm_event.load`/`mpm_worker.load` symlinks and re-enables `mpm_prefork`. It's redundant on Railway (the symlinks get re-injected after pull), but correct on any platform without this bug.

**Ask to Railway, if anyone from the team sees this**

Would it be possible to look into what's writing to `/etc/apache2/` between image pull and CMD execution on `php:*-apache` containers? It's the same mechanism behind the Dec 12 WordPress outage. Users are patching around it (see lots of "MPM Fix" in community templates) but it keeps resurfacing whenever upstream Apache/PHP bumps to a stricter MPM enforcement. Happy to share the full diagnostic harness if useful.