Week 055 — Production Finally Ships

This is the week srchParty runs on a real server.

Week of December 8, 2025

Progress

Monday: the dev Docker compose was refactored and tested on a second machine for the first time. It worked. Dynamic SITE_URL bootstrapping was implemented so the URL doesn't need to be hardcoded in .env per machine.

Tuesday: the production Docker image was built and pushed to GitHub Container Registry. The DigitalOcean droplet was configured — firewall ports opened, project directory created, compose file deployed, reserved IP set.

Wednesday: production was not coming up. Two problems found. First, sudo docker uses root's configuration, not the user's — which meant the GitHub PAT the user had configured wasn't visible to Docker when run with sudo. Second, the .env file was empty in the container's html directory; the Dockerfile needed a COPY instruction to include it in the image.

After .env was fixed, a PHP fatal error appeared: Class "SrchParty\Classes\Database" not found. The class file was named database.php (lowercase), but the autoloader expected Database.php. On macOS (case-insensitive filesystem) this worked fine. On the Linux container it failed. The fix was renaming the file to match the class name.

Thursday: images weren't persisting between container restarts. The uploads directory was baked into the image instead of mounted as a volume. A named volume was created for uploads in both production and development — keeping the environments consistent and preventing uploads from being included in future image builds.

A separate issue: saving a user profile had a multi-second delay. Traced to a raw PDO connection being created in the users API (leftover from before the DTO/Service/Repo refactor). The connection was attempting to use parameters that weren't valid in the new environment and timing out silently. Commenting out that code removed the delay.

Saturday: switched from phpMyAdmin to Adminer for the database admin container. Smaller, more secure, can be stopped when not in use.

Learnings

Docker and case sensitivity: A file named database.php on macOS works anywhere on that machine because the OS abstracts case. In a Linux container built from an image (not a mounted volume), the filesystem is case-sensitive and the mismatch causes a fatal. The safe practice: name class files to exactly match the class name, and consider using a volume for source code so that case errors break in development rather than in production.

Next Week

Subscribe page route not working in production.