$ cat blog/building-infrastructure-that-will-host-this-website.md
Building the infrastructure that will eventually host this website
Why the portfolio launches at the current provider first, and why moving it later is being treated as a system-administration project.
This website currently runs at my existing hosting provider. That is temporary by design.
The long-term goal is to move it to infrastructure that I build and operate myself. I am treating that migration as a system-administration project rather than simply a web-design task.
Why not self-host the first release?
Because two objectives are different: publishing a useful portfolio and learning to operate an internet-facing service safely. Delaying the first objective until the second is complete would create the wrong dependency.
The site can therefore go live on conventional provider hosting while I learn the infrastructure layers one by one.
The architecture I want to understand
Current status
The Ubuntu Server host, headless operation, SSH/SFTP administration and network configuration investigation are already part of the lab. KVM/libvirt is the current topic. VM networking and isolation come next.
Web serving, TLS, minimal exposure, monitoring and backup are intentionally later stages. They are objectives, not claimed competencies.
Why use a VM?
The virtualization layer gives me a clean boundary between the physical lab host and the future public service. It also creates a useful learning surface: VM lifecycle, resource allocation, virtual networking, isolation and recovery become explicit parts of the system.
What counts as complete?
Not merely “the page loads”. The end state should include a documented security model, a reproducible deployment, monitoring, backups and a tested restore path. The migration should only happen when the service is understood well enough to operate responsibly.