Back to projects

In operation

Portfolio Infrastructure

A portfolio operated as a real service, with content, deployment, and maintenance treated as one system.

A Japanese-first portfolio built with Next.js and operated from a reused laptop through Docker Compose and Cloudflare Tunnel.

Period
2026.07 - Present
Ownership
Content model · containers · networking · operation
Team
Solo project
Repository
Private repository

Links

Live site

A portfolio that opens reliably and surfaces evidence quickly

Recruiters may not read every page in order. I kept Japanese, English, and Korean content in one data model so they could find major projects, detailed evidence, and the resume quickly.

Even strong content loses credibility when the link itself fails. I therefore treated the information hierarchy and the environment keeping the site online as parts of the same product problem.

Delivery path

A public path to the home server without opening an inbound router port

  1. 01

    Visitor

    Secure browser request

  2. 02

    Cloudflare

    DNS, HTTPS, and Tunnel

  3. 03

    Secure tunnel

    cloudflared container

  4. 04

    Portfolio app

    Next.js standalone in Docker

Publishing a home server without opening router ports

Running the portfolio on a reused laptop required a public path from visitors to the home server.

I wanted to avoid opening an inbound home-router port and keep the app container separate from the public entry path. The configuration also needed to make clear that localhost differs inside each container.

I used Cloudflare Tunnel as the public path and ran the app and cloudflared in the same Docker Compose network, connecting them by service name.

  • Placed the app and cloudflared on the same Compose bridge network.
  • Connected to the app by service name rather than localhost.
  • Recorded the Tunnel, Compose, and network boundary in the repository.

wondde.com is running from the home server with this setup.

Encoding the public path and container-network boundary in configuration made the connection reproducible without relying on operator memory.

A deployment that recovers itself after restart

Because the service runs on a reused laptop, manually restoring the startup order after every reboot or container stop would make recovery depend on my memory and presence.

This is a low-memory personal server, not a commercial setup with automated CI/CD, external monitoring, or verified backup restoration. I needed a repeatable recovery path within the system that actually exists.

I run a Next.js standalone image containing only the required files as a non-root user. Compose healthchecks and restart policies manage readiness and restarts, while the repository records manual update and log-inspection steps.

  • Copied only standalone output into the runtime image.
  • Ran the Next.js process as a non-root user.
  • Captured healthchecks, restart policies, and manual operations in Compose and documentation.

wondde.com runs with the current Dockerfile and Compose configuration. I have not measured recovery time or uptime, and external monitoring is not yet in place.

Deployment includes defining how far the service recovers automatically after a stop and how the remaining steps are restored.

The Japanese portfolio is live at wondde.com, and the repository contains its Dockerfile, Compose and Tunnel configuration, and update procedure.

I no longer treat deployment as a one-time file copy. It includes recovery after restart, correct network boundaries, protected secrets, healthchecks, and enough logging to investigate failures.

Automated CI/CD, an uptime SLA, external monitoring, load tests, and backup/restore verification are not in place yet.

  • Add CI/CD or an approved release workflow
  • Add uptime/latency monitoring and alerts
  • Add log rotation, backup/restore, and a managed-hosting fallback