Von der Idee zur Live-Website – Deployment-Guide für Einsteiger

51 Min. Lesezeit

Stell dir vor: Du hast wochenlang an deinem ersten Projekt gearbeitet. Das Portfolio sieht fantastisch aus, alle Features funktionieren perfekt, und auf localhost:3000 läuft alles butterweich. Deine Freunde und Familie wollen endlich sehen, woran du so lange gearbeitet hast. Voller Stolz öffnest du den Terminal, tippst npm run build und… jetzt kommt der Moment, wo die meisten Einsteiger ins Stocken geraten: Wie zur Hölle bekomme ich das Ding jetzt ins Internet?

Du googlest verzweifelt “Website online stellen”, landest in einem Wust aus FTP-Tutorials von 2010, verworrenen Apache-Konfigurationen und Deployment-Guides, die voraussetzen, dass du bereits weißt, was ein “Build-Prozess” ist. Nach zwei Stunden bist du frustrierter als zuvor, und deine Website läuft immer noch nur auf deinem Laptop.

Kommt dir bekannt vor? Dann ist dieser Guide genau für dich.

Die gute Nachricht: Deployment ist Heute dramatisch einfacher geworden – wenn man weiß, welche Tools man nutzen sollte. In diesem Guide zeige ich dir Schritt für Schritt, wie du deine Website mit modernen Plattformen wie Netlify oder Vercel in unter 10 Minuten live bekommst. Inklusive Custom Domain, SSL-Verschlüsselung und automatischem Deployment bei jedem Git Push.

Von der Idee zur Live-Website – Deployment-Guide für Einsteiger

In diesem Guide lernst du alles, was du brauchst, um deine erste Website professionell zu deployen. Du verstehst den Unterschied zwischen Deployment und Hosting, vergleichst Netlify und Vercel, deployest Schritt für Schritt deine erste Site, richtest eine Custom Domain mit SSL ein, konfigurierst Environment Variables sicher, baust eine automatische CI/CD-Pipeline auf und vermeidest die 5 häufigsten Anfängerfehler.

Am Ende dieses Guides hast du eine live Website mit deiner eigenen Domain, automatischem Deployment und allem, was dazugehört. Klingt kompliziert? Ist es nicht – versprochen!

Lass uns loslegen!

Warum Deployment so einschüchternd wirkt (und warum es das nicht sein muss)

Viele Tutorials enden mit “npm run dev” – und dann? Die meisten Anfänger wissen, wie man Code schreibt, aber nicht, wie man ihn veröffentlicht. Das führt zu Frustration, aufgeschobenen Projekten und dem Gefühl, dass man “noch nicht soweit” ist.

Ich sehe das regelmäßig in Entwickler-Communities: Jemand hat ein tolles Projekt gebaut, aber es liegt seit Monaten auf der Festplatte, weil der letzte Schritt – das Deployment – zu kompliziert wirkt. Dabei ist genau dieser letzte Schritt der, der aus einem Hobby-Projekt ein echtes Portfolio-Piece macht.

Das Problem: Die Deployment-Landschaft hat sich radikal verändert, aber viele Tutorials sind noch in der alten Welt verhaftet. Sie erklären FTP-Uploads, Server-Konfiguration und manuelle SSL-Zertifikate – Dinge, die du Heute nicht mehr brauchst.

Die alte Welt: FTP, Apache und Server-Konfiguration

Bis vor wenigen Jahren war Website-Deployment eine echte Herausforderung. Du musstest dich mit Server-Administration auskennen, Konfigurationsdateien bearbeiten und hoffen, dass nach dem Upload alles noch funktioniert. Ein falscher Klick in FileZilla und deine Live-Website war kaputt – ohne Rollback-Möglichkeit.

Was du früher brauchtest:

Warum das so kompliziert war:

Server-Administration war eine eigene Disziplin. Du musstest Linux-Befehle kennen, Dateiberechtigungen verstehen und wissen, wie man Apache-Konfigurationen schreibt. Ein Fehler in der .htaccess-Datei konnte deine gesamte Website lahmlegen.

Es gab keine Rollbacks bei Fehlern. Wenn du versehentlich die falsche Datei überschrieben hast, war sie weg. Hoffentlich hattest du ein Backup – aber wer macht schon vor jedem kleinen Update ein Backup?

SSL-Zertifikate kosteten bis 2015 Geld (50-200€ pro Jahr) und mussten manuell installiert werden. HTTPS war ein Luxus, den sich nur professionelle Sites leisten konnten. Heute undenkbar!

Jede noch so kleine Änderung musste manuell hochgeladen werden. Typo im Footer gefunden? FTP öffnen, die richtige Datei finden, hochladen, hoffen dass es funktioniert. Kein Continuous Deployment, kein automatischer Build-Prozess.

Ein Staging-Environment für Tests? Das bedeutete oft einen zweiten Server mit extra Kosten. Die meisten Entwickler haben direkt auf Production deployed und die Daumen gedrückt.

Die neue Welt: Git Push und fertig

Heute ist Deployment dramatisch einfacher geworden. Moderne Plattformen wie Netlify, Vercel, Railway und Cloudflare Pages haben den Prozess revolutioniert:

Was du heute brauchst:

Was automatisch passiert:

Der Build-Prozess läuft vollautomatisch auf dem Server. Du pushst deinen Code, und die Plattform kümmert sich um npm install, npm run build und die gesamte Optimierung. Du musst dich um nichts davon kümmern.

SSL-Zertifikate werden kostenlos und automatisch generiert. Sobald deine Domain verbunden ist, bekommst du ein Let’s Encrypt-Zertifikat – ohne dass du eine Zeile Konfiguration schreiben musst. Die Erneuerung passiert ebenfalls automatisch alle 90 Tage.

Rollbacks funktionieren mit einem einzigen Klick. Jeder Deploy wird gespeichert, und du kannst jederzeit zu einer früheren Version zurückkehren. Fehler im Production-Build? Kein Problem – in 10 Sekunden läuft wieder die vorherige Version.

Deploy Previews werden für jeden Pull Request automatisch erstellt. Dein Team oder du selbst kann Änderungen testen, bevor sie live gehen. Jeder Branch bekommt seine eigene Test-URL.

Ein globales CDN und Edge Network sind inklusive. Deine Website wird automatisch auf Servern weltweit verteilt. Ein Nutzer in Tokio lädt deine Site genauso schnell wie jemand in Berlin.

Der Free Tier ist für die meisten Projekte völlig ausreichend. Kleine bis mittelgroße Websites können komplett kostenlos gehostet werden – ohne versteckte Kosten oder Limitierungen, die dich ausbremsen.

Der Paradigmenwechsel:

AspektAlte Welt (FTP)Neue Welt (Git-basiert)
DeploymentFTP UploadGit Push
SSLManuell/kostenpfl.Automatisch/kostenlos
RollbackBackup wiederherstellenEin Klick
CI/CDManuellAutomatisch
StagingOft nicht vorhandenDeploy Previews
PerformanceEinzelner ServerGlobal CDN
Kosten (klein)5-10€/MonatKostenlos

Deployment vs. Hosting – Die Grundlagen verstehen

Bevor wir loslegen, lass uns die wichtigsten Begriffe klären. Viele verwechseln Deployment und Hosting – dabei sind das zwei verschiedene Dinge.

Was ist Deployment?

Deployment ist der Prozess, deine Anwendung von deinem lokalen Rechner auf einen Server zu bringen und dort auszuführen.

Stell dir Deployment wie das “Veröffentlichen” eines Buches vor: Du hast das Manuskript geschrieben (dein Code), aber es liegt noch auf deinem Schreibtisch. Deployment ist der Moment, wo du es drucken lässt, in Buchhandlungen verteilst und der Öffentlichkeit zugänglich machst. Erst dann können andere Leute es lesen.

Der typische Deployment-Prozess:

# 1. Code schreiben
# (du arbeitest lokal an deinem Projekt)

# 2. Build erstellen
npm run build
# → Erstellt optimierte Production-Version in /dist oder /build

# 3. Build deployen
git push origin main
# → Plattform erkennt Push, lädt Code herunter, führt Build aus

# 4. Live!
# → Website ist unter URL erreichbar

Was beim Deployment passiert:

Im Hintergrund läuft eine ganze Kette von Prozessen ab. Zuerst wird dein Source Code auf den Server übertragen – entweder direkt aus deinem Git-Repository oder als gezipptes Paket. Die Plattform lädt den Code herunter und beginnt mit der Verarbeitung.

Als nächstes werden alle Dependencies installiert. Die Plattform führt npm install (oder yarn install, pnpm install) aus und lädt alle Pakete herunter, die dein Projekt braucht. Das passiert auf dem Server, nicht auf deinem Rechner.

Dann wird der Build-Prozess ausgeführt. npm run build kompiliert deinen TypeScript-Code, optimiert deine Assets, minimiert JavaScript und CSS, und erstellt die produktionsreife Version deiner Website im /dist oder /build Ordner.

Die statischen Files werden auf ein CDN (Content Delivery Network) verteilt. Deine HTML-, CSS-, JS- und Bild-Dateien werden auf Servern weltweit gespeichert, damit sie überall schnell geladen werden können.

Falls du eine Custom Domain hast, wird das DNS aktualisiert oder überprüft, damit deine Domain auf die richtigen Server zeigt. Bei der ersten Einrichtung kann das ein paar Minuten dauern.

Abschließend wird ein SSL-Zertifikat generiert oder erneuert, damit deine Website über HTTPS erreichbar ist. Let’s Encrypt stellt das kostenlos bereit, und die Plattform kümmert sich automatisch um die Erneuerung.

Was ist Hosting?

Hosting ist der Service, der deine Website rund um die Uhr verfügbar macht. Der Host stellt die Server-Infrastruktur bereit.

Während Deployment ein einmaliger Vorgang ist (oder bei Updates wiederholt wird), ist Hosting der dauerhafte Service. Dein Host sorgt dafür, dass deine Website 24/7 erreichbar ist, Requests beantwortet werden und alles läuft, auch wenn du schläfst.

Arten von Hosting:

Shared Hosting bedeutet, dass deine Website auf einem Server liegt, den du dir mit dutzenden oder hunderten anderen Websites teilst. Das ist die billigste Option (2-5€/Monat), aber auch die langsamste. Wenn eine andere Site auf dem Server einen Traffic-Spike hat, leidet deine Performance mit. Beispiele: Strato, IONOS, HostEurope.

VPS (Virtual Private Server) gibt dir einen virtuellen Server, der nur dir gehört. Du hast mehr Kontrolle und bessere Performance, musst dich aber selbst um Updates, Security und Konfiguration kümmern. Das ist was für fortgeschrittene Nutzer. Kosten: 5-20€/Monat. Beispiele: DigitalOcean, Linode, Hetzner.

Dedicated Server ist ein komplett physischer Server, der nur für dich läuft. Maximale Performance und Kontrolle, aber auch maximaler Aufwand und Kosten (50-200€+/Monat). Das brauchst du nur für sehr große Projekte oder spezielle Anforderungen.

Static Site Hosting ist die moderne Lösung für Websites ohne Server-seitigen Code. Deine HTML/CSS/JS-Files werden direkt ausgeliefert, extrem schnell und sicher. Das ist was wir in diesem Guide nutzen. Beispiele: Netlify, Vercel, Cloudflare Pages. Kosten: Meistens kostenlos!

Serverless bedeutet, dass dein Code nur läuft, wenn er gebraucht wird. Statt einen Server 24/7 laufen zu lassen, werden Functions “on-demand” ausgeführt. Du zahlst nur für die tatsächliche Ausführungszeit. Perfekt für APIs und Backend-Logic. Beispiele: AWS Lambda, Vercel Functions, Netlify Functions.

Static Sites vs. Dynamic Sites – Was ist der Unterschied?

Dieser Unterschied ist entscheidend für die Wahl deiner Plattform.

Static Sites:

Eine Static Site besteht aus fertigen HTML-, CSS- und JavaScript-Dateien, die direkt an den Browser ausgeliefert werden. Es gibt keinen Server-seitigen Code, der bei jedem Request ausgeführt wird. Die Seiten werden einmal beim Build generiert und dann an alle Nutzer gleich ausgeliefert.

Das ist perfekt für Websites, deren Inhalt sich nicht bei jedem Nutzer unterscheidet. Ein Portfolio sieht für dich genauso aus wie für mich. Ein Blog-Artikel ist für alle Leser identisch. Eine Marketing-Website zeigt jedem Besucher dieselben Informationen.

Typische Use Cases: Portfolio-Websites, Blogs, Dokumentationen, Marketing-Sites, Landing Pages, Unternehmens-Websites ohne Login.

Frameworks die Static Sites bauen: Astro, Next.js (mit Static Export), Gatsby, 11ty, Hugo, Jekyll. Diese Frameworks nehmen deine Templates und Inhalte und generieren beim Build fertige HTML-Dateien.

Die Vorteile: Geschwindigkeit – es gibt keine Datenbank-Abfragen oder Server-Berechnungen, nur direkte File-Auslieferung. Sicherheit – ohne Server-Code gibt es kaum Angriffsfläche für Hacker. Kosten – Static Hosting ist oft kostenlos oder sehr günstig. Skalierung – CDNs können problemlos Millionen Requests ausliefern.

Dynamic Sites:

Eine Dynamic Site generiert HTML bei jedem Request auf dem Server. Wenn du eine Seite aufrufst, wird sie in diesem Moment erstellt – mit aktuellen Daten aus der Datenbank, angepasst an deinen Login-Status, deine Präferenzen, deine Region.

Das brauchst du, wenn jeder Nutzer unterschiedliche Inhalte sehen soll. Ein Social Network zeigt dir deinen eigenen Feed. Ein E-Commerce-Shop zeigt deinen Warenkorb. Eine SaaS-App zeigt deine eigenen Daten und Settings.

Typische Use Cases: Social Networks, E-Commerce-Shops, SaaS-Anwendungen, Dashboards, User-Portale, Plattformen mit Login und personalisierten Inhalten.

Frameworks für Dynamic Sites: Next.js (mit Server-Side Rendering), Remix, SvelteKit, Rails, Django, Laravel, Node.js mit Express. Diese Frameworks laufen auf einem Server und generieren HTML on-the-fly.

Die Vorteile: Du kannst dynamische Inhalte anzeigen, auf User-Input reagieren, Datenbanken abfragen, Authentifizierung durchführen und jedem Nutzer eine personalisierte Experience bieten. Das ist die richtige Wahl, wenn deine App mehr ist als nur eine Informations-Website.

Hybrid-Ansatz (das Beste aus beiden Welten):

Moderne Frameworks erlauben dir, Static und Dynamic zu mischen. Du kannst eine hauptsächlich statische Website haben, die an bestimmten Stellen dynamische Features nutzt. Das Beste aus beiden Welten!

Wie funktioniert das? Deine Haupt-Seiten werden statisch generiert (schnell, günstig, sicher), aber du nutzt Serverless Functions für Dinge, die Interaktion brauchen. Ein Blog ist statisch, aber die Newsletter-Anmeldung ruft eine Function auf. Eine Marketing-Site ist statisch, aber das Kontaktformular sendet über eine Function.

Frameworks die Hybrid unterstützen: Astro (Static + Server Endpoints), Next.js (SSG + SSR + ISR), SvelteKit (Static + Server). Du entscheidest pro Seite oder Feature, was statisch und was dynamisch sein soll.

Ein praktisches Beispiel: Dein Portfolio ist komplett statisch – alle Seiten werden beim Build generiert. Aber du hast ein Kontaktformular, das eine Serverless Function aufruft, die eine E-Mail versendet. Die Function läuft nur, wenn jemand das Formular abschickt. Du zahlst nicht für einen 24/7 laufenden Server, sondern nur für die paar Millisekunden Ausführungszeit.

Die richtige Plattform wählen: Netlify vs. Vercel im Vergleich

Es gibt dutzende Deployment-Plattformen, aber für Einsteiger sind Netlify und Vercel die besten Optionen. Beide sind:

Aber welche solltest du wählen?

Netlify – Der Allrounder für Static Sites

Netlify ist die Plattform, die ich jedem Einsteiger zuerst empfehle. Die UI ist intuitiv, die Dokumentation ist hervorragend, und der Free Tier ist großzügig genug für die meisten persönlichen Projekte und Portfolios.

Stärken:

Die Einstiegshürde ist extrem niedrig. Du kannst buchstäblich einen Ordner mit HTML-Dateien per Drag & Drop in den Browser ziehen und hast 10 Sekunden später eine live Website. Kein Git nötig (aber empfohlen).

Der Free Tier ist großzügig: 100 GB Bandwidth pro Monat (das reicht für tausende Besucher), 300 Build-Minuten (genug für dutzende Deployments täglich) und unbegrenzte Websites. Du kannst so viele Projekte hosten wie du willst.

Form Handling ist kostenlos eingebaut. Du fügst ein netlify-Attribut zu deinem HTML-Formular hinzu, und Netlify fängt die Submissions ab und schickt sie dir per E-Mail. Keine Backend-Logik nötig! Das ist perfekt für Kontaktformulare, Newsletter-Anmeldungen, etc.

Identity & Authentication ist ebenfalls integriert. Du kannst User-Login zu deiner Static Site hinzufügen, ohne einen eigenen Auth-Server aufzusetzen. Das ist ein Feature, das Vercel nicht bietet.

Split Testing (A/B-Tests) laufen direkt auf der Plattform. Du kannst zwei Versionen deiner Website deployen und den Traffic automatisch aufteilen, um zu sehen, welche Version besser performt.

Netlify Dev ist ein CLI-Tool, das deine Serverless Functions lokal emuliert. Du kannst deine gesamte Netlify-Umgebung auf deinem Laptop nachbauen und testen, bevor du deployest.

Free Tier Limits:

Wann Netlify wählen?

Wähle Netlify wenn du einen Allrounder für Static Sites suchst. Perfekt für Portfolios, Blogs, Marketing-Websites, Landing Pages. Besonders gut, wenn du Formulare brauchst (Netlify Forms ist ein Killer-Feature) oder A/B-Testing machen willst.

Auch ideal, wenn du noch nicht so viel Erfahrung mit Deployment hast – die Plattform verzeiht Anfängerfehler und die Dokumentation ist exzellent.

Vercel – Optimiert für Next.js und React

Vercel ist die Plattform hinter Next.js und damit die erste Wahl, wenn du mit dem React-Ökosystem arbeitest. Die Integration ist nahtlos, die Performance ist exzellent, und die Developer Experience ist erstklassig.

Stärken:

Die Next.js-Integration ist unschlagbar, weil Vercel das Framework selbst entwickelt. Alle neuen Next.js-Features werden zuerst auf Vercel optimiert. ISR (Incremental Static Regeneration), Edge Runtime, Server Components – alles funktioniert out-of-the-box ohne Konfiguration.

Sehr schnelle Builds sind ein Markenzeichen von Vercel. Die Build-Infrastruktur ist aggressiv optimiert, und du merkst den Unterschied: Was auf Netlify 3 Minuten braucht, ist auf Vercel oft in unter 1 Minute fertig. Das macht einen wirklich großen Unterschied im Development-Flow.

Edge Functions mit globalem Deployment laufen auf Vercels globalem Edge Network. Deine Serverless Functions werden automatisch auf Servern weltweit deployed und laufen dort, wo deine Nutzer sind. Das bedeutet minimale Latenz, egal wo jemand deine Site aufruft.

Serverless Functions haben bessere Cold-Start-Performance als bei der Konkurrenz. Vercel nutzt eine optimierte V8-Runtime, die Functions schneller startet. Für APIs und Backends macht das einen spürbaren Unterschied.

Analytics sind kostenlos inklusive, inklusive Core Web Vitals-Tracking. Du siehst sofort, wie deine Website performt, ohne externe Tools einbinden zu müssen. Das ist ein Feature, für das du bei Netlify $9/Monat zahlst.

Die Vercel CLI ist hervorragend. Deployment, Logs, Environment Variables, alles über das Terminal steuerbar. Die DX (Developer Experience) ist hier wirklich durchdacht.

Free Tier Limits:

Wann Vercel wählen?

Wähle Vercel wenn du Next.js, React oder ein modernes JS-Framework nutzt. Die Integration ist so gut, dass es keinen Grund gibt, woanders zu deployen. Auch perfekt, wenn du viele Builds machst (6000 Minuten vs. 300 bei Netlify!).

Vercel ist auch die bessere Wahl für Projekte mit Serverless Functions und APIs, weil die Performance und Cold-Start-Zeiten besser sind. Wenn du Analytics brauchst, ist der kostenlose Vercel-Analytics-Plan ein Bonus.

Netlify vs. Vercel: Der direkte Vergleich

FeatureNetlifyVercel
Free Bandwidth100 GB/Monat100 GB/Monat
Build Minutes300 Credits (~20 Deploys)*100 Hours/Monat (6000 Min)
Serverless Functions125k Invocations/Monat1M Invocations/Monat
Best für FrameworkAstro, 11ty, JekyllNext.js, React
Form Handling✅ Ja (100 Submissions/Monat)❌ Nicht verfügbar
A/B Testing✅ Ja (Split Testing)❌ Nein
Analytics7 Tage Retention ($9/Monat)Begrenzt (10k Events/Monat)
Edge Functions✅ Ja (Deno)✅ Ja (V8)
CLI QualityGutExzellent
Learning CurveSehr einfachEinfach

*Wichtig zu Netlify’s neuem Pricing (2025): Seit September 2025 nutzt Netlify ein Credit-basiertes System statt Build Minutes. Neue Free-Accounts erhalten 300 Credits pro Monat. Jeder Production Deploy kostet 15 Credits, was etwa 20 Deploys pro Monat ermöglicht. Form Submissions kosten 1 Credit pro Submission.

Meine Empfehlung: Wann welche Plattform?

Die ehrliche Antwort: Beide sind großartig, und du kannst mit keiner der beiden etwas falsch machen. Die Wahl hängt von deinem Projekt und deinen Prioritäten ab.

Wähle Netlify wenn:

Wähle Vercel wenn:

Alternativen (kurz erwähnt):

Cloudflare Pages ist eine starke Alternative mit unbegrenzter Bandwidth im Free Tier und sehr guter Performance. Die Plattform ist noch relativ neu, aber das Edge Network von Cloudflare ist unschlagbar. Gut für Static Sites, aber weniger Features als Netlify/Vercel.

GitHub Pages ist komplett kostenlos und perfekt für einfache Static Sites, besonders Open-Source-Projekte und Dokumentation. Einschränkung: Nur Static HTML/CSS/JS, kein Build-Prozess auf dem Server (du musst lokal builden). Keine Serverless Functions.

Railway und Render sind besser für Full-Stack-Apps mit Backend, Datenbanken und Docker. Wenn du mehr brauchst als nur Static Hosting, sind diese Plattformen einen Blick wert. Der Free Tier ist aber begrenzter als bei Netlify/Vercel.

Schritt-für-Schritt: Deine erste Website auf Netlify deployen

Genug Theorie – lass uns deine Website live bringen! Ich zeige dir jetzt Schritt für Schritt, wie du dein Projekt auf Netlify deployest.

Voraussetzungen

Bevor wir loslegen, stelle sicher, dass du Folgendes hast:

Alles klar? Dann geht’s los!

Schritt 1: Projekt zu Git hinzufügen

Falls dein Projekt noch kein Git-Repository ist, machen wir das jetzt. Öffne dein Terminal im Projektordner und führe folgende Befehle aus:

# Initialisiere Git-Repository (falls noch nicht geschehen)
git init

# .gitignore erstellen (wichtig!)
echo "node_modules/\n.env\ndist/\nbuild/" > .gitignore

# Alle Files hinzufügen
git add .

# Ersten Commit erstellen
git commit -m "Initial commit"

Warum .gitignore wichtig ist:

Die .gitignore-Datei sagt Git, welche Files nicht ins Repository sollen. Das ist kritisch wichtig:

node_modules/ ist oft hunderte MB groß und wird auf dem Server neu installiert. Niemand will 50.000 Dependency-Files in Git haben. Das würde dein Repository riesig und langsam machen.

.env enthält Secrets wie API Keys und Passwörter. Wenn du diese Datei commitest, sind deine Secrets öffentlich im Internet. Ein Albtraum für die Security! Immer in .gitignore packen.

dist/ und build/ sind die kompilierten Output-Ordner. Diese werden beim Deployment neu erstellt, du brauchst sie nicht in Git. Das spart Speicherplatz und verhindert Merge-Konflikte.

Schritt 2: Repository zu GitHub pushen

Jetzt bringen wir deinen Code zu GitHub, damit Netlify ihn deployen kann.

Gehe zu github.com und erstelle ein neues Repository:

  1. Klicke oben rechts auf das + Symbol und wähle “New repository”
  2. Gib einen Repository-Namen ein, z.B. mein-portfolio oder meine-website
  3. Wähle Public oder Private:
    • Public = Jeder kann deinen Code auf GitHub sehen (gut für Open-Source-Projekte)
    • Private = Nur du siehst den Code (perfekt für persönliche Projekte oder Client-Arbeit)
    • Wichtig: Beides funktioniert mit Netlify und Vercel! Auch mit privaten Repos wird deine Website öffentlich deployed – nur der Source-Code bleibt privat
  4. Wichtig: Wähle KEINE README, .gitignore oder License aus (das haben wir schon lokal)
  5. Klicke auf “Create repository”

GitHub zeigt dir jetzt eine Seite mit Setup-Befehlen. Wir brauchen den Abschnitt “push an existing repository”. Kopiere die Befehle oder nutze diese:

# Remote hinzufügen (ersetze USERNAME und REPO-NAME)
git remote add origin https://github.com/USERNAME/REPO-NAME.git

# Zum Main-Branch wechseln (falls noch auf master)
git branch -M main

# Code pushen
git push -u origin main

💡 Muss mein Repository öffentlich sein?

Nein! Ein häufiges Missverständnis bei Anfängern: Dein GitHub-Repository kann privat bleiben, auch wenn deine Website öffentlich im Internet erreichbar ist.

Was passiert:

  • Deine Website → öffentlich sichtbar für alle (das ist ja der Sinn eines Deployments)
  • Dein Source-Code → privat, nur für dich und eingeladene Collaborators sichtbar (wenn du Private wählst)

Netlify und Vercel bekommen die Permission, auf dein privates Repository zuzugreifen (du gibst ihnen das beim Connect), aber dein Code bleibt trotzdem privat. Die Plattformen bauen deine Website und veröffentlichen nur die kompilierten HTML/CSS/JS-Files – nicht deinen Source-Code.

Wann welche Option?

  • Public: Open-Source-Projekte, Portfolio-Code zum Zeigen, Learning in Public
  • Private: Persönliche Projekte, Client-Arbeit, wenn du deinen Code nicht teilen willst

Schritt 3: Netlify-Account erstellen

Jetzt brauchst du einen Netlify-Account. Der Prozess dauert etwa 30 Sekunden.

So geht’s:

  1. Gehe zu netlify.com
  2. Klicke oben rechts auf “Sign up”
  3. Wähle “Sign up with GitHub” (das ist die einfachste Option und verbindet sofort deine Repositories)
  4. GitHub fragt dich nach Permissions – klicke auf “Authorize Netlify”
  5. Netlify begrüßt dich mit einem Onboarding – du kannst das überspringen oder durchklicken

Warum mit GitHub anmelden? Das verbindet automatisch deine Repositories mit Netlify. Du könntest auch mit E-Mail anmelden, aber dann musst du später manuell die Git-Provider-Connection herstellen. Mit GitHub geht’s in einem Schritt.

Schritt 4: Site deployen

Jetzt kommt der spannende Teil – wir verbinden dein GitHub-Repository mit Netlify.

Im Netlify Dashboard:

  1. Klicke auf “Add new site” (grüner Button oben rechts)
  2. Wähle “Import an existing project”
  3. Netlify fragt: “Connect to Git provider” – wähle GitHub
  4. Du siehst jetzt eine Liste deiner GitHub-Repositories
  5. Finde dein Repository und klicke darauf

Wenn dein Repository nicht in der Liste ist:

Das passiert manchmal, wenn Netlify nicht auf alle deine Repositories zugreifen darf. Kein Problem:

  1. Scrolle runter und klicke auf “Configure the Netlify app on GitHub”
  2. GitHub öffnet sich in einem neuen Tab
  3. Unter “Repository access” wähle entweder:
    • “All repositories” (bequem, aber Netlify sieht alle deine Repos)
    • “Only select repositories” (wähle nur die, die du deployen willst)
  4. Klicke “Save” und gehe zurück zu Netlify
  5. Dein Repository sollte jetzt in der Liste sein

Schritt 5: Build-Settings konfigurieren

Nachdem du dein Repository ausgewählt hast, zeigt Netlify dir die Build Settings. Das ist der Moment, wo du Netlify sagst, wie dein Projekt gebaut werden soll.

Die gute Nachricht: Netlify erkennt die meisten Frameworks automatisch. Wenn du Astro, Next.js, Vite oder Create React App nutzt, sind die Settings oft schon vorausgefüllt. Trotzdem solltest du checken, ob alles stimmt.

Typische Build-Settings für verschiedene Frameworks:

# Astro
Build command: npm run build
Publish directory: dist

# Next.js
Build command: npm run build
Publish directory: .next

# Vite (React/Vue)
Build command: npm run build
Publish directory: dist

# Create React App
Build command: npm run build
Publish directory: build

Was bedeuten diese Settings?

Build command ist der Befehl, den Netlify ausführt, um dein Projekt zu bauen. Das steht normalerweise in deiner package.json unter scripts. Fast immer ist das npm run build.

Publish directory ist der Ordner, wo die fertig gebauten Files liegen. Nach dem Build-Prozess sucht Netlify in diesem Ordner nach deinen HTML/CSS/JS-Files und deployed sie. Das ist entweder dist, build, .next oder ein anderer Output-Ordner.

Branch to deploy ist standardmäßig main (oder master bei älteren Repos). Das bedeutet: Netlify deployed immer, wenn du auf diesen Branch pushst.

Environment Variables hinzufügen (falls nötig):

Wenn dein Projekt Environment Variables braucht (API Keys, Datenbank-URLs, etc.), kannst du sie hier hinzufügen. Klicke auf “Show advanced” und dann “New variable”.

Zum Beispiel:

Wichtig: Füge hier KEINE Secrets aus deiner lokalen .env-Datei ein! Die brauchst du nur, wenn dein Build-Prozess sie wirklich braucht. Mehr dazu später im Kapitel über Environment Variables.

Schritt 6: Deployment starten

Alles konfiguriert? Perfekt! Jetzt kommt der Moment der Wahrheit.

Klicke auf den großen “Deploy” Button (bei neueren Netlify-Versionen heißt er manchmal “Deploy site” oder nur “Deploy”).

Netlify startet jetzt den Build-Prozess. Du siehst eine Build-Log-Ansicht, wo in Echtzeit angezeigt wird, was gerade passiert:

# Das siehst du ungefähr:
Initializing repository...
Building project...
Deploying site from build...
Cleanup Caching artifacts
Post-processing Site is live ✨

Das dauert in der Regel 2-5 Minuten, abhängig von deinem Projekt. Ein einfaches Portfolio ist in unter 1 Minute fertig, ein großes Next.js-Projekt kann 3-5 Minuten brauchen.

Verfolge den Build-Log! Hier siehst du, ob alles funktioniert oder ob Fehler auftreten. Die Logs sind sehr hilfreich für Debugging.

Bei Fehlern:

Wenn der Build fehlschlägt, keine Panik! Das ist völlig normal beim ersten Deployment. Häufige Probleme:

Lies den Fehler im Log genau, behebe das Problem lokal, committe die Änderung und pushe erneut zu GitHub. Netlify startet automatisch einen neuen Build!

Erfolg! Deine Site ist live

Nach 2-5 Minuten solltest du eine grüne Success-Message sehen: “Site is live” 🎉

Herzlichen Glückwunsch! Du hast gerade deine erste Website deployed. Deine Website ist jetzt unter einer URL erreichbar:

https://random-name-12345.netlify.app

Netlify generiert automatisch einen zufälligen Namen für deine Site. Das ist okay für Testing, aber du willst wahrscheinlich was Schöneres.

Was du jetzt tun kannst:

1. Site-Namen ändern:

Der zufällige Name random-name-12345.netlify.app ist nicht besonders einprägsam. Du kannst ihn kostenlos ändern:

2. Custom Domain hinzufügen:

Die .netlify.app Domain ist okay, aber für Production willst du wahrscheinlich deine eigene Domain wie deine-website.de. Das zeige ich dir später im Kapitel “Custom Domain Setup”.

3. Deploy Previews aktivieren:

Standardmäßig sind Deploy Previews schon aktiv! Das bedeutet: Jeder Pull Request auf GitHub bekommt automatisch eine Preview-URL zum Testen. Kein Setup nötig, funktioniert einfach.

4. Automatisches Deployment testen:

Ändere jetzt irgendwas an deiner Website lokal, committe und pushe zu GitHub:

# Ändere z.B. einen Text in deiner index.html
git add .
git commit -m "Update homepage text"
git push

Gehe zu Netlify und schau zu – ein neuer Build startet automatisch! Das ist Continuous Deployment in Action. Jeder Git Push = automatischer Deploy.

Schritt-für-Schritt: Deployment mit Vercel

Vercel funktioniert ähnlich wie Netlify, hat aber ein paar Unterschiede. Hier ist der vollständige Walkthrough.

Voraussetzungen

Die Voraussetzungen sind die gleichen wie bei Netlify:

Falls du die Netlify-Anleitung übersprungen hast und direkt mit Vercel startest, gehe zurück zu “Schritt 1: Projekt zu Git hinzufügen” im Netlify-Abschnitt und folge den Git-Setup-Schritten.

Schritt 1: Vercel-Account erstellen

Der Sign-up-Prozess bei Vercel ist super schnell und unkompliziert.

So geht’s:

  1. Gehe zu vercel.com
  2. Klicke auf “Sign Up” (oben rechts)
  3. Wähle “Continue with GitHub” – das ist die einfachste und empfohlene Option
  4. GitHub fragt nach Permissions – klicke auf “Authorize Vercel”
  5. Vercel fragt nach deinem Namen – gib ihn ein und klicke “Continue”
  6. Wähle den Hobby Plan (das ist der kostenlose Plan für persönliche Projekte)

Das war’s! Vercel leitet dich jetzt zum Dashboard weiter. Die ganze Registrierung dauert keine 30 Sekunden.

Schritt 2: Projekt importieren

Im Vercel Dashboard siehst du jetzt eine Übersicht deiner Projekte (wahrscheinlich noch leer). Zeit, dein erstes Projekt zu deployen!

So importierst du dein Repository:

  1. Klicke auf “Add New…” (oben rechts) und wähle “Project”
  2. Vercel zeigt dir jetzt deine GitHub-Repositories – wähle das Repository aus, das du deployen willst (funktioniert auch mit privaten Repositories!)
  3. Falls dein Repository nicht in der Liste ist, klicke auf “Adjust GitHub App Permissions” und gewähre Vercel Zugriff
  4. Klicke auf “Import” neben dem Repository-Namen

Das war’s schon! Vercel ist hier etwas schneller als Netlify – weniger Klicks, direkter zum Ziel.

Schritt 3: Build-Settings konfigurieren

Vercel erkennt die meisten Frameworks automatisch! 🎉

Nachdem du auf “Import” geklickt hast, analysiert Vercel dein Repository und erkennt automatisch, welches Framework du nutzt. Die Build-Settings sind meistens schon perfekt konfiguriert.

Framework Presets:

Vercel hat eingebaute Presets für alle gängigen Frameworks. Wenn Vercel dein Framework erkennt, siehst du oben “Framework Preset: Next.js” (oder Astro, Vite, etc.). Das bedeutet: Null Konfiguration nötig!

Was automatisch erkannt wird:

Falls dein Framework nicht erkannt wird:

Kein Problem, du kannst die Settings manuell setzen. Klicke auf “Override” bei den Build Settings und gib an:

Schritt 4: Deployment starten

Alles bereit? Dann klicke auf den großen blauen “Deploy” Button!

Vercel startet jetzt den Build-Prozess. Der läuft in der Regel deutlich schneller als bei Netlify – dank aggressiver Optimierungen und besserer Build-Infrastruktur.

Was jetzt passiert:

# Vercel Build-Prozess
Cloning repository...
Analyzing dependencies...
Installing dependencies (npm install)...
Building (npm run build)...
Uploading to Edge Network...
Propagating to 50+ regions worldwide...

Durchschnittliche Build-Zeiten:

Das ist oft 2-3x schneller als auf Netlify. Die Geschwindigkeit ist einer der großen Vorteile von Vercel.

Bei Erfolg: Confetti! 🎉

Wenn der Build erfolgreich ist, zeigt Vercel eine Confetti-Animation und die Message “Congratulations!”. Deine Website ist live!

Du bekommst sofort eine URL:

https://dein-projekt-name.vercel.app

Vercel generiert den Namen automatisch aus deinem Repository-Namen. Du kannst ihn später in den Project Settings ändern.

Vercel CLI – Deployment direkt aus dem Terminal

Ein großer Vorteil von Vercel: Die CLI ist exzellent.

# Vercel CLI global installieren
npm i -g vercel

# In Projektordner wechseln
cd mein-projekt

# Deployment starten (erstellt Preview-Deployment)
vercel

# Production Deployment (für deine Main-Domain)
vercel --prod

Wie funktioniert die CLI?

Wenn du vercel zum ersten Mal in einem Projekt ausführst, passiert Folgendes:

  1. Die CLI fragt dich: “Set up and deploy?” → Drücke Enter (Yes)
  2. “Which scope?” → Wähle deinen Account
  3. “Link to existing project?” → Wenn du das Projekt schon über das Web-UI erstellt hast, wähle Yes und wähle das Projekt aus. Sonst No.
  4. “What’s your project’s name?” → Gib einen Namen ein oder drücke Enter für den Ordnernamen
  5. “In which directory is your code located?” → . (aktueller Ordner)
  6. Vercel erkennt dein Framework automatisch und fragt: “Want to override the settings?” → Normalerweise No

Danach startet der Build, und nach 30-60 Sekunden bekommst du eine Preview-URL:

✅ Preview: https://mein-projekt-abc123.vercel.app

Das ist ein Preview-Deployment – perfekt zum Testen. Wenn alles gut aussieht, deploye zu Production:

vercel --prod

Jetzt ist deine Website live unter der Production-URL!

Warum die CLI so praktisch ist:

Custom Domain Setup – Deine eigene Adresse

Deine Site läuft jetzt unter einer Subdomain von Netlify oder Vercel. Das ist okay für Testing, aber für Production willst du deine eigene Domain.

Schritt 1: Domain kaufen

Wo Domain kaufen?

Anbieter.de Domain/Jahr.com Domain/JahrEmpfehlung
INWX 🇩🇪4,65€~10€✅ Günstigster DE-Anbieter
Porkbun3,80€~10€✅ Günstigster International
checkdomain 🇩🇪ab 0,84€/Monat~11€✅ Budget-Option, deutscher Support
Namecheap~12€10€ (dann 14€)⚠️ OK, Verlängerung teurer
IONOS 🇩🇪1€ (dann 20€)1€ (dann 15€)❌ Lock-in Pricing

🇩🇪 = Deutscher Anbieter mit deutschem Support und DSGVO-Compliance

Meine Empfehlung: INWX für deutsche Nutzer, Porkbun für internationale.

Warum diese Empfehlung?

INWX ist der beste deutsche Registrar: Günstig (4,65€ für .de), transparent, keine versteckten Kosten, deutscher Support und DSGVO-konform. Über 300.000 Domains verwaltet, sehr zuverlässig. Perfekt, wenn du deutschen Support und faire Preise willst.

Porkbun ist international am günstigsten: 3,80€ für .de, 10€ für .com. Modernes Interface, kostenlose Domain-Privacy (WHOIS-Schutz), keine Upsells. Der Geheimtipp unter Entwicklern. Support ist auf Englisch, aber sehr gut.

checkdomain ist die Budget-Option mit deutschem Support: Promotional-Preise ab 0,84€/Monat, über 950 TLDs verfügbar, Teil der Dogado-Gruppe. Gut für Einsteiger, die deutschen Support brauchen und sparen wollen.

Namecheap ist etabliert und solide: Fair für .com Domains (10€), aber die Verlängerung steigt auf 14€. Kostenlose Domain-Privacy inklusive. Gut, wenn du einen bekannten Namen willst, aber schau dir die Verlängerungspreise an.

Vermeide IONOS: Lockt mit 1€ im ersten Jahr, dann explodieren die Preise auf 20€/Jahr. Lock-in-Mechanismen und schwer zu kündigen. Klassisches Bait-Pricing.

Wichtig: Achte immer auf die Verlängerungspreise! Viele Anbieter locken mit günstigen Erstjahrespreisen. Die echten Kosten zeigen sich erst ab dem zweiten Jahr.

So kaufst du eine Domain (der Prozess ist überall ähnlich):

  1. Gehe zur Website deines gewählten Registrars (z.B. inwx.de oder porkbun.com)
  2. Gib deinen Wunsch-Domain-Namen in die Suche ein
  3. Checke, ob die Domain verfügbar ist – wenn nicht, probiere Alternativen
  4. Wähle die .de oder .com Endung (für Deutschland empfohlen: .de)
  5. Klicke “In den Warenkorb” bzw. “Add to cart” und gehe zur Kasse
  6. Wichtig: Aktiviere Domain-Privacy/WHOIS-Schutz (bei INWX, Porkbun kostenlos!)
  7. Erstelle einen Account oder logge dich ein
  8. Bezahle mit Kreditkarte, PayPal oder SEPA (je nach Anbieter)
  9. Fertig! Du besitzt jetzt deine Domain

Die Domain ist jetzt in deinem Account, aber sie zeigt noch nirgendwo hin. Das ändern wir im nächsten Schritt.

Schritt 2: Domain mit Netlify verbinden

Jetzt verbinden wir deine gekaufte Domain mit deiner Netlify-Site.

Im Netlify Dashboard:

  1. Wähle deine Site aus der Übersicht
  2. Gehe zu Site settings (linke Sidebar)
  3. Klicke auf Domain management
  4. Unter “Custom domains” klicke auf “Add custom domain”
  5. Gib deine Domain ein (z.B. meine-website.de)
  6. Netlify prüft, ob die Domain schon verwendet wird
  7. Klicke “Verify” oder “Add domain”

Netlify fragt jetzt: “Do you own this domain?”

Wenn du die Domain gerade gekauft hast, klicke “Yes, add domain”. Netlify weiß natürlich nicht automatisch, dass die Domain dir gehört – das verifizieren wir im nächsten Schritt über DNS.

Du siehst jetzt deine Domain in der Liste, aber mit einem orangenen Badge: “Awaiting External DNS”

Das ist normal! Es bedeutet: Netlify wartet darauf, dass du die DNS-Einträge konfigurierst. Das machen wir jetzt.

Schritt 3: DNS-Einträge konfigurieren

Das ist der technischste Teil – aber keine Sorge, ich führe dich durch!

Was ist DNS?

DNS (Domain Name System) ist wie das Telefonbuch des Internets. Wenn jemand meine-website.de in den Browser tippt, fragt der Browser das DNS: “Wo finde ich diese Website?” Das DNS antwortet mit der IP-Adresse des Servers, wo die Website liegt.

Stell dir vor, du ziehst um. Deine Freunde kennen deine alte Adresse (deine Domain), aber du wohnst jetzt woanders (neuer Server). Du musst also im Telefonbuch (DNS) deine neue Adresse eintragen, damit deine Freunde dich finden.

Genau das machen wir jetzt: Wir sagen dem DNS, dass meine-website.de zu deiner Netlify-Site zeigen soll.

Welche DNS-Einträge brauchst du?

Für Netlify:

# Apex Domain (meine-website.de)
A Record: 75.2.60.5

# www Subdomain
CNAME Record: www → deine-site.netlify.app

# Optional: Netlify DNS Nameserver (empfohlen)
NS Records: dns1.p01.nsone.net, dns2.p01.nsone.net, ...

Was bedeuten diese Einträge?

A Record (Address Record) zeigt deine Haupt-Domain (apex domain, ohne www) auf eine IP-Adresse. meine-website.de → 75.2.60.5 (Netlify’s Load Balancer).

CNAME Record (Canonical Name) ist ein Alias. www.meine-website.de zeigt auf deine-site.netlify.app. Das ist flexibler als eine feste IP, weil Netlify die dahinterliegende Infrastruktur ändern kann ohne dass du was anpassen musst.

NS Records (Nameserver) geben die Kontrolle komplett an Netlify ab. Das ist optional, aber empfohlen, weil Netlify dann alles automatisch managen kann.

So konfigurierst du DNS bei Namecheap:

  1. Logge dich bei Namecheap ein
  2. Gehe zu Domain List und klicke auf “Manage” bei deiner Domain
  3. Scrolle zu “Advanced DNS” und klicke darauf
  4. Unter “Host Records” klicke “Add New Record”

Füge folgende Records hinzu:

A Record:

CNAME Record:

Wichtig: Entferne eventuell vorhandene alte Records für @ und www, bevor du die neuen hinzufügst. Sonst gibt’s Konflikte!

Bei Porkbun funktioniert es fast identisch – die UI ist nur etwas anders beschriftet. Suche nach “DNS Records” im Domain-Management.

Schritt 4: SSL-Zertifikat aktivieren (automatisch!)

Was ist SSL/TLS?

SSL (bzw. das modernere TLS) verschlüsselt die Verbindung zwischen Browser und Server. Wenn deine Website HTTPS nutzt (statt HTTP), können Dritte nicht mitlesen, was zwischen Nutzer und Website übertragen wird. Das ist heute Pflicht – Websites ohne HTTPS werden von Browsern als “nicht sicher” markiert.

Die gute Nachricht: Netlify und Vercel aktivieren SSL automatisch nach DNS-Propagation.

Du musst nichts machen. Sobald die DNS-Einträge aktiv sind und Netlify deine Domain erreichen kann, passiert Folgendes automatisch:

  1. Netlify prüft die DNS-Einträge – Ist die Domain korrekt konfiguriert und zeigt sie auf Netlify?
  2. Let’s Encrypt Zertifikat wird generiert – Netlify nutzt Let’s Encrypt (kostenlos, vertrauenswürdig, Standard in der Industrie) um ein SSL-Zertifikat für deine Domain zu erstellen
  3. HTTPS wird erzwungen – Netlify richtet automatisch einen Redirect ein: Alle HTTP-Requests (http://meine-website.de) werden zu HTTPS (https://meine-website.de) umgeleitet
  4. Automatische Erneuerung – Let’s Encrypt-Zertifikate sind 90 Tage gültig, aber Netlify erneuert sie automatisch. Du musst nie daran denken.

Du siehst in Netlify: Unter Domain Management wechselt das Badge von “Awaiting External DNS” zu “Netlify DNS is set up” (oder ähnlich), und ein grünes Badge “HTTPS” erscheint.

Das dauert normalerweise 10-30 Minuten nach der DNS-Konfiguration.

Schritt 5: Propagation abwarten

Was ist DNS Propagation?

Wenn du DNS-Einträge änderst, wird diese Änderung nicht sofort weltweit sichtbar. DNS-Server auf der ganzen Welt cachen (speichern) die alten Einträge für eine Weile. Es dauert Zeit, bis alle Server die neuen Einträge abgerufen haben. Dieser Prozess heißt “DNS Propagation”.

Wie lange dauert das?

In der Praxis siehst du die Änderung oft schon nach 1-2 Stunden. Bei Namecheap und Porkbun geht’s tendenziell schneller als bei älteren Anbietern.

Wie prüfst du den Status?

Option 1: Terminal-Befehle (für Fortgeschrittene)

# DNS Lookup (Mac/Linux)
dig meine-website.de

# DNS Lookup (Windows)
nslookup meine-website.de

Wenn du in der Ausgabe die Netlify-IP (75.2.60.5) siehst, ist die Propagation durch!

Option 2: Online-Tool (einfacher)

Gehe zu dnschecker.org, gib deine Domain ein und wähle “A” als Record-Type. Das Tool zeigt dir, wie verschiedene DNS-Server weltweit deine Domain sehen. Wenn die meisten die richtige IP zeigen, bist du ready.

Was während der Propagation passiert:

Manche Nutzer sehen schon deine neue Website, andere noch die alte (oder eine Fehlermeldung, wenn vorher nichts da war). Das ist normal und löst sich von selbst, wenn die Propagation abgeschlossen ist. Sei einfach geduldig – gute Dinge brauchen Zeit!

Domain mit Vercel verbinden

Der Prozess bei Vercel ist fast identisch zu Netlify, aber mit ein paar kleinen Unterschieden.

Im Vercel Dashboard:

  1. Wähle dein Projekt aus
  2. Gehe zu Settings (oben)
  3. Klicke auf Domains in der linken Sidebar
  4. Gib deine Domain ein (z.B. meine-website.de) und klicke “Add”
  5. Vercel zeigt dir jetzt, welche DNS-Einträge du brauchst

DNS-Einträge für Vercel:

Vercel empfiehlt einen CNAME Record für die Apex Domain (nicht A Record wie Netlify). Das funktioniert aber nicht bei allen Domain-Anbietern. Falls CNAME nicht geht, nutze:

# Option 1: CNAME (empfohlen)
Type: CNAME
Name: @ (oder leer lassen)
Value: cname.vercel-dns.com

# Option 2: A Record (falls CNAME nicht funktioniert)
Type: A
Name: @
Value: 76.76.21.21

Für die www Subdomain:

Type: CNAME
Name: www
Value: cname.vercel-dns.com

Gehe zu deinem Domain-Anbieter und füge diese Records hinzu (genau wie bei Netlify erklärt). Vercel wartet dann auf die DNS-Propagation und aktiviert automatisch SSL.

Vercel ist oft etwas schneller bei der SSL-Aktivierung als Netlify – manchmal ist das Zertifikat schon nach 5-10 Minuten da.

Environment Variables & Secrets richtig handhaben

Ein kritisches Thema, das viele Anfänger falsch machen: API Keys und Secrets.

Was sind Environment Variables?

Environment Variables sind Konfigurationswerte, die außerhalb deines Codes gespeichert werden.

Stell dir vor, du hast einen API Key für einen Payment-Provider wie Stripe. Du könntest ihn direkt in deinen Code schreiben:

// ❌ NIEMALS so machen!
const stripeKey = "sk_live_1234567890abcdef";

Aber was passiert, wenn du den Code auf GitHub pushst? Der Key ist öffentlich! Jeder kann ihn sehen und missbrauchen. Du könntest plötzlich mit riesigen Rechnungen dastehen, weil jemand deinen Key für Fraud genutzt hat.

Die Lösung: Environment Variables. Du speicherst sensible Werte außerhalb des Codes:

// ✅ Richtig!
const stripeKey = process.env.STRIPE_SECRET_KEY;

Der Wert kommt aus einer .env-Datei lokal oder aus den Platform-Settings auf Netlify/Vercel.

Typische Beispiele für Environment Variables:

DATABASE_URL=postgresql://user:pass@host:5432/db
API_KEY=sk_live_abcdefg123456789
STRIPE_SECRET_KEY=sk_live_...
SENDGRID_API_KEY=SG.xxx
NEXT_PUBLIC_API_ENDPOINT=https://api.example.com

Wo gehören Environment Variables hin?

Variable TypeLokal (.env)Git (.env.example)Netlify/Vercel
API Keys (Secret)✅ Ja❌ NIEMALS✅ Ja
Public Keys✅ Ja✅ Ja✅ Ja
Config (nicht geheim)✅ Ja✅ Ja✅ Optional

Die goldene Regel:

NIEMALS Secrets in Git committen! .env gehört in .gitignore.

Das ist die wichtigste Regel beim Umgang mit Environment Variables. Ich habe Horrorgeschichten gesehen von Entwicklern, die versehentlich AWS Keys auf GitHub gepusht haben – binnen Minuten fanden Bots die Keys und starteten Bitcoin-Mining-Server. Die Rechnung: 50.000€ in 24 Stunden.

So machst du es richtig:

# .gitignore (diese Datei MUSS in deinem Projekt sein!)
node_modules/
.env
.env.local
.env.production
dist/
build/

Deine .env-Datei mit Secrets wird nie committed. Stattdessen commitest du eine .env.example mit Platzhaltern:

# .env.example (wird committed, zeigt anderen Entwicklern was sie brauchen)
DATABASE_URL=your-database-url-here
STRIPE_SECRET_KEY=your-stripe-key-here
API_ENDPOINT=https://api.example.com

Wenn jemand dein Projekt klont, kopiert er .env.example zu .env und füllt seine eigenen Werte ein.

Environment Variables in Netlify hinzufügen

So fügst du Environment Variables in Netlify hinzu:

  1. Wähle deine Site im Netlify Dashboard
  2. Gehe zu Site settings → Build & deploy → Environment
  3. Klicke auf “Edit variables”
  4. Füge deine Key-Value-Paare hinzu:
    • Key: Z.B. STRIPE_SECRET_KEY
    • Value: Der echte Wert, z.B. sk_live_abc123...
  5. Wichtig: Wähle den Scope (wo die Variable verfügbar sein soll):
    • All deploy contexts (Production + Previews + Branch deploys)
    • Production (nur live website)
    • Deploy previews (nur Pull Request Previews)
    • Branch deploys (nur spezifische Branches)
  6. Klicke “Save”

Was jetzt passiert: Netlify triggert automatisch einen neuen Build! Die Variable ist erst nach dem Redeploy verfügbar. Du siehst den Build-Prozess im Deploys-Tab.

Environment Variables in Vercel hinzufügen

Bei Vercel ist der Prozess ähnlich, aber etwas streamlined:

  1. Wähle dein Projekt im Vercel Dashboard
  2. Gehe zu Settings → Environment Variables
  3. Füge eine neue Variable hinzu:
    • Name: Z.B. DATABASE_URL
    • Value: Der echte Wert
  4. Wähle die Environments (wo soll die Variable verfügbar sein?):
    • Production (Live-Website)
    • Preview (Pull Request Deploys)
    • Development (lokal mit vercel dev)
  5. Klicke “Save”

Wichtig: Anders als Netlify triggered Vercel keinen automatischen Redeploy. Du musst manuell deployen (entweder git push oder über die Vercel UI: Deployments → ”…” → “Redeploy”).

Pro-Tipp: Mit der Vercel CLI kannst du Environment Variables auch aus dem Terminal managen:

# Variable hinzufügen
vercel env add SECRET_KEY

# Alle Variables anzeigen
vercel env ls

# Production Variables lokal nutzen
vercel env pull

Das vercel env pull Command erstellt eine .env.local-Datei mit allen Production-Variables – super praktisch für lokales Development!

Best Practices für Environment Variables

1. Verwende .env.example für Dokumentation:

# .env.example (wird in Git committed)
DATABASE_URL=your-database-url-here
API_KEY=your-api-key-here

# .env (wird NICHT committed)
DATABASE_URL=postgresql://real-connection-string
API_KEY=sk_live_real_key_12345

2. Unterschiedliche Values für Different Environments:

Du willst nicht versehentlich in Production auf deine Test-Datenbank zugreifen! Nutze verschiedene Werte für Development und Production:

# .env (lokal, Development)
DATABASE_URL=postgresql://localhost:5432/myapp_dev
STRIPE_KEY=sk_test_123... # Test-Mode Key
API_URL=http://localhost:3000/api

# Production (Netlify/Vercel)
DATABASE_URL=postgresql://prod-server:5432/myapp
STRIPE_KEY=sk_live_456... # Live-Mode Key
API_URL=https://api.meine-website.de

So kannst du lokal testen ohne echte Daten oder echte Payments zu beeinflussen.

3. Framework-spezifische Prefixes:

Moderne Frameworks unterscheiden zwischen Server-side und Client-side Variables:

Server-side Variables sind nur im Backend/Build-Prozess verfügbar. Sie werden nie im Browser-Code eingebaut. Perfekt für Secrets!

Client-side Variables werden im Browser-Code eingebaut. Jeder kann sie im Source Code sehen! Nur für öffentliche Werte nutzen.

Die Unterscheidung funktioniert über Prefixes:

# Vite: Nur VITE_ Prefix ist im Browser verfügbar
VITE_PUBLIC_API_URL=https://api.example.com
VITE_API_KEY=secret  # ❌ Nicht verfügbar!

# Next.js: NEXT_PUBLIC_ Prefix
NEXT_PUBLIC_API_URL=https://api.example.com

# Astro: PUBLIC_ Prefix
PUBLIC_API_URL=https://api.example.com

Häufige Fehler mit Environment Variables

Problem 1: Variable nicht verfügbar nach Hinzufügen

Du hast eine Variable in Netlify/Vercel hinzugefügt, aber dein Code findet sie nicht? Der Grund: Die Variable ist erst nach einem Redeploy verfügbar!

Lösung:

Warte, bis der Build durch ist, und teste dann erneut.

Problem 2: Public vs. Private Variables verwechselt

Du hast einen API Secret als NEXT_PUBLIC_API_KEY definiert? Katastrophe! Das NEXT_PUBLIC_ Prefix macht die Variable öffentlich sichtbar im Browser-Code.

Lösung:

# ✅ Richtig
DATABASE_URL=secret          # Server-only
NEXT_PUBLIC_API_URL=public   # Browser-safe

# ❌ Falsch
NEXT_PUBLIC_DB_PASSWORD=secret  # Jetzt öffentlich!!!

Problem 3: .env committed in Git

Du hast versehentlich deine .env-Datei mit Secrets committed und gepusht? Das ist ein Security-Notfall!

Sofort-Maßnahmen:

  1. Regeneriere alle Secrets die in der .env waren (neue API Keys, neue Passwörter)
  2. Entferne die .env aus Git-History (nicht nur den letzten Commit!)
# Mit git-filter-repo (empfohlen, aber komplex)
git filter-repo --invert-paths --path .env

# Oder: Repo neu aufsetzen (einfacher für kleine Projekte)
# 1. Lösche das GitHub-Repo
# 2. Entferne .git Ordner lokal
# 3. Füge .env zur .gitignore hinzu
# 4. git init, neues Repo erstellen, pushen

Präventiv: Stelle sicher, dass .env in .gitignore ist BEVOR du das erste Mal commitest!

CI/CD Pipeline – Automatisches Deployment bei Git Push

Jetzt wird’s spannend: Continuous Integration / Continuous Deployment. Klingt kompliziert, ist aber bereits eingebaut!

Was ist CI/CD?

CI/CD klingt nach Enterprise-Buzzword, ist aber eigentlich ganz simpel: Code schreiben, pushen, automatisch live. Keine manuelle FTP-Uploads mehr, keine “Hoffentlich habe ich nichts vergessen”-Momente.

Continuous Integration (CI):

Das bedeutet, dass dein Code bei jedem Commit automatisch getestet wird. Wenn du git push machst, laufen automatisch alle Tests. Falls etwas kaputt ist, erfährst du es sofort – nicht erst wenn ein Nutzer sich beschwert.

Bei jedem Push wird dein Code automatisch gebaut und geprüft. Funktioniert der Build? Laufen die Tests? Falls nein, wird nicht deployed. Das verhindert, dass kaputter Code auf Production landet.

Continuous Deployment (CD):

Das ist die logische Fortsetzung: Wenn alle Tests grün sind und der Build erfolgreich ist, wird automatisch deployed. Keine manuelle Intervention nötig.

Du pushst zu main, wartest 2 Minuten, und deine Änderungen sind live. Kein “Deploy”-Button, keine SSH-Commands, keine FTP-Clients. Es passiert einfach automatisch.

Das Beste: Wenn etwas schiefgeht, kannst du mit einem Klick zur vorherigen Version zurückkehren (Rollback). Du hast eine komplette History aller Deployments.

Der vollständige Workflow:

Developer schreibt Code
    ↓
git push origin main
    ↓
Netlify/Vercel erkennt Push
    ↓
Code wird heruntergeladen
    ↓
Dependencies installieren (npm install)
    ↓
Tests laufen (npm test)
    ↓
Build erstellen (npm run build)
    ↓
Build auf CDN deployen
    ↓
DNS aktualisieren
    ↓
Site ist LIVE! 🎉

Wie funktioniert automatisches Deployment?

Die Magie dahinter sind Webhooks – eine simple, aber mächtige Technologie.

So funktioniert’s:

Wenn du dein Repository mit Netlify oder Vercel verbindest, registrieren die Plattformen einen Webhook bei GitHub. Das ist im Prinzip eine Callback-URL, die GitHub benachrichtigt, wenn etwas passiert.

Der Ablauf im Detail:

  1. Du pushst Code zu GitHub: git push origin main
  2. GitHub sendet eine Notification: “Hey Netlify, im Repository XYZ gibt’s einen neuen Commit auf dem main-Branch!”
  3. Netlify/Vercel empfängt die Notification und startet sofort den Build-Prozess
  4. Code wird heruntergeladen, Dependencies installiert, Build ausgeführt
  5. Bei Erfolg: Die neue Version wird auf das CDN deployed und ist innerhalb von Sekunden live
  6. Bei Fehler: Du bekommst eine E-Mail mit dem Build-Log, und die alte Version bleibt online

Das Schöne: Du musst nichts konfigurieren. Sobald du dein Repository verbunden hast, ist der Webhook automatisch eingerichtet. Jeder Push triggert ein Deployment.

Du kannst das in den GitHub Repository Settings sehen: Gehe zu Settings → Webhooks und du siehst den Netlify/Vercel Webhook mit allen Events, die er abonniert hat.

Branch-basiertes Deployment

Ein mächtiges Feature: Different Branches = Different Deployments

Stell dir vor, du arbeitest an einem neuen Feature in einem eigenen Branch. Du willst es testen, bevor es auf Production geht. Mit Branch-basiertem Deployment bekommt jeder Branch seine eigene URL!

Typischer Git-Flow:

main (Production)
    ↓ Deploy zu: https://meine-site.com

develop (Staging)
    ↓ Deploy zu: https://develop--my-site.netlify.app

feature/new-design (Preview)
    ↓ Deploy zu: https://new-design--my-site.netlify.app

Jeder Branch wird automatisch deployed und bekommt eine eigene Subdomain. Du kannst das neue Feature in Ruhe testen, ohne die Live-Site zu beeinflussen.

Wie einrichten?

Bei Netlify:

Branch-Deploys sind standardmäßig aktiviert! Jeder Branch, den du pushst, bekommt automatisch eine URL. Du findest alle Branch-Deploys im “Deploys” Tab unter “Branch deploys”.

Falls du es feiner einstellen willst: Site settings → Build & deploy → Continuous deployment → Branch deploys. Hier kannst du wählen:

Bei Vercel:

Vercel deployed standardmäßig nur main als Production. Andere Branches werden als “Preview” deployed. Das funktioniert automatisch – kein Setup nötig.

Wenn du einen bestimmten Branch als Production markieren willst: Settings → Git → Production Branch und wähle den Branch aus.

Deploy Previews – Die Killer-Feature

Das Problem: Du willst eine Änderung testen, bevor sie live geht.

Die Lösung: Deploy Previews für jeden Pull Request!

Deploy Previews sind das Feature, das moderne Deployment-Plattformen von klassischem Hosting unterscheidet. Und es ist unfassbar praktisch.

So funktioniert’s:

  1. Du erstellst einen Pull Request auf GitHub mit deinen Änderungen
  2. Netlify/Vercel erkennt den PR und startet automatisch einen Preview-Deploy
  3. Innerhalb von 1-3 Minuten ist die Preview fertig
  4. Ein Bot kommentiert im PR mit der Preview-URL: “Deploy preview ready! https://pr-42—meine-site.netlify.app”
  5. Du und dein Team können die Änderungen testen ohne dass sie die Live-Site beeinflussen
  6. Nach dem Merge wird automatisch zu Production deployed

Warum das so mächtig ist:

Du kannst Stakeholder (Kunden, Designer, Product Manager) einfach die Preview-URL schicken. Sie sehen die Änderungen in einer echten Umgebung, nicht auf deinem Laptop mit localhost:3000. Feedback kommt früher, Bugs werden vor Production gefunden.

Für Solo-Entwickler: Du kannst verschiedene Ansätze ausprobieren (z.B. zwei unterschiedliche Designs), beide als PRs erstellen, beide Preview-URLs öffnen und vergleichen.

Build Hooks – Deployment ohne Git Push

Use Case: Du willst einen Deploy triggern ohne Code zu ändern (z.B. CMS-Content-Update).

Manchmal willst du einen neuen Build starten, ohne dass sich der Code geändert hat. Build Hooks ermöglichen genau das.

Was sind Build Hooks?

Ein Build Hook ist eine spezielle URL, die du per POST-Request aufrufen kannst um einen Build zu triggern. Das ist im Prinzip ein “Deploy jetzt”-Button, aber über eine API.

So erstellst du einen Build Hook:

Bei Netlify:

  1. Site settings → Build & deploy → Build hooks
  2. “Add build hook” klicken
  3. Namen eingeben (z.B. “Contentful Webhook”)
  4. Branch wählen (normalerweise main)
  5. Speichern – du bekommst eine URL im Format: https://api.netlify.com/build_hooks/[deine-hook-id]

Bei Vercel:

  1. Settings → Git → Deploy Hooks
  2. “Create Hook” klicken
  3. Namen und Branch wählen
  4. URL kopieren

Build Hook nutzen:

# Deploy triggern
curl -X POST https://api.netlify.com/build_hooks/abc123def456

# Oder aus einer anderen App/Service
fetch('https://api.netlify.com/build_hooks/abc123def456', {
  method: 'POST'
});

Wann brauchst du das?

Headless CMS Integration: Du nutzt ein CMS wie Contentful, Sanity oder Strapi. Wenn ein Editor Content veröffentlicht, soll automatisch ein neuer Build laufen. Du konfigurierst im CMS einen Webhook, der bei “Publish” den Netlify Build Hook aufruft.

Scheduled Builds: Du willst jeden Tag um 3 Uhr morgens einen Build laufen lassen (z.B. um Daten von einer API zu fetchen). Nutze einen Cron-Service wie GitHub Actions oder cron-job.org, der täglich den Build Hook aufruft.

External Data Sources: Deine Website zeigt Daten aus einer Datenbank oder API. Wenn die Daten aktualisiert werden, soll die Site neu gebaut werden. Der Daten-Service ruft den Build Hook auf.

Die 5 häufigsten Deployment-Fehler (und Lösungen)

Selbst mit den besten Tools kann beim Deployment etwas schiefgehen. Hier sind die 5 häufigsten Fehler – und wie du sie behebst.

1. Build funktioniert lokal, aber nicht auf der Plattform

Symptom:

npm run build
# Lokal: ✅ Build successful!

# Netlify/Vercel: ❌ Build failed

Häufige Ursachen:

Unterschiedliche Node-Versionen: Lokal nutzt du Node 20, aber Netlify nutzt standardmäßig Node 16. Neuere Features funktionieren nicht, der Build bricht ab.

Dependencies fehlen in package.json: Du hast ein Package global installiert (npm i -g something) und nutzt es im Build, aber es steht nicht in package.json. Lokal funktioniert’s, auf dem Server nicht.

Environment Variables nicht gesetzt: Dein Build braucht eine Variable wie API_ENDPOINT, aber du hast vergessen, sie in Netlify hinzuzufügen.

Case-sensitive Imports: Auf Mac/Windows funktioniert import Component from './component' auch wenn die Datei Component.tsx heißt. Auf Linux (wo die Deployment-Server laufen) schlägt das fehl!

Absolute Pfade ohne Alias-Konfiguration: Du nutzt import '@/components/Button' aber die Path-Aliases sind nur in deiner lokalen IDE konfiguriert, nicht in tsconfig.json.

Lösung:

1. Node-Version fixieren:

Erstelle eine .nvmrc-Datei im Root deines Projekts:

# .nvmrc
20

Oder bei Netlify in netlify.toml:

[build.environment]
  NODE_VERSION = "20"

2. Package Dependencies prüfen:

# Liste alle installierten Packages
npm list --depth=0

# Checke ob alles in package.json ist
# Reinstalliere alles von scratch
rm -rf node_modules package-lock.json
npm install
npm run build

3. Environment Variables checken:

Gehe in den Build-Log und suche nach Fehlern wie “undefined is not a function” oder “Cannot read property X of undefined”. Oft deutet das auf fehlende Env Vars hin.

4. Case-Sensitivity fixen:

Nutze das richtige Casing für Imports. Wenn die Datei Component.tsx heißt, importiere mit großem C: import Component from './Component'.

5. Path Aliases konfigurieren:

Stelle sicher, dass deine Aliases in der Build-Konfiguration definiert sind:

// tsconfig.json
{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["src/*"],
      "@components/*": ["src/components/*"]
    }
  }
}

Und für Vite zusätzlich in vite.config.ts:

import { defineConfig } from "vite";
import path from "path";

export default defineConfig({
  resolve: {
    alias: {
      "@": path.resolve(__dirname, "./src"),
      "@components": path.resolve(__dirname, "./src/components"),
    },
  },
});

2. Environment Variables vergessen

Symptom:

Site is live, aber Features funktionieren nicht:
- API-Calls schlagen fehl
- Datenbank-Connection fehlt
- Externe Services nicht erreichbar

Lösung:

Das hast du wahrscheinlich vergessen! Gehe zurück zum Kapitel “Environment Variables” und füge alle benötigten Variables in Netlify/Vercel hinzu.

Checkliste:

  1. Öffne deine lokale .env-Datei
  2. Liste alle Variables auf, die dein Code braucht
  3. Gehe zu Netlify/Vercel → Environment Variables
  4. Füge jede Variable mit dem richtigen Value hinzu
  5. Wichtig: Redeploy nach dem Hinzufügen!
    • Netlify: Automatisch
    • Vercel: Manuell (neuer Push oder “Redeploy” klicken)

Debug-Tipp: Füge temporär ein console.log(process.env) in deinen Code ein und checke den Build-Log. Du siehst dann, welche Variables ankommen und welche fehlen.

3. Falsche Node-Version

Symptom:

Build failed: Error: Cannot find module 'node:crypto'
# → Du nutzt eine zu alte Node-Version

Lösung:

Node-Version in Netlify/Vercel festlegen:

# Erstelle .nvmrc im Root
echo "20" > .nvmrc

# Oder in netlify.toml
[build.environment]
  NODE_VERSION = "20"

# Oder in Vercel-Settings
# Project Settings → General → Node.js Version → 20.x

4. Relative Pfade vs. Absolute Pfade

Symptom:

Build successful, aber auf der Website:
- Images 404
- Links gehen ins Leere
- CSS nicht geladen

Ursache: Falsche Base-URL oder Asset-Pfade.

Lösung:

Verschiedene Frameworks brauchen verschiedene Konfigurationen:

Astro:

// astro.config.mjs
export default defineConfig({
  site: "https://deinedomain.com", // Deine finale URL
  base: "/", // Für Root-Domain, oder '/subfolder' für Unterverzeichnisse
});

Next.js:

// next.config.js
module.exports = {
  basePath: "", // Leer lassen für Root-Domain
  assetPrefix:
    process.env.NODE_ENV === "production" ? "https://cdn.deinedomain.com" : "",
};

Vite/Vue/React:

// vite.config.js
export default defineConfig({
  base:
    process.env.NODE_ENV === "production" ? "https://deinedomain.com/" : "/",
});

Quick-Fix: Nutze relative Pfade statt absolute:

// ❌ Schlecht
<img src="/images/logo.png" />

// ✅ Gut (mit import)
import logo from './images/logo.png';
<img src={logo} />

// ✅ Gut (für Public-Ordner)
<img src={new URL('/images/logo.png', import.meta.url).href} />

5. Cached Dependencies – “Aber bei mir funktioniert es!”

Symptom:

Lokal: ✅ Alles funktioniert
Nach git push: ❌ Build failed oder alte Version online

Ursache: Netlify/Vercel cached node_modules.

Lösung:

Netlify: Cache manuell löschen

  1. Gehe zu deiner Site im Netlify Dashboard
  2. Site settings → Build & deploy → Build settings
  3. Scrolle nach unten zu “Build hooks”
  4. Klicke auf “Clear cache and deploy site”

Alternativ in netlify.toml:

[build]
  command = "npm ci && npm run build"  # npm ci löscht node_modules

Vercel: Cache clearen

  1. Gehe zu deinem Projekt im Vercel Dashboard
  2. Klicke auf Settings → General
  3. Scrolle zu “Build & Development Settings”
  4. Aktiviere temporär “Override Build Command”
  5. Füge hinzu: rm -rf node_modules && npm install && npm run build
  6. Triggere neuen Deploy
  7. Deaktiviere Override wieder

CLI-Lösung (schnellster Weg):

# Netlify
netlify deploy --prod --clear-cache

# Vercel
vercel --force  # Forciert kompletten Rebuild

Präventiv-Tipp: Nutze npm ci statt npm install im Build-Command. Das sorgt für saubere Installs ohne Cache-Probleme:

# package.json
"scripts": {
  "build": "npm ci && astro build"
}

Testing & Monitoring nach dem Launch

Deine Site ist live – aber funktioniert auch alles?

Funktioniert alles? Die Post-Launch-Checkliste

Performance Monitoring

Tools für Performance-Tracking:

  1. Lighthouse CI – Automatische Performance-Tests bei jedem Deploy

    • Integriert sich direkt in deine CI/CD-Pipeline
    • Warnt dich, wenn Performance schlechter wird
    • Setup: npm install -D @lhci/cli

  2. PageSpeed Insights (pagespeed.web.dev)

    • Kostenloses Tool von Google
    • Zeigt Real-User-Data (CrUX) + Lab-Data
    • Konkrete Verbesserungsvorschläge

  3. WebPageTest (webpagetest.org)

    • Detaillierte Performance-Analyse
    • Teste von verschiedenen Standorten und Devices
    • Waterfall-Diagramm zeigt jeden Request

  4. Vercel Analytics – Eingebaut bei Vercel

    • Real-User-Monitoring direkt im Dashboard
    • Core Web Vitals tracking
    • Kostenlos für Hobby-Projekte

  5. Netlify Analytics – Kostenpflichtig (9$/Monat)

    • Server-seitiges Tracking (kein JavaScript nötig)
    • Privacy-freundlich, kein Cookie-Banner nötig
    • Zeigt echte Nutzerdaten, keine geschätzten Zahlen

Core Web Vitals im Blick behalten:

Google nutzt drei Metriken, um die User Experience zu messen:

  1. LCP (Largest Contentful Paint) – Wie schnell lädt der größte sichtbare Content?

    • Ziel: < 2,5 Sekunden
    • Häufige Probleme: Große Bilder, langsame Server-Response
    • Fix: Bilder optimieren, CDN nutzen, Preload für kritische Assets

  2. INP (Interaction to Next Paint) – Wie schnell reagiert die Seite auf Klicks?

    • Ziel: < 200ms
    • Häufige Probleme: Zu viel JavaScript, blockierende Scripts
    • Fix: Code-Splitting, Lazy Loading, Web Workers

  3. CLS (Cumulative Layout Shift) – Verschiebt sich Content beim Laden?

    • Ziel: < 0,1
    • Häufige Probleme: Bilder ohne width/height, Ads, Webfonts
    • Fix: Dimensions für alle Bilder, font-display: swap

Tipp: Installiere die Web Vitals Chrome Extension für Live-Monitoring beim Surfen.

Error Tracking

Wie findest du Fehler in Production?

Deine Nutzer sehen Fehler, bevor du sie siehst. Error Tracking hilft dir, Probleme zu finden und zu beheben, bevor zu viele User betroffen sind.

1. Sentry – Der Platzhirsch für Error Monitoring

npm install @sentry/astro  # oder @sentry/nextjs, @sentry/react

Features:

2. LogRocket – Session Replay

LogRocket zeichnet User-Sessions auf (wie ein Video), sodass du siehst, was der User vor dem Fehler gemacht hat.

3. Browser DevTools + Remote Debugging

Für schnelle Checks ohne extra Tools:

// In production temporär aktivieren
console.error("Debug Info:", { user, state, environment });

Achtung: Nie sensible Daten loggen! Nutze conditional logging:

if (import.meta.env.DEV) {
  console.log("Debug info here");
}

4. Netlify/Vercel Build Logs

Deine Plattform zeigt alle Build-Fehler:

Tipp: Aktiviere E-Mail-Benachrichtigungen für Failed Builds im Dashboard.

Analytics – Wie viele Nutzer hast du wirklich?

Du hast deine Website deployed – aber woher weißt du, ob jemand sie besucht? Analytics zeigen dir Besucherzahlen, Traffic-Quellen und beliebteste Seiten.

DSGVO-konforme Analytics-Tools:

Gute Nachricht: Moderne Privacy-First Analytics brauchen KEIN Cookie-Banner nach TTDSG § 25! Hier sind die besten Optionen für deutsche Websites:

Budget-Friendly (Empfohlen für Einsteiger):

1. Pirsch Analytics 🇩🇪 – pirsch.io

Perfekt für: Budget-bewusste deutsche Entwickler, die lokalen Support wollen

2. Plausible Analytics – plausible.io

Perfekt für: Professionelle Projekte, die Wert auf einfache Privacy legen

3. Umami (Open Source) – umami.is

Perfekt für: Entwickler mit eigenem Server, die 100% Kontrolle wollen

Feature-Rich (Google Analytics Alternative):

4. Matomo 🇩🇪 – matomo.org

Perfekt für: Wer alle GA-Features braucht, aber DSGVO-konform

Nicht empfohlen:

5. Google Analytics 4 (GA4)

Nicht empfohlen für deutsche Websites – zu hohes rechtliches Risiko!

🇩🇪 = Deutscher Anbieter mit Servern in Deutschland

Meine klare Empfehlung für deutsche Websites:

Alle empfohlenen Tools brauchen keinen Cookie-Banner, weil sie cookiefrei arbeiten. Das spart dir Entwicklungszeit und verbessert die User Experience!

Pre-Launch Checkliste – Nichts vergessen!

Bevor du auf den “Deploy”-Button drückst, gehe diese Checkliste durch:

Code & Build

Content & SEO

Performance & Security

Legal & Compliance (DSGVO!)

Fazit: Von 0 zu Live in unter einer Stunde

Wir haben eine lange Reise hinter uns! Von den Grundlagen des Deployments über die Wahl der richtigen Plattform bis hin zu Custom Domains, Environment Variables und CI/CD-Pipelines.

Die wichtigsten Takeaways

1. Deployment ist Heute einfacher denn je

Kein FTP, keine Server-Konfiguration, keine SSH-Keys. Du pushst Code zu GitHub, und Netlify/Vercel machen den Rest. Was früher Stunden dauerte, funktioniert heute in Minuten.

2. Git-basierter Workflow ist der Standard

git push → automatisches Deployment. Kein manuelles Hochladen, keine Versionskonflikte, keine “Funktioniert auf meinem Rechner”-Probleme mehr.

3. Netlify vs. Vercel: Beide sind großartig

Netlify ist perfekt für Static Sites und hat bessere Form-Handling. Vercel ist optimal für Next.js und React-Apps. Beide bieten kostenlose Tier für Hobby-Projekte. Du kannst nichts falsch machen.

4. Automatisches Deployment spart Zeit und Nerven

Jeder Git-Push triggert automatisch einen neuen Deploy. Deploy Previews zeigen deine Änderungen, bevor sie live gehen. Kein manuelles Testen auf Staging-Servern mehr nötig.

5. Custom Domain + SSL ist kostenlos und einfach

Eine eigene Domain kostet 10€/Jahr. SSL-Zertifikate sind bei Netlify/Vercel kostenlos und werden automatisch erneuert. Kein Grund mehr für “http://”.

6. Environment Variables NIEMALS in Git!

.env → .gitignore. API-Keys gehören in das Netlify/Vercel Dashboard. Ein einziger Commit mit Secrets kann dich 50.000€ kosten (Bitcoin-Mining-Bots lauern überall).

7. Testing und Monitoring nicht vergessen

Deine Site ist live – aber funktioniert sie auch? Lighthouse für Performance, Sentry für Error-Tracking, Plausible für Analytics. Du willst wissen, wenn etwas kaputt geht, nicht deine Nutzer.

Dein nächster Schritt

Jetzt bist du dran! Nimm ein Projekt, das lokal läuft, und deploye es:

  1. Repository auf GitHub pushen
  2. Netlify oder Vercel Account erstellen
  3. Site deployen
  4. Custom Domain hinzufügen (optional, aber empfohlen)
  5. Automatisches Deployment testen (Code ändern, pushen, live sehen)

Deployment ist kein Hexenwerk mehr – es ist ein systematischer Prozess, den du jetzt beherrschst.

Möchtest du mehr lernen?

Deployment ist nur ein Teil der modernen Webentwicklung. Wenn du tiefer in die Materie einsteigen und lernen möchtest, wie man performante Websites baut, schau dir meinen anderen Guide an:

Bis dahin: Viel Erfolg mit deinem Deployment – und vergiss nicht: Die erste Live-Website ist immer die aufregendste! 🚀

Weitere Blog Artikel

Mobile First Email Design – Email-Darstellung auf Smartphone und Desktop im Vergleich
07.11.2025
Mobile First Email Design – Der praktische Guide für 2025
 KI in der Softwareentwicklung - Chance oder Risiko für Entwickler 2025
01.11.2025
KI in der Softwareentwicklung: Chance oder Risiko?
 Windsurf vs. Cursor - KI-Editor Vergleich 2025
26.10.2025
Windsurf vs. Cursor: Welcher KI-Editor macht dich zum 10x-Developer?
 HTML Email Grundlagen für Anfänger
22.10.2025
HTML Email Grundlagen für Anfänger - Der ultimative Einstieg