This is broken.

It gets stuck on the healthcheck stage. Removing the healthcheck results in a successful deployment, but I am greeted with the Apache2 default page - I believe this is why the healthcheck itself is failing, because it checks against /w/api.php which will be returning HTTP 404.

Hey, thanks for your feedback

I did take a quick look at what's going on and there is something on Railway that prevents it from running as deployment of the same image works just fine via Compose

Specifically, when deployed on Railways there is an extra /etc/apache2/sites-enabled/000-default.conf being installed into the image, despite the file never existed on the image itself as can be seen here https://github.com/WikiTeq/Taqasta/blob/ce8d2cb14ee94c32af9272dc11568b4ecda5999c/templates/base.Dockerfile#L102

I am looking into the issue and will post an update here once I manage to tackle this

Confirmed this is due to Railways issue mentioned here https://station.railway.com/questions/image-layers-with-deleted-files-are-not-d7d808ee?utm%5Fsource=chatgpt.com

The issue has been work-arounded on the template level via custom startup command, so you deployment should succeed after you update the template. Whether Railways fix their runtime the workaround can be removed

If you'd like to unbreak existing deployment without syncing from the template, this can be done by adding the following Custom startup command to the Taqasta service:

bash -c "rm -f /etc/apache2/sites-enabled/000-default.conf && rm -f /etc/apache2/sites-available/000-default.conf && rm -rf /var/www/html && /run-apache.sh"

Noting that the fix of the platform-wide bug that causes this issue is still in progress by the Railway team https://station.railway.com/questions/image-layers-with-deleted-files-are-not-d7d808ee