To be completely honest, managing our production infrastructure was starting to feel unnecessarily complex. The production stack I was maintaining used to be pretty fragmented, running three separate applications simultaneously: Nuxt for the main landing page, a dedicated WordPress instance for the blog, and a custom Laravel application handling the knowledge base.
Having specialized tools for each use case seemed like the right architectural decision at first. But over time, operational overhead started to pile up. Publishing new content required logging into WordPress, while updating documentation meant hopping over to Laravel. Managing three separate deployment pipelines single-handedly was a huge time sink, especially since I run weekly dependency updates to minimize security vulnerabilities.
The tipping point came with the disclosure of two severe PHP security vulnerabilities: CVE-2026-109618 and CVE-2026-109619. Seeing these vulnerabilities surface in short succession was the ultimate red flag. Running two separate PHP runtime environments in production meant double the attack surface and constant anxiety over zero-day patches. Interestingly, that vulnerability panic turned out to be the exact push I needed to re-evaluate the setup, simplify everything, and ditch the PHP runtime altogether.
I started exploring various headless CMS alternatives. Strapi was the obvious first candidate, but its minimum system requirements (1 Core CPU and 2GB RAM) made it an immediate no-go, it would actually consume more server resources than standard WordPress. Using WordPress as a headless backend hit a roadblock too: the default REST API doesn’t expose custom SEO titles and descriptions set via Rank Math out of the box, requiring an additional API request just for metadata. Statamic felt too similar in functionality to what we already had built in Laravel, so migrating there didn’t offer much of an upgrade. I also evaluated Emdash (an Astro-based CMS backed by Cloudflare), but moving our setup over would have required too much development time, particularly to retain our exact slug directory structure domain.com/blog and domain.com/panduan.
Ultimately, consolidating everything into Nuxt proved to be the best path forward. The main challenge was migrating the legacy WordPress posts into static files. I turned to the well-known open-source tool lonekorean/wordpress-export-to-markdown, a CLI utility that converts WordPress XML exports into clean Markdown files along with downloaded images. However, since the default script didn’t extract my custom Rank Math SEO fields and tailored frontmatter tags, I forked it to reynaldiarya/WordPress-Export-To-Markdown. In my fork, I tweaked the parser logic to extract those specific metadata fields, giving me clean Markdown files tailored directly for my Nuxt setup.
What I realized after completing the migration is just how much operational friction disappears when you streamline multiple applications into a single deployment pipeline. I opted for Static Site Generation (SSG) over server-side rendering, as serving pre-rendered static files is far more reliable and secure for a production environment. Interestingly, even without switching to Astro, the site comfortably hits a 90+ PageSpeed score, all while eliminating the complexity of keeping an active PHP runtime alive in production.
Moving forward, keeping architecture lean will remain top of mind. When managing production systems, it’s easy to over-engineer by splitting services until the maintenance cost quietly swallows up all your bandwidth. Sometimes, simplifying the stack is the best optimization you can make.