Das Repo ist privat, ein HTTPS-Clone auf dem Server wuerde interaktiv nach Zugangsdaten fragen. Stattdessen ein repo-eigener Deploy-Key mit Nur-Lese- Rechten und ein eigener Host-Alias, damit der Key nicht bei anderen GitHub-Repos angeboten wird. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
djnizz.at
Website von DJ NIZZ. Astro 7 (statisch vorgerendert) hinter einem Node-Server, Tailwind 4, ausgeliefert per Docker + Caddy mit automatischem HTTPS.
Inhalte ändern
Fast alles steht in src/data/site.ts – Texte, Genres,
Kontaktdaten, Navigation, Social-Links. Für normale Textänderungen musst du
keine Komponente anfassen.
- Social-Profile: In
SOCIALSdieurleintragen. Einträge ohne URL werden automatisch ausgeblendet, du kannst also alles stehen lassen, was du noch nicht hast. - Neues Genre: In
GENRESergänzen. Marquee, Genre-Karten, Zähler in der About-Sektion, Footer-Text und die strukturierten Daten ziehen automatisch nach. Für die Akzentfarbe muss der Name inaccentVarinsrc/components/About.astroexistieren. - Impressum / Datenschutz:
src/pages/impressum.astroundsrc/pages/datenschutz.astro.
Lokal entwickeln
npm install
npm run dev
Läuft auf http://localhost:4321.
npm run build # nach dist/ bauen
npm run preview # gebaute Seite wie in Produktion starten
Bild-Assets
Die Quellbilder liegen in src/assets/. Abgeleitete Dateien (Hero-Hintergrund,
OG-Bild, Favicons) erzeugt:
npm run assets
Der freigestellte Render src/assets/nizz-cutout.png entsteht separat aus dem
Ganzkörper-Bild:
node scripts/cutout.mjs pfad/zum/render.jpg src/assets/nizz-cutout.png 70
Das Skript trennt über eine Sobel-Kantenkarte frei und entfernt zusätzlich eingeschlossene Hintergrundflächen (z. B. zwischen Arm und Oberkörper). Der letzte Parameter ist die Kantenschwelle – höher = aggressiver, damit fallen weiche Bodenschatten weg.
Deployment auf Oracle Cloud
Läuft sowohl auf Ampere A1 (ARM) als auch auf x86 – die verwendeten Images sind Multi-Arch.
1. Netzwerk freigeben (zwei Stellen!)
Der häufigste Stolperstein bei OCI: Ports müssen sowohl in der Cloud-Firewall als auch in der Instanz freigegeben werden.
a) VCN Security List / NSG in der OCI-Konsole – Ingress-Regeln für
0.0.0.0/0 auf TCP 80 und TCP 443 (und UDP 443, wenn HTTP/3 genutzt werden soll).
b) Firewall in der Instanz. Oracle-Linux-Images bringen firewalld mit:
sudo firewall-cmd --permanent --add-service=http --add-service=https
sudo firewall-cmd --permanent --add-port=443/udp
sudo firewall-cmd --reload
Ubuntu-Images von Oracle haben stattdessen eine restriktive iptables-Regel:
sudo iptables -I INPUT 6 -m state --state NEW -p tcp --dport 80 -j ACCEPT
sudo iptables -I INPUT 6 -m state --state NEW -p tcp --dport 443 -j ACCEPT
sudo netfilter-persistent save
2. DNS
A-Record djnizz.at → öffentliche IP der Instanz. Wenn www.djnizz.at genutzt
werden soll, dafür ebenfalls einen A-Record anlegen – sonst den www-Block im
Caddyfile auskommentieren, weil Caddy sonst dauerhaft erfolglos
ein Zertifikat dafür anfordert.
3. Docker installieren
curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker $USER
Danach einmal neu einloggen.
4. Deploy-Key einrichten
Das Repo ist privat, ein HTTPS-Clone auf der VM würde also nach Zugangsdaten fragen. Stattdessen bekommt die VM einen eigenen Deploy-Key mit Nur-Lese-Rechten:
ssh-keygen -t ed25519 -C "djnizz-vm-deploy" -f ~/.ssh/djnizz_deploy -N ""
cat ~/.ssh/djnizz_deploy.pub
Den ausgegebenen Public Key in GitHub unter Repo → Settings → Deploy keys → Add deploy key eintragen und Allow write access nicht anhaken.
Anschließend einen eigenen Host-Alias anlegen – bewusst nicht Host github.com,
sonst würde dieser Key auch bei allen anderen GitHub-Repos angeboten und dort
scheitern:
cat >> ~/.ssh/config <<'EOF'
Host github-djnizz
HostName github.com
User git
IdentityFile ~/.ssh/djnizz_deploy
IdentitiesOnly yes
EOF
chmod 600 ~/.ssh/config
ssh -T git@github-djnizz
Die letzte Zeile muss mit Hi nizzgruber/djnizz_website! You've successfully authenticated antworten. Dass GitHub danach „does not provide shell access"
meldet, ist normal und kein Fehler.
5. Starten
git clone git@github-djnizz:nizzgruber/djnizz_website.git
cd djnizz_website
docker compose up -d --build
Caddy holt sich das Let's-Encrypt-Zertifikat automatisch, sobald die Domain auf den Server zeigt. Fortschritt prüfen:
docker compose logs -f caddy
Updates ausrollen
git pull
docker compose up -d --build
Konfiguration
Domain und ACME-Mailadresse lassen sich per .env neben der
docker-compose.yml überschreiben:
DOMAIN=djnizz.at
ACME_EMAIL=business.djnizz@gmail.com
Das Volume
caddy_dataenthält die TLS-Zertifikate. Nicht löschen – sonst werden bei jedem Neustart neue Zertifikate angefordert und irgendwann greift das Rate-Limit von Let's Encrypt.
Datenschutz
Die Seite lädt nichts von externen Servern: Schriften sind selbst gehostet, es
gibt keine Cookies, kein Tracking und keine eingebetteten Player. Caddy kürzt in
den Access-Logs die Client-IP (ip_mask) und löscht sie nach 14 Tagen – das muss
so bleiben, sonst stimmt die Datenschutzerklärung nicht mehr.
Wenn später ein Booking-Formular, Analytics oder Spotify-/YouTube-Embeds
dazukommen, muss src/pages/datenschutz.astro entsprechend erweitert werden.
Struktur
src/
assets/ Bilder (werden beim Build zu WebP/AVIF optimiert)
components/ Header, Hero, About, Footer, SocialIcon
data/site.ts Zentrale Inhalts- und Konfigurationsdatei
layouts/ Base (SEO, JSON-LD), Legal
pages/ index, impressum, datenschutz, 404
styles/ global.css (Tailwind-Theme, Animationen)
scripts/ Einmalige Bildaufbereitung
Die Seiten sind alle vorgerendert. Der Node-Adapter ist trotzdem drin, damit
später einzelne Routen (z. B. /api/booking) mit export const prerender = false
dynamisch werden können, ohne dass sich am Deployment etwas ändert.