A step-by-step walkthrough for self-hosting a static Astro site on an isolated VM — with a hardened setup, no SSH, and a real plan for network isolation.
Before the steps: a quick reality check on what this setup gives you and why it works.
You're putting a machine on the public internet. That's a real responsibility — but your posture is inherently safer than most self-hosting scenarios because you're doing three specific things right.
One: the site is static. No PHP, no database, no login page. Almost all compromised web servers get compromised through the application, not the web server itself. You've removed that entire category of risk.
Two: no SSH. You skipped the single most-attacked service on internet-facing Linux boxes. Every service you don't run is a service that can't be exploited.
Three: the VM lives on its own network. If something bad happens to the server, "inside your house" doesn't mean "inside your network." The blast radius is contained.
Six decisions to make before you start. There are no wrong answers here — these are the defaults that will bite you the least.
Long support windows, huge community, most tutorials assume it. Debian is equally fine if you prefer minimal.
nginx has the most current docs. Caddy auto-manages TLS certificates for you — genuinely great if you want to skip that chore.
Free, automated, industry-standard. Renew every 60 days with a systemd timer. Caddy handles this without any config.
Friendly frontend to nftables. Allow 80 and 443 inbound, deny everything else. Since you're not running SSH, don't open 22.
Porkbun and Cloudflare Registrar sell at-cost. Point the A record at your public IP. Dynamic DNS if your IP changes.
Without SSH, deploys happen from the console. Push to a repo, pull from the VM, build locally. Or fetch a CI artifact tarball.
The server hosts what these three tools produce. Worth keeping the two stacks separate in your head: one builds the site, the other runs it.
Package manager for the Node.js ecosystem. Installs Astro, Tailwind, and their dependencies.
Static site framework. Turns your Markdown and .astro files into HTML at build time.
Utility-first styling. Pre-built classes you apply directly in your markup — no separate stylesheet to write.
The whole security model depends on this shape. Traffic from the internet reaches the VM, but the VM cannot reach — and is not reachable from — anything on your regular LAN.
┌─────────────────────────────┐
│ INTERNET │
└──────────────┬──────────────┘
│
│ ports 80, 443
▼
┌─────────────────────────────┐
│ ROUTER │
│ (WAN port forward) │
└─────┬─────────────────┬─────┘
│ │
isolated subnet home LAN
▼ ▼
┌─────────────────────┐ ┌────────────────────┐
│ ▓▓▓ THE VM ▓▓▓ │ │ YOUR LAN │
│ │ │ │
│ nginx / caddy │ │ laptop / phone │
│ ufw + certbot │ │ printer / NAS │
│ Astro dist/ │ │ everything else │
└──────────┬──────────┘ └─────────┬──────────┘
│ │
└──────── ✗ ───────────┘
FIREWALLED APART
The VM reaches the internet. The internet reaches the VM. The VM does not reach your LAN — and your LAN does not reach the VM, except through whatever admin path you deliberately define.
Each phase is self-contained. Get it working before moving to the next. That way, when something breaks, you know it's the new thing that broke — not something three steps back.
Install Ubuntu Server LTS in your hypervisor of choice (VirtualBox, VMware, Proxmox, Hyper-V, whatever you already have). Give it 1–2 GB of RAM, one CPU, and 10–20 GB of disk — plenty for a static site. Boot, log in via the hypervisor console, and get comfortable in the shell.
Install your web server and confirm you can hit a page from your laptop — while everything is still on your normal network. Prove the pieces work in isolation before you start layering complexity.
$ sudo apt update
$ sudo apt install nginx
$ echo "it's alive" | sudo tee /var/www/html/index.html
$ ip addr # find the VM's IPOpen http://[vm-ip] from your laptop's browser. If you see your message, the web server is working. Nothing to do with the internet yet — just LAN.
Only two ports need to be open to the outside world. Everything else stays closed.
$ sudo ufw allow 80/tcp
$ sudo ufw allow 443/tcp
$ sudo ufw enable
$ sudo ufw statusVerify the site still loads from your laptop. If it does, ufw is doing its job — allowing web traffic and blocking the rest.
This is the setup-dependent step. The goal: the VM should be able to reach the internet, but your LAN and the VM shouldn't be able to reach each other. Pick the option that matches your gear:
Buy a domain from any registrar. In the DNS settings, create an A record pointing your domain (and the www subdomain, if you want) at your home's public IP address. You can find your public IP by searching "what is my ip" from any device on your home network.
In your router's admin interface, add port forwarding rules: WAN port 80 → the VM's private IP on port 80, and WAN port 443 → the VM's private IP on port 443. The exact UI is different for every router; look for "Port Forwarding" or "Virtual Servers."
Once the rule is live, your site is reachable from the internet — at least on HTTP. Try loading http://yourdomain.com from your phone (on cellular, not WiFi, so it actually goes out and back). If you see the page, the whole path works.
Now that your domain resolves and port 80 is reachable, certbot can prove you own the domain and issue a real certificate. One command handles everything — the cert, the nginx config edit, and the auto-renewal timer.
$ sudo apt install certbot python3-certbot-nginx
$ sudo certbot --nginx -d yourdomain.com -d www.yourdomain.comAfter it finishes, https:// works and HTTP automatically redirects. Certbot installs a systemd timer that renews the cert every 60 days.
Without SSH, you need a way to get files onto the VM without opening remote access. A few workable patterns:
npm run build right there. Point nginx at the resulting dist/ folder.curl it onto the VM. The VM only needs to fetch — no push access required.Point nginx at the built folder in /etc/nginx/sites-available/default — change the root directive to your dist/ path, then sudo systemctl reload nginx. Reload the page and your Astro site is live.
You're a sysadmin now. Two habits keep the machine healthy without much ongoing effort.
$ sudo apt install unattended-upgrades
$ sudo dpkg-reconfigure --priority=low unattended-upgradesThat takes care of security patches. For monitoring, occasionally skim journalctl -u nginx and /var/log/nginx/access.log. You'll see relentless bot traffic probing for exploits — that's the normal internet. What you're looking for is anything unusual: a spike in 500 errors, requests hitting paths that don't exist on your site, patterns that suggest an actual attack.
Nine phases, one running server, one working site. You built the whole thing yourself — the OS, the network, the web server, the TLS, the deploy pipeline.
The site itself is the smaller half of what you just learned. The bigger half is the mental model: how a request travels from a browser, through the internet, past a firewall, into a process, and back out as HTML. That's the model that makes every future infrastructure decision easier.