You don't need Vercel: a static site on Swiss hosting

When you build a website in 2026, the default path is well worn: push to Git, connect Vercel or Netlify, watch it deploy on every commit. It’s good infrastructure, and often the right call.

I went the other way on purpose. This site is a folder of static files on a Swiss shared-hosting box, and it ships with one rsync command. No serverless, no edge runtime, no dashboard — a few francs a month, and I know exactly where the bytes live.

Why Swiss hosting

The interesting part isn’t the mechanics, it’s the where. I host with Infomaniak, a Geneva company, on servers physically in Switzerland. That buys me three things a US hyperscaler can’t.

Sovereignty. My data sits under Swiss law and the GDPR, not the US CLOUD Act. For a static site that sounds academic, but a site is never only HTML — there’s a contact address, request logs, maybe a form later. I’d rather all of it stay on Swiss soil.

Independence. Infomaniak builds and owns its data centers. It isn’t a reseller layer on top of AWS, so “Swiss hosting” means Swiss hardware in Swiss buildings, not a Swiss invoice in front of us-east-1.

It’s genuinely greener. Their data centers run on renewable Swiss energy, and their newest Geneva facility recovers 100% of its energy as heat, feeding the city’s district-heating network to warm around 6,000 households a year. My site’s footprint is rounding-error small either way — but I like that my host’s default behaviour is the responsible one.

None of this needs a 12-factor cloud ☁️. A personal site is small. Hosting it close to home, on infrastructure whose values I can point at, costs me almost nothing and feels a lot better.

It’s just files

After astro build, the whole site is a folder of HTML, CSS, JS, and images. No runtime, no database, no functions to invoke. It’s the most portable artifact in web development, and files don’t need a platform — they need a directory and a web server. Shared hosting has had both since the nineties.

The deploy

The build runs on Bun; the deploy is plain rsync over SSH — a 15-line script:

#!/bin/bash
set -e

SSH_HOST="xxxxx.ftp.infomaniak.com"
SSH_USER="myuser"
REMOTE_PATH="web/maiis.me"

echo "🏗️  Building site..."
bun run build

echo "📦 Syncing..."
rsync -avz --delete \
  --exclude='.DS_Store' \
  --exclude='.git/' \
  dist/ "${SSH_USER}@${SSH_HOST}:${REMOTE_PATH}/"

bun run deploy and I’m live. Two things that bit me:

• The remote path is relative. SSH drops you in your home directory, so it’s web/maiis.me, not /web/maiis.me. The leading slash quietly sends your files nowhere useful.
• --delete makes dist/ the source of truth. The server is mirrored to match the build exactly, so stale files never pile up — but point it at the wrong directory and you’ll have a bad afternoon.

I used to do this over FTP with lftp. Moving to SSH got me encryption, key-based auth, and delta transfers for free. There was no reason to keep using FTP except habit.

What you give up

I won’t pretend it’s free:

• No preview deploys. I preview locally with bun run dev.
• No one-click rollback. Mine is git checkout and a rebuild — slower, but I’ve needed it roughly never.
• No global edge CDN. The site serves from one region, which happens to be where most of my readers are.

There’s also no CI: I self-host my Git and deploy with a command I run on purpose. I’ve come to like that — shipping is a small, deliberate act, not a side effect of merging.

The takeaway

A personal site doesn’t need a hyperscaler. Mine is a folder of files served from Switzerland 🇨🇭, deployed with a script I can read top to bottom in ten seconds. It’s smaller, cheaper, and closer to home than the default — and for the kind of things I build, every one of those is a feature.