Why vasiloiu.com Is a Static VitePress Site
I wanted a Markdown-based technical blog with reproducible builds, readable articles, and no application process to operate. VitePress meets those requirements by producing static files that can be served without running Node.js in production.
Azure Static Web Apps is the deployment target. The architecture, however, depends only on static hosting rather than Azure-specific runtime behavior.
Why a static build
The site does not need authentication, server-side business logic, a database, or content generated for each request. Node.js and VitePress are build dependencies; the production artifact is the contents of .vitepress/dist.
This removes the need to maintain an application process, runtime package updates, server configuration, and infrastructure for keeping that process available.
Why VitePress
VitePress provides routing, syntax highlighting, navigation, an outline, local search, and a development server. It also supports Vue components where Markdown is not enough.
The articles remain Markdown files under posts/. Custom theme components implement the home page, archives, categories, tags, pagination, and article metadata.
The production build is a single npm command:
npm run buildThis runs vitepress build and writes the deployable files to .vitepress/dist.
What the custom build code does
The build scans posts/**/*.md, reads each post's frontmatter, normalizes its date and ordering, and sorts the collection. That metadata drives the article list, archives, categories, and tags.
It also generates pagination pages from the number of posts. VitePress creates the local search index as part of the static output, so search does not require an external service.
The tradeoff
VitePress adds more machinery than a basic Markdown-to-HTML converter. The repository contains Vue components, build-time content loading, generated pages, and custom CSS that must remain compatible with VitePress.
The most obvious implementation issue is pagination. It currently writes generated Markdown pages into the source tree, coupling the build to source-tree mutation. Route generation or a data-loading approach would remove that coupling if pagination becomes significant.
For this site, the remaining complexity stays at build time. The deployed result is still a directory of static files, and changing hosts would affect deployment configuration rather than the content model.