Eine eigene Wave für den Shop
Ich wollte etwas Neues abseits meiner statischen Website bauen: mit Next.js, einem eigenen Node-Prozess und neuer Infrastruktur, aber weiterhin unter newwaves.dev und auf demselben VPS. Der Shop ist zunächst ein technischer und gestalterischer Test, hat aber das Potenzial, später ein echter eigener Shop zu werden. Dafür bekam er von Anfang an eine eigene Subdomain: shop.newwaves.dev.
newwaves.dev bleibt die Heimat für Website, Projekte und Blog. Unter shop.newwaves.dev läuft getrennt davon der Shop. Zwei Websites, ein VPS und für jede Aufgabe eine klare Adresse.
Warum eine eigene Subdomain
Die statische Website besteht aus HTML, CSS und etwas JavaScript. Der Shop läuft dagegen mit Next.js als eigener Node-Prozess. Beides unter derselben Domain zu vermischen, hätte Routing, Deployment und spätere Änderungen unnötig miteinander verknotet.
Eine Subdomain hält die Grenze sichtbar: Die Hauptdomain gehört dem Blog, die Shop-Subdomain dem neuen Projekt. Beide können unabhängig voneinander gebaut, aktualisiert und bei Bedarf zurückgerollt werden.
Bestandsaufnahme auf dem VPS
Bevor der Shop dazukam, habe ich den bestehenden Server gemeinsam mit Claude Code und Codex durchleuchtet:
- Die statische Website liegt als sauberer Git-Clone unter
/var/www/newwaves.dev. - NGINX übernimmt bereits HTTPS und die sauberen URLs ohne
.html. - Eigene Deploy-Scripte oder zusätzliche Automatisierung waren nicht im Weg.
- Für den zusätzlichen Node-Dienst waren genug Speicher und Arbeitsspeicher vorhanden.
Damit war klar, dass der VPS nicht neu aufgesetzt werden muss. Er bekommt einfach einen zweiten Webroot, einen zusätzlichen NGINX Server Block und einen systemd-Service für Next.js.
Backup an drei Orten
Vor dem Umbau wurde der vollständige Zustand gesichert. Der Code beider Websites liegt jeweils in einem privaten GitHub-Repository. Auf dem VPS entstand zusätzlich ein Archiv aus beiden Webroots, der NGINX-Konfiguration, Let's Encrypt und dem systemd-Service.
Das Archiv bekam eine SHA256-Checksumme, wurde auf meinen Rechner geladen und dort erneut geprüft. Gleicher Hash, gleiche Daten. Damit liegt der relevante Stand auf GitHub, auf dem VPS und lokal.
sudo tar -czf /var/backups/newwaves-website/newwaves-domain-setup.tar.gz \
/var/www/newwaves.dev \
/var/www/newwaves-shop \
/etc/nginx/nginx.conf \
/etc/nginx/sites-available \
/etc/nginx/sites-enabled \
/etc/letsencrypt \
/etc/systemd/system/newwaves-shop.service
Zwei Websites, ein VPS
NGINX entscheidet anhand des Hostnamens, welche Website eine Anfrage bekommt. Die beiden Projekte bleiben dadurch sauber getrennt:
- newwaves.dev liefert die statische Website aus
/var/www/newwaves.dev. - shop.newwaves.dev leitet intern an den Next.js-Prozess weiter.
Der Shop läuft als newwaves-shop.service unter systemd. Dadurch startet er nach einem Reboot automatisch neu. NGINX bleibt die einzige öffentliche Eingangstür und kümmert sich um HTTPS, HSTS und die Proxy-Header.
Eigene Zertifikate, klare Zuständigkeiten
Die Hauptdomain samt www behält ihr bestehendes Let's-Encrypt-Zertifikat. Für shop.newwaves.dev gibt es ein eigenes Zertifikat. Certbot erneuert beide automatisch, der Dry-Run war für beide erfolgreich.
www.newwaves.dev leitet dauerhaft auf die Hauptdomain weiter. So gibt es für die Website eine eindeutige kanonische Adresse, während der Shop sichtbar seine eigene Subdomain behält.
Der Workflow bleibt klein
Die statische Website wird weiterhin lokal bearbeitet, zu GitHub gepusht und auf dem VPS per git pull aktualisiert. Beim Shop kommen danach noch npm ci, der Build und ein Neustart des systemd-Service dazu. Zwei Projekte, zwei Deploy-Wege und keine unnötige Magie dazwischen.
Learning in Public geht weiter
newwaves.dev bleibt mein Platz für Projekte, Experimente und Notizen. Der Shop läuft eine Tür weiter unter shop.newwaves.dev. Was dort technisch und gestalterisch entsteht, wird wahrscheinlich noch genug Stoff für weitere Beiträge liefern.