Skip to main content
Skip to content
← Back

PROJECT DOSSIER

Web delivery · From source to a live service

Independent development and operation·2024-2026·Web engineering
Next.jsTypeScriptNginxCloudflaresystemd
Web delivery · From source to a live service

The problem

The portfolio, blogs, and product sites share infrastructure, but their content, lifecycle, and access requirements differ. The engineering problem is not just making one page return HTTP 200; it is keeping the service correct after content changes, navigation updates, and subsequent deployments.

I independently maintain this environment, from local builds and content management through domain configuration, deployment, and live verification.

Current implementation

  • Shared code, separate releases. Next.js apps reuse components and tools in a pnpm workspace while retaining their own content roots and deployment flows. Static product sites use their respective release entry points.
  • Domains have deployment owners. A structured registry connects subdomains, source locations, running services, and health URLs. Navigation and operational entry points are derived from that registry.
  • Content is separate from build output. The portfolio's writing lives in its own content repository. Build preparation protects content symlinks and checks source integrity; build folders are not treated as content backups.
  • Access control is enforced at the origin. Public pages can be browsed directly. Administrative routes and private content are behind an authentication gate, with page descriptions matching those boundaries.
  • A complete delivery path. Next.js standalone output is built locally and deployed to a VPS, with Nginx and systemd serving the application and Cloudflare providing DNS and edge proxying.

What counts as a completed release

The deployment script checks live HTTP responses, CSS hashes, build identifiers, and service logs as well as the build result. After a content change, the updated page must be checked online. After a removal, the old URL must be checked independently; a healthy homepage does not prove stale pages have disappeared.

This makes common failures observable: source changes that were never deployed, HTML and assets from different builds, and stale routes left behind by a partial sync.

Inspect the running work

  • English portfolio: bilingual content and case-study routes.
  • Blog: a separately published content site.
  • Initials and KeyScope: product delivery through installation guides, demonstrations, and support content.

Together, these sites show how bilingual content, separate releases, and product delivery share a managed infrastructure.