5 Checks, bevor deine App live geht

Warum es bei dir läuft und live nicht

Während du baust, läuft deine App auf deinem eigenen Computer, oft „lokal“ genannt. „Live“ heißt dagegen: Sie ist im Internet für alle erreichbar. Lokal liest die App geheime Werte aus einer Datei auf deinem Rechner, schickt Leute nach der Anmeldung zu einer Adresse zurück, die mit localhost beginnt (so nennt dein Computer sich selbst), und spricht mit einer Testdatenbank voller eigener Daten. Eine Datenbank ist der Speicher, in dem deine App alle Einträge ablegt, etwa Konten oder Notizen.

Beim Veröffentlichen zieht die App zu einem Hosting-Dienst (kurz: Hoster) wie Vercel um, also zu einem Anbieter, der sie im Internet bereitstellt. Keiner dieser stillen Helfer kommt von allein mit. Die Fehler am Launch-Tag sind deshalb oft gar keine neuen Programmierfehler (Bugs), sondern fehlende Einstellungen. Die fünf Checks unten decken die schmerzhaftesten davon in einer sinnvollen Reihenfolge ab; die meisten dauern ein paar Minuten.

Check 1: Die Schlüssel sind beim Hoster, und Geheimes bleibt geheim

Apps nutzen Umgebungsvariablen: benannte Einstellungen, die außerhalb des Codes liegen, etwa die Adresse deiner Datenbank oder einen Schlüssel für einen Zahlungsdienst. Ein solcher Schlüssel (oft „API-Key“ genannt) funktioniert wie ein Passwort, mit dem sich deine App bei einem Dienst ausweist. Auf deinem Computer stehen diese Werte meist in einer Datei namens .env oder .env.local. Diese Datei soll nicht mit deinem Code hochgeladen werden, etwa in ein Repository auf GitHub, den Online-Speicher für Code. Also hat der Hoster sie nicht, und du trägst dieselben Werte dort noch einmal in den Projekteinstellungen ein.

Zwei Details übersehen viele. Bei Vercel gilt eine geänderte Variable erst für neue Deployments; ein Deployment ist eine Version deiner App, die auf den Hoster hochgeladen wurde. Du veröffentlichst nach einer Änderung also noch einmal. Und in Next.js, einem verbreiteten Grundgerüst (Framework) für solche Apps, wird jede Variable, deren Name mit NEXT_PUBLIC_ beginnt, in den Code geschrieben, den der Browser jedes Besuchers herunterlädt. Ein geheimer Schlüssel darf diesen Namensanfang nie tragen.

1. 1Schreib dir die Namen aller Variablen aus deiner lokalen .env-Datei auf (nur die Namen, nicht die Werte). Die Datei liegt im Hauptordner deines Projekts; findest du sie nicht, bitte dein KI-Tool, dir die Namen aufzulisten.
2. 2Öffne beim Hoster die Projekteinstellungen, bei Vercel Settings und dann Environment Variables. Prüf, ob jeder Name für Production existiert, also für die Live-Version deiner App.
3. 3Prüf, dass kein Geheimnis im Browser landet. Nutzt deine App Next.js (dein KI-Tool kann dir das sagen), darf kein geheimer Name mit NEXT_PUBLIC_ beginnen. Nutzt sie Supabase, einen verbreiteten Dienst für Datenbank und Anmeldung, findest du dort unter Settings und API Keys zwei Arten von Schlüsseln: Der Publishable Key darf öffentlich sein, der Secret Key (früher service_role) nie, denn er umgeht jede Zugriffsregel.
4. 4Veröffentliche nach jeder Änderung neu. Bei Vercel geht das im Bereich Deployments: Klick beim neuesten Deployment auf das Menü mit den drei Punkten und dann auf Redeploy.

Geheime Schlüssel bleiben auf dem Server · Aus der Faber-Wissensbasis

Check 2: Die Anmeldung kennt deine Live-Adresse

Links in E-Mails, Magic Links (Anmeldelinks ohne Passwort) und die Anmeldung über ein anderes Konto schicken Leute weg und wieder zurück. Der Anmeldedienst schickt sie aber nur zu Adressen zurück, die auf einer Erlaubnisliste stehen; diese Rücksprungadressen heißen Redirect-URLs. Supabase Auth, der Anmeldebereich von Supabase, startet mit http://localhost:3000 als Site-URL, also als Standardadresse für die Rückkehr. Ändert das niemand, klappt die Anmeldung bei dir und scheitert live.

1. 1Öffne in Supabase den Bereich Authentication und dann URL Configuration.
2. 2Setz die Site URL auf deine Live-Adresse, zum Beispiel https://deineapp.de.
3. 3Trag deine Live-Adresse unter Redirect URLs ein. Erzeugt dein Hoster Vorschau-Adressen (eigene Adressen für Testversionen), füg auch dafür ein Muster mit Platzhalter hinzu, das alle diese Adressen abdeckt.
4. 4Meld dich auf der Live-Seite in einem privaten Browserfenster (Inkognito-Fenster) an, dann ab und noch einmal an.

Prüf auch die E-Mails. Der eingebaute E-Mail-Dienst von Supabase stellt nur an Mitglieder deines Projektteams zu und ist derzeit auf 2 Nachrichten pro Stunde begrenzt. Für echte Nutzer verbindest du vor dem Launch einen eigenen E-Mail-Versanddienst über SMTP, das übliche Verfahren zum Versenden von E-Mails; die Einstellung dafür findest du in Supabase unter Authentication. Sonst kommen Registrierungs- und Passwort-Mails einfach nicht an.

Check 3: Die Live-Datenbank ist getrennt und hat Zugriffsregeln

Deine Testdaten und die Daten deiner Nutzer sollten nicht in derselben Datenbank liegen. Supabase beschreibt einen Aufbau mit getrennten Projekten für den Live-Betrieb und fürs Testen. So erwischt ein missglückter Versuch nie echte Konten.

Das größere Risiko ist, wer was lesen darf. Eine Datenbank besteht aus Tabellen, und jede Zeile darin ist ein Eintrag, etwa ein Konto oder eine Notiz. Bei Supabase spricht die App im Browser oft direkt mit der Datenbank. Row Level Security (RLS) ist das Regelwerk, das Zeile für Zeile entscheidet, wer Daten lesen oder ändern darf.

Ohne RLS kann jeder, der den öffentlichen Schlüssel aus deiner App hat, die Tabelle lesen und ändern; mit RLS erreicht dieser Schlüssel nur das, was die Regeln erlauben. Eine Regel, die nur prüft „Ist jemand angemeldet?“, reicht auch nicht: Dann sieht jeder Nutzer die Zeilen aller anderen. Die Regel muss den Besitz prüfen: Gehört diese Zeile dem Nutzer, der gerade angemeldet ist?

1. 1Prüf, ob du in Supabase zwei getrennte Projekte hast, eins zum Testen und eins für den Live-Betrieb. Lass dir von deinem KI-Tool zeigen, an welcher Umgebungsvariable beim Hoster du erkennst, dass die Live-App mit dem Live-Projekt verbunden ist.
2. 2Öffne in Supabase den SQL Editor und bitte dein KI-Tool um die kurze Abfrage, die für jede Tabelle anzeigt, ob RLS aktiviert ist. In der Spalte „rowsecurity“ muss bei jeder Tabelle „true“ stehen.
3. 3Lass dir von deinem KI-Tool alle Tabellen mit ihren Regeln auflisten und jede Regel in einem einfachen Satz erklären.
4. 4Meld dich mit einem Testkonto (Nutzer A) an und leg etwas an. Meld dich dann mit einem zweiten Testkonto (Nutzer B) an und versuch, es zu finden. B darf nichts von A sehen.

Private Daten direkt in der Datenbank absichern · Aus der Faber-Wissensbasis

Check 4: Geh den echten Ablauf auf der Live-Adresse durch

Die Version auf deinem Computer ist nicht die, die deine Besucher bekommen. Teste die veröffentlichte Seite selbst, so wie eine fremde Person – nicht die Vorschau in deinem Baukasten, also in dem Tool, in dem du die App baust.

1. 1Öffne die Live-Adresse in einem privaten Browserfenster und auf deinem Handy.
2. 2Registrier dich als ganz neuer Nutzer mit einer E-Mail-Adresse, die du noch nie verwendet hast, und bestätige sie über den Link in der E-Mail.
3. 3Erledige die eine Hauptsache, für die es deine App gibt, von Anfang bis Ende.
4. 4Mach absichtlich etwas falsch: ein Formular leer lassen, Unsinn eintippen, mittendrin abbrechen. Du solltest eine verständliche Meldung sehen, keine leere Seite.
5. 5Schau dir eine Seite ohne Daten an, zum Beispiel die leere Liste eines neuen Kontos. Sie sollte sagen, was als Nächstes zu tun ist.
6. 6Wiederhol den Hauptablauf mit einem zweiten Konto und prüf, dass keines die Daten des anderen sieht.

Check 5: Ein Weg zurück und ein Blick auf Fehler

Irgendwann geht etwas schief. Entscheidend ist, ob du es merkst und ob du es rückgängig machen kannst.

Ein Weg zurück für die App. Ein Rollback holt eine frühere Version deiner App zurück. Mit Instant Rollback von Vercel zeigt deine Domain, also die Adresse deiner App, mit wenigen Klicks wieder auf eine frühere Live-Version. Im kostenlosen Hobby-Plan kommst du zum vorherigen Deployment zurück, in Bezahlplänen zu jedem früheren. Ein Rollback tauscht den Code der App aus, nicht deine Daten und nicht deine Umgebungsvariablen.

Ein Weg zurück für deine Daten. In den Bezahlplänen von Supabase gibt es automatische tägliche Sicherungskopien (Backups). Im kostenlosen Plan nicht – dort empfiehlt Supabase, die Daten regelmäßig selbst zu exportieren. Kläre, welcher Fall auf dich zutrifft, bevor echte Nutzer kommen.

Ein Blick auf Fehler. Wenn ein Nutzer auf ein Problem stößt, siehst du seinen Bildschirm nicht. Der Bereich Logs bei Vercel zeigt, was auf dem Server passiert ist; Serverfehler sind rot markiert. Im Hobby-Plan werden die Logs eine Stunde lang aufbewahrt, schau also bald nach, wenn etwas kaputtgeht.

1. 1Such bei deinem Hoster den Rollback-Knopf und merk dir, wo er ist. Bei Vercel findest du Instant Rollback auf der Übersichtsseite deines Projekts.
2. 2Prüf in Supabase unter Database und Backups, welche Backups dein Plan enthält. Hast du keine, lass dir von deinem KI-Tool Schritt für Schritt zeigen, wie du heute eine Kopie exportierst.
3. 3Öffne bei Vercel in deinem Projekt den Bereich Logs, lös absichtlich einen harmlosen Fehler aus und finde ihn dort wieder. Wie du so einen Fehler auslöst, kann dir dein KI-Tool sagen.

Lass dein KI-Tool die Checkliste bauen – mit Belegen

Dein KI-Tool kann deinen tatsächlichen Code lesen, das kann keine allgemeine Liste. Bitte es, genau deine App zu prüfen, und besteh auf einem Beleg für jeden Punkt. Was es nicht belegen kann, bleibt offen, bis du es selbst geprüft hast.

Bevor ich diese App veröffentliche, erstell eine Checkliste für genau dieses Projekt. Ändere noch keinen Code.

Deck mindestens ab:
1. Jede Umgebungsvariable, die die App braucht, wo sie verwendet wird und ob sie geheim ist. Markiere jedes Geheimnis, das in den Browser gelangen könnte oder im Repository gespeichert ist.
2. Anmeldung: Welche Site-URL und welche Redirect-URLs brauche ich für meine Live-Adresse [deine Live-Adresse]? Prüf auch, wie Registrierungs- und Passwort-Mails verschickt werden.
3. Die Live-Datenbank: Ist sie vom Testen getrennt, hat jede Tabelle Row Level Security, und prüft jede Regel, dass die Zeile dem aktuellen Nutzer gehört?
4. Den Hauptablauf auf der Live-Adresse, inklusive der Fehlerzustände, der leeren Seiten und eines zweiten Nutzers, der die Daten des ersten nicht sehen darf.
5. Wie ich eine fehlerhafte Version zurückrolle, wie meine Daten gesichert sind und wo ich Fehler-Logs lesen kann.

Zeig für jeden Punkt einen Beleg: Datei und Zeile, die genaue Einstellung, die ich ansehen soll, oder einen Test, den ich selbst machen kann. Markiere alles, was du nicht prüfen konntest, als UNGEPRÜFT, statt zu raten.