At one point during this project, a development server sat on a single step labelled Harmonizing for over seven hours. Not stuck on an error. Not crashed. Just running, silently, with nothing to show for it. That single moment is a fair summary of the month that preceded it: real effort, applied constantly, to a problem that kept generating new problems.
The goal was simple to state: a personal website to publish SAP and AI content on my own domain, self hosted on my Synology NAS rather than handed to a platform I do not control. The architecture I chose to get there was a full headless CMS, Strapi, backed by PostgreSQL, running in Docker, with a separate development instance alongside production. It is a completely reasonable architecture. It is also considerably more machine than a one person blog actually needs.
Getting there meant fighting the stack itself rather than writing anything. A custom Docker image had to be built by hand after the prebuilt one refused to initialise. TypeScript compilation failed against a content type that did not exist yet. A content type that did exist failed with a cryptic error tracing back to a missing component definition, the kind of failure that only shows up once you dig past the first error message to the real one underneath. Then the database layer itself: a dialect that Strapi could not recognise, followed immediately by a configuration error that made it look like no database was configured at all, on a database that was very much running.
Every one of these was individually solvable, and every one of them was solved. That was exactly the problem. The pattern was not one hard bug. It was an unbroken sequence of infrastructure fighting back, one layer at a time.
The moment that mattered was not a fix. It was a question: what am I actually building this for. A personal blog does not need multi-user roles, a relational database, or a production and development environment kept permanently in sync. It needs content and a place to publish it. Once that was named plainly, the entire Strapi and PostgreSQL stack stopped looking like infrastructure and started looking like unnecessary surface area, a large collection of things that could fail for a job that did not require any of them.
The pivot was to a static site built with Astro, content stored as plain Markdown files, version controlled in git, deployed automatically to Vercel on every push. There is no database to misconfigure, because there is no database. There is no server process that can hang for seven hours, because there is no server process at runtime at all, only a build step that either succeeds or fails immediately and says why. Adding a new post is creating a file. Publishing it is a git push.
It is worth being honest about the trade. There is no browser based editor for someone non technical to log into and write a post. Every new piece of content goes through a file and a command line, which was an acceptable cost for a one person site and would not be for a team publishing daily. The right architecture depends entirely on who is actually doing the publishing, and for this project, that was one person willing to work in Markdown.
The lesson was not about Strapi, Docker, or any specific error message. It was that persistence and debugging skill can make almost any architecture eventually work, and that is exactly the trap. The better question, asked earlier, is whether the architecture matches the actual job. This website, the one you are reading this on, is the direct result of finally asking that question instead of solving the next error in line.