15 Minuten
Das eigene Projekt prüfen
Öffne deinen eigenen Projektordner oder dein eigenes Lovable-Projekt. Notiere den Namen des Projekts, die wichtigste Funktion und einen Test, der ihren Erfolg zeigt. Für die Kursübung reichen erfundene Namen und Adressen wie probe@example.test.
Eine Abhängigkeit ist etwas, das dein Projekt zum Laufen braucht. Dazu gehören Zusatzpakete, eine bestimmte Node- oder Python-Version, eine Datenbank, ein Login-Dienst oder ein geheimer Schlüssel. Prüfe die README, die Startanleitung deines Projekts. Bei JavaScript stehen Pakete und Befehle meist in package.json, bei Python in requirements.txt oder pyproject.toml. Notiere die Namen benötigter Einstellungen ohne ihre geheimen Werte.
Codex-Auftrag: Prüfe meinen Projektordner. Erkläre in einfacher Sprache, wie ich ihn lokal starte, welche Zusatzpakete und Dienste er braucht, welcher Befehl die Website baut und welcher Ordner dabei entsteht. Prüfe, ob Funktionen auf einem Server laufen und wo Daten gespeichert werden. Zeige mir zuerst deinen Plan.
Öffne die lokale Vorschau und teste deine Hauptfunktion. Wenn localhost keine Verbindung aufbaut, kontrolliere das Terminal mit dem Startbefehl und öffne die dort angezeigte Adresse.
25 Minuten
Dein Projekt für die Veröffentlichung vorbereiten
Lokal mit Codex
Arbeite in deinem eigenen Projektordner. Wenn du aus Tag 4 weiterarbeitest, kopiere deine eigene Mini-App nach Praxistag. Öffne diesen Ordner in Codex und lass den Plan prüfen, bevor Codex etwas umbaut.
Eine fertige HTML-Seite kannst du aus dem Ordner mit index.html und den zugehörigen Bildern, CSS- und JavaScript-Dateien veröffentlichen. Wenn dein Projekt React für die Oberfläche und Vite zum Erstellen der fertigen Dateien nutzt, helfen dir oft diese zwei Befehle. Führe es im Ordner mit package.json aus. npm ci setzt eine passende package-lock.json voraus. Nutzt dein Projekt pnpm, Yarn oder einen anderen Befehl, folge seiner Projektanleitung.
npm ci
npm run buildVite legt das Ergebnis normalerweise in dist ab. Prüfe im Terminal, welchen Ordner dein Projekt tatsächlich erzeugt. Öffne bei Vite mit npm run preview die gebaute Version und teste auch Bilder, Navigation und einen direkten Aufruf einer Unterseite.
Cloudflare · Build-Einstellungen
Aus Lovable
Erweitere dein eigenes Projekt aus Tag 4 mit ein bis zwei Bausteinen. Entwirf je Baustein einen Prompt. Nutze Visual Edit für kleine Korrekturen und arbeite mit dem vorhandenen Kursbudget. Prüfe die Funktionen zuerst in der Lovable-Vorschau.
Öffne Project settings → Git → GitHub. Richte bei Bedarf die Verbindung zu deinem GitHub-Konto ein und verbinde dein Projekt. Öffne das entstandene Repository, also den Projektordner auf GitHub. Prüfe, welcher Ordner package.json enthält und welche Build-Einstellungen das Projekt braucht. Cloudflare braucht Zugriff auf dieses Repository.
Der Export überträgt den Code. Prüfe separat, welche Datenbank, welchen Login-Dienst und welche Serverfunktionen das Projekt verwendet. Wenn dein Projekt etwa Supabase verwendet, kann die Oberfläche auf Cloudflare laufen und weiter diesen Dienst nutzen, sofern die Einrichtung das unterstützt. Trage die öffentlichen Einstellungen des Projekts ein. Gib beim Login-Dienst die neue Adresse an, zu der Besucher nach dem Anmelden zurückkehren. Prüfe, wer welche Daten sehen darf. Für eine echte Migration zu D1 müssen Daten, Anfragen und Zugriffsregeln angepasst und erneut getestet werden.
30 Minuten
Passenden Weg wählen und veröffentlichen
Fertige Dateien per Direct Upload
Öffne Cloudflare → Workers & Pages → Create application und wähle den Pages-Weg für Drag and Drop. Gib dem Projekt einen eigenen Namen und lade den fertigen Ordner oder ein ZIP mit index.html auf der obersten Ebene hoch. Bei Vite ist das normalerweise der Inhalt von dist. Wähle Deploy site und öffne die angezeigte pages.dev-Adresse.
Erscheint „Your upload exceeds the limit of 1000 files“, prüfe zuerst den Upload-Ordner. node_modules, .git, .env, die Python-Umgebung und lokale Datenbankdateien gehören nicht hinein. Für einen tatsächlich größeren fertigen Ordner unterstützt Wrangler bis zu 20.000 Dateien. Gib dem Befehl deinen Ausgabeordner und deinen Projektnamen.
npx wrangler pages deploy dist --project-name mein-kursprojekt
Automatisch aus GitHub veröffentlichen
Öffne Cloudflare → Workers & Pages → Create application und wähle die Pages-Verbindung zu Git. Verbinde das eigene GitHub-Repository. Wähle den Produktionszweig, meist main. Falls package.json in frontend liegt, setze frontend als Projektwurzel. Für Vite sind npm run build und dist typische Werte. Übernimm die tatsächlichen Werte deines Projekts und starte Save and Deploy. Prüfe das Bericht mit den Fehlermeldungen, wenn Cloudflare den Bau abbricht.
Trage nur Einstellungen ein, die dein Projekt braucht. Öffentliche Browserwerte und geheime Serverwerte haben unterschiedliche Aufgaben. Vite-Werte mit VITE_ können im Browser sichtbar sein. Geheime Schlüssel gehören in den Serverbereich unter Variables and Secrets.
Wenn dein Projekt Serverfunktionen braucht
Ein Formular, ein Login oder ein eigener Endpunkt wie /api/kontakt kann Servercode benötigen. Eine erfolgreiche Veröffentlichung der Oberfläche sagt noch nichts darüber aus, ob diese Funktionen laufen. Für JavaScript auf Pages kommen Pages Functions infrage. Lade ein Projekt mit einem functions-Ordner per Git oder Wrangler hoch. Ein bereits für Pages gebautes _worker.js im Ausgabeordner kann auch beim direkten Upload mitgehen.
Für eine lokale Flask-App unterstützt Cloudflare Python Workers. Lass Codex den Einstiegspunkt, die Pakete und die Datenbankanbindung prüfen. Passe den Server an die Python-Workers-Laufzeit an, teste mit uv run pywrangler dev und veröffentliche mit uv run pywrangler deploy. Eine lokale SQLite-Datei ist kein dauerhaftes Online-Laufwerk. Verwende für diese Kursvariante D1 als Onlinespeicher und passe den Datenbankcode an. Wenn die Oberfläche getrennt auf Pages läuft, prüfe die öffentliche API-Adresse und den Zugriff aus der Pages-Domain. Alternativ kann der Python Worker die gebaute Oberfläche mit ausliefern.
50 Minuten
Datenbanken auf Cloudflare einrichten
Hero-Bereich, Mehrsprachigkeit mit lokal gespeicherter Sprachwahl und Bildergalerie brauchen für die Kursziele keine gemeinsame Datenbank. Für die fünf Bausteine unten hilft D1, eine von Cloudflare verwaltete SQL-Datenbank. Richte nur die Tabellen für die Bausteine ein, die dein Projekt verwendet.
D1 anlegen, Tabellen erstellen und verbinden
Codex-Auftrag: Mein Baustein ist [Name]. Prüfe den vorhandenen Code und die Datenbank. Erstelle einen Plan für SQL-Datei, Serverfunktionen und Zugriffsregeln. Zeige mir die lokale Prüfung und die Schritte für Cloudflare. Nutze Testdaten und frage nach, bevor du vorhandene Daten änderst.
1. Öffne im Cloudflare-Dashboard Storage & databases → D1 SQL database → Create database. Gib ihr einen eigenen Namen, etwa mein-kurs-db. Nutze für Tests eine separate Datenbank, wenn dein Projekt schon echte Daten enthält.
2. Lass Codex für deinen Baustein eine SQL-Datei erzeugen und die nötigen Serverfunktionen bauen. Die Beispiele unten zeigen die Tabellenstruktur. Lass sie an dein Projekt anpassen. SQL ist die Sprache, mit der du Tabellen und Regeln anlegst. Prüfe Tabellen und Spalten. Wenn bereits Daten existieren, sichere sie vor dem Import und teste die Umstellung mit einer Kopie. Importiere eine geprüfte SQL-Datei, keine rohe .sqlite-Datei. Passe Namen und Pfad in diesem Beispiel an.
npx wrangler loginFür die lokale Kopie richte zuerst in der Wrangler-Konfiguration die D1-Bindung ein. Verwende beim anschließenden Online-Import den tatsächlichen Namen deiner Cloudflare-Datenbank.
npx wrangler d1 execute mein-kurs-db --local --file=./schema.sql
npx wrangler d1 execute mein-kurs-db --remote --file=./schema.sql3. Öffne dein Pages-Projekt → Settings → Bindings → Add → D1 database bindings. Wähle die Datenbank und trage den Namen ein, den der Servercode erwartet, zum Beispiel DB für context.env.DB. Bei einem Worker trägst du die D1-Bindung mit Name und Datenbank-ID in die Wrangler-Konfiguration ein. Production ist die öffentliche Version, Preview die Vorschau. Verbinde die richtige Datenbank mit der richtigen Umgebung.
4. Veröffentliche erneut. Rufe dein Formular oder deine Funktion über die öffentliche Adresse auf. Prüfe den Eintrag über die D1-Konsole oder die geschützte Verwaltung. Prüfe auch, dass Gäste keine privaten Daten abrufen können. Verwende für die Kursübung ausschließlich Testdaten.
Cloudflare · D1 mit Pages verbinden
Cloudflare · SQL-Dateien mit Wrangler ausführen
Benutzerkonten mit Login
Richte einen bestehenden Login-Dienst ein und trage die Cloudflare-Adresse als erlaubte Rückleitung ein. Lege in D1 eine Tabelle profiles an, mit der eindeutigen Konto-ID des Login-Dienstes als Schlüssel und den zusätzlichen Profildaten deines Projekts. Der Server prüft die Anmeldung bei jedem Zugriff und liest die Konto-ID aus der geprüften Sitzung. Passwörter bleiben beim Login-Dienst.
CREATE TABLE profiles (user_id TEXT PRIMARY KEY NOT NULL, display_name TEXT NOT NULL);Test Lege zwei Testkonten an. Melde dich ab und wieder an. Konto A darf das Profil von Konto B auch über eine direkte URL oder eine geänderte Anfrage nicht lesen oder ändern.
Kontaktformular mit Datenbank
Lege contacts mit ID, Name, E-Mail, Nachricht und Eingangszeit an. Lass den Server Pflichtfelder und Längen prüfen und die Anfrage speichern. Schütze die Liste über die Betreiberrolle. Öffentliche Besucher brauchen nur Zugriff auf das Absenden.
CREATE TABLE contacts (id INTEGER PRIMARY KEY, name TEXT NOT NULL, email TEXT NOT NULL, message TEXT NOT NULL, received_at TEXT NOT NULL DEFAULT CURRENT_TIMESTAMP);Test Sende eine Anfrage und prüfe sie in der Betreiberliste. Öffne dieselbe Listenadresse in einem privaten Fenster. Dort darf die Anfrage nicht erscheinen.
Online-Terminbuchung
Lege slots für freie Zeiten und bookings für Buchungen an. Für einen Platz pro Termin erhält bookings eine Eindeutigkeitsregel für slot_id. Der Server speichert direkt mit dieser Regel. Die Datenbank entscheidet auch dann, wenn zwei Anfragen gleichzeitig eintreffen.
CREATE TABLE slots (id INTEGER PRIMARY KEY, starts_at TEXT NOT NULL UNIQUE);
CREATE TABLE bookings (slot_id INTEGER PRIMARY KEY REFERENCES slots(id), name TEXT NOT NULL, email TEXT NOT NULL);Test Öffne denselben freien Termin in zwei Fenstern und buche ihn fast gleichzeitig. Prüfe, dass genau ein Eintrag gespeichert wurde. Bei einem eigenen Gruppenangebot kannst du pro Termin mehrere nummerierte Plätze mit eindeutigen Paaren aus Termin und Platznummer verwenden.
Blog mit Admin-Bereich
Lege posts mit ID, Titel, Text und einem optionalen Veröffentlichungszeitpunkt an. Schütze Schreiben und Veröffentlichen über eine serverseitig geprüfte Betreiberrolle. Die öffentliche Abfrage gibt nur veröffentlichte Beiträge aus. Wenn dein Editor HTML erzeugt, bereinige es vor der Anzeige.
CREATE TABLE posts (id INTEGER PRIMARY KEY, title TEXT NOT NULL, body TEXT NOT NULL, published_at TEXT);Test Speichere einen Entwurf und öffne den Blog in einem privaten Fenster. Veröffentliche danach den Beitrag. Prüfe, dass er erst jetzt öffentlich erscheint und der Entwurf eines weiteren Beitrags verborgen bleibt.
Newsletter-Anmeldung
Lege subscribers mit E-Mail, Anmeldezeit und optionaler Bestätigungszeit an. Entferne Rand-Leerzeichen, schreibe die Adresse einheitlich klein und erzwinge Eindeutigkeit in D1. Speichere die Anmeldung zunächst als offen. Nach dem Klick auf einen einmalig nutzbaren, zeitlich begrenzten Bestätigungslink markiert dein Server sie als bestätigt. Speichere dafür nur den Hash, also den Prüfwert des zufällig erzeugten Codes. Begrenze neue Versandversuche pro Adresse.
CREATE TABLE subscribers (email TEXT PRIMARY KEY NOT NULL COLLATE NOCASE CHECK (email = trim(email)), subscribed_at TEXT NOT NULL DEFAULT CURRENT_TIMESTAMP, confirmed_at TEXT, token_hash TEXT, token_expires_at TEXT);Test Melde ein eigenes Testpostfach an. Der Eintrag steht zunächst als offen in der Datenbank. Öffne die Bestätigungsmail und klicke den Link. Prüfe, dass der Status wechselt und derselbe Link kein zweites Mal wirkt. Melde dieselbe Adresse mit anderer Großschreibung und Rand-Leerzeichen erneut an. Es bleibt ein Eintrag. In der Übung wird nur die Bestätigungsmail verschickt.
Versanddienst für die Bestätigungsmail
Migadu bietet eine zeitlich begrenzte kostenlose Testphase ohne Kreditkarte. Der frühere Gratis-Tarif wurde durch Micro ersetzt. Stand 13. November 2026 kostet Micro 19 US-Dollar pro Jahr. Migadu ist für persönliche Korrespondenz gedacht. Seine Nutzungsregeln schließen Newsletter, automatischen Versand und Transaktionsmails ausdrücklich aus.
Wenn du ein persönliches Testpostfach brauchst, öffne das Anmeldeformular von Migadu. Gib deinen Namen und eine bestehende E-Mail-Adresse an, akzeptiere die Bedingungen selbst und bestätige die Nachricht im Postfach. Füge im Migadu-Dashboard eine eigene Domain hinzu, deren DNS-Einträge du verwaltest. Übernimm die angezeigten DNS-Einträge, prüfe die Diagnose und aktiviere die Domain. Erstelle danach ein Postfach und teste eine persönliche Nachricht im Webmail. Für die Adresse brauchst du eine eigene Domain. Die von Cloudflare bereitgestellte pages.dev-Adresse kannst du dafür nicht verwalten.
Migadu · Domain und Postfach einrichten
Brevo bietet im zeitlich unbegrenzten Gratis-Tarif bis zu 300 Sendungen pro Tag. Registriere ein Konto, authentifiziere die Absender-Domain und richte den Absender ein. Prüfe, ob der Transaktionsversand freigeschaltet ist. Unter Settings → SMTP & API findest du den SMTP-Benutzernamen und kannst einen SMTP-Schlüssel erstellen. Ein SMTP-fähiger Server nutzt smtp-relay.brevo.com mit Port 587 und STARTTLS. Der SMTP-Schlüssel ist das Passwort.
Für Pages Functions oder Workers kann der Server dieselbe Bestätigungsmail über die HTTPS-Schnittstelle von Brevo verschicken. Dafür verwendest du einen separaten API-Schlüssel als Cloudflare-Secret. SMTP- und API-Schlüssel bleiben auf dem Server. Wenn dein Projekt bereits das Formular eines Newsletter-Dienstes einbettet, kann der Dienst die Bestätigung verwalten. Prüfe dann, ob und wie der bestätigte Status in deine eigene Datenbank übernommen wird. MailerLite und EmailOctopus bieten solche Formulare ebenfalls kostenlos an.
20 Minuten
Abnahme mit einer zweiten Person
Gib deiner Testperson die öffentliche HTTPS-Adresse. Sie öffnet die Seite am Handy oder in einem privaten Fenster. Testet Startseite, Navigation, Bilder und die wichtigste Funktion. Lade auch eine Unterseite direkt neu. Bei einer Datenbank prüft ihr zusätzlich den gespeicherten Eintrag und den Zugriff ohne Anmeldung.
Falls das Design fehlt, prüfe, ob der richtige Ausgabeordner hochgeladen wurde, ob CSS und Bilder darin liegen und ob ihre Pfade stimmen. Falls die Oberfläche lädt und das Formular scheitert, prüfe die öffentliche API-Adresse, die Datenbankbindung, die Tabellen und die Einstellungen für diese Umgebung. Falls der Login zurück zu localhost führt, korrigiere die Rückleitungsadresse beim Login-Dienst. Nach Änderungen an Build-Einstellungen oder Bindungen veröffentlichst du erneut und wiederholst den Test.
Haltet für die Abgabe die öffentliche Adresse, euren Veröffentlichungsweg, die Dienste eures Projekts und den bestandenen Test fest. Bei einem Fehler notiert ihr den genauen Wortlaut und den Schritt, an dem er auftrat.