Secrets in Replit nutzen, und was trotzdem veröffentlicht wird

Irgendwann zwischen Bauen und Veröffentlichen hat Replit dir gesagt, du sollst deinen API-Schlüssel nicht mehr in den Code schreiben. Also hast du nachgeschlagen, wie man Secrets in Replit nutzt, den Schlüssel ins Secrets-Werkzeug gelegt, und die Warnung war weg. Dann hat dir jemand gesagt, der Schlüssel sei in deiner veröffentlichten App immer noch zu sehen, und beides scheint gleichzeitig zu stimmen.

Tut es auch. Hier ist der Teil, den die meisten Ratschläge dazu auslassen: das Secrets-Werkzeug entscheidet, wo ein Wert liegt. Dein Code entscheidet, wohin er getragen wird. Das sind zwei getrennte Fragen, und nur die erste hat überhaupt etwas mit dem Werkzeug zu tun.

Auf Replit trifft das besonders hart, weil die Hälfte deiner App, die auf Replits Maschine läuft, und die Hälfte, die auf dem Laptop deines Besuchers läuft, im selben Projekt liegen, oft in benachbarten Dateien. Nichts im Editor zieht eine Linie zwischen ihnen.

Zwischen dem 12. und dem 14. August 2026 haben wir dieselben neun externen Prüfungen über 30.998 live erreichbare Apps laufen lassen, davon 3.042 auf Replit veröffentlicht. In 219 dieser Replit-Apps lag etwas Schlüsselförmiges im Code, den ein Besucher herunterlädt. Über die ganze Stichprobe hinweg ist das meiste, was diese Prüfung findet, ein Google-Schlüssel, der eingeschränkt normalerweise in Ordnung ist. Die, die nicht in Ordnung sind, sind die, die ein Secrets-Werkzeug verhindern sollte. Die vollständigen Zahlen stehen in unserem Scan-Bericht.

Wie nutze ich Secrets in Replit?

Öffne das Secrets-Werkzeug, trage einen Namen und einen Wert ein und lies den Wert in deinem Code als Umgebungsvariable aus. Das dauert etwa eine Minute.

1. Öffne in deinem Projekt Secrets. Es steht in der Werkzeugliste, und die Suche im Werkzeugbereich nach dem Wort findet es.
2. Wähle + New secret. Gib ihm einen Namen in Großbuchstaben mit Unterstrichen, etwa OPENAI_API_KEY. Diesen Namen benutzt später dein Code, er ist also wichtiger, als er aussieht.
3. Füge den Wert in das zweite Feld ein und speichere. Replit verschlüsselt ihn und hält ihn außerhalb deiner Projektdateien.
4. Lies ihn in deinem Code aus. In JavaScript ist das process.env.OPENAI_API_KEY, in Python os.getenv("OPENAI_API_KEY").
5. Geh zurück und lösche den Wert dort, wo er vorher stand.

Schritt fünf ist der, den Leute überspringen, und der, an dem hängt, ob das alles etwas gebracht hat. Ein Secret anzulegen entfernt die Kopie nicht, die du schon hattest. Ein Schlüssel, der letzte Woche in eine Datei geschrieben wurde, steht immer noch in dieser Datei, immer noch in deiner Projekthistorie und immer noch in jeder Kopie deiner App, die seitdem veröffentlicht wurde.

Eine .env-Datei macht dieselbe Arbeit wie das Secrets-Werkzeug, mit einem Unterschied, der zählt: Sie ist eine Datei und reist mit dem Projekt mit, wenn jemand es forkt oder an ein Repository anschließt.

Sind Replit Secrets sicher?

Für das, was sie tun, ja. Der Wert ist verschlüsselt, er liegt außerhalb deines Quellcodes, und die drei häufigsten Wege, auf denen einem ein Schlüssel abhandenkommt, sind damit alle zu: Du teilst dein Projekt mit jemandem, du schließt es an ein Repository an, oder jemand sieht dir beim Arbeiten zu.

Stell es dir als abgeschlossene Schublade vor. Was in der Schublade liegt, ist vor jedem verborgen, der deine Dateien liest. Was die Schublade nicht entscheiden kann, ist, was deine App mit dem Inhalt anstellt, sobald dein eigener Code sie geöffnet hat und damit losgezogen ist.

Und eine veröffentlichte Replit-App zieht mit ziemlich viel los. Jeder Besucher, der deine Seite lädt, bekommt die gesamte vordere Hälfte davon geschickt, denn ein Browser kann keine Seite zeichnen, die er nicht bekommen hat. Wenn der Code, der die Schublade öffnet, zu den Besuchern geschickt wird, reist der herausgenommene Wert mit.

Welche Hälfte deiner App liest den Schlüssel?

Die Hälfte, die auf Replits Maschine läuft, kann ein Secret gefahrlos lesen. Die Hälfte, die im Browser deines Besuchers läuft, kann es nicht, und der übliche Weg, es doch zum Laufen zu bringen, ist zugleich der Weg, auf dem der Schlüssel öffentlich wird.

Dein Server-Code ist der Teil, den Replit ausführt: eine Express-Route, ein Python-Handler, eine Funktion, die mit OpenAI oder Stripe spricht und deiner App eine Antwort zurückgibt. Sie liest ein Secret, benutzt es, und der Wert verlässt die Maschine nie.

Dein Browser-Code ist alles, was der Laptop deines Besuchers ausführt. In einem React-Projekt ist das das meiste von dem, was du bearbeitet hast. Es wird zu einem Bündel JavaScript kompiliert und vollständig von jedem heruntergeladen, der deine Seite öffnet.

process.env gibt es in einem Browser nicht, Browser-Code, der es liest, bekommt also überhaupt nichts. Damit der Wert doch ankommt, benennt ihn jemand um: VITE_OPENAI_API_KEY in einem Vite-Projekt oder NEXT_PUBLIC_OPENAI_API_KEY in einem von Next.js. Es funktioniert sofort, denn dieses Präfix ist eine Anweisung an das Build-Werkzeug, den Wert in das Bündel zu schreiben. Vites eigene Dokumentation sagt genau das und warnt aus ebendiesem Grund davor, API-Schlüssel dort abzulegen.

Die schnellste Prüfung in diesem Artikel ist deshalb eine Suche. Öffne dein Projekt und such nach VITE_ und NEXT_PUBLIC_. Jeder Treffer ist ein Wert, den dein Build-Werkzeug veröffentlichen soll.

Für manche davon ist das richtig. Ein veröffentlichbarer Supabase-Schlüssel ist dafür gebaut, in einem Browser zu sitzen, und ein Google-Maps-Schlüssel mit einer Referrer-Einschränkung auch. Falsch ist es für alles, was Geld ausgibt oder eine Datenbank liest, ohne zu fragen, wer da klopft, und die beiden auseinanderzuhalten dauert etwa eine Minute pro Schlüssel.

Wenn du lieber sehen willst, was deine veröffentlichte App herausgibt, bevor du Datei für Datei gehst: Unser kostenloser Scan liest deine Website von außen und sagt dir, was er dort finden kann. Er dauert etwa 20 Sekunden und braucht kein Konto: App scannen.

Warum funktioniert mein Replit-Secret nicht?

Zwei Gründe, und von deinem Platz aus erzeugen sie dasselbe Symptom: einen leeren Wert und eine App, die nicht läuft.

Der Code, der es liest, läuft im Browser. Dort gibt es keine Umgebung zum Auslesen, process.env.DEIN_KEY ist also leer und bleibt es. Das ist kein Konfigurationsproblem, und kein noch so häufiges Neuanlegen des Secrets bewegt daran etwas. Der Aufruf, der den Schlüssel braucht, muss in die Server-Hälfte deiner App umziehen.

Deine veröffentlichte App läuft in einer älteren Version. Replit hält zwei Sätze von Werten, die in deinem Workspace und die, mit denen deine veröffentlichte App läuft. Sie gleichen sich ab, ein neu angelegtes Secret erreicht das Deployment also normalerweise. Was die laufende App tatsächlich benutzt, ist aber das, was beim letzten Veröffentlichen da war. Legst du danach ein Secret an, weiß die laufende App nichts davon, bis du erneut veröffentlichst.

Replits eigene Fehlersuche für eine App, die im Editor läuft und veröffentlicht kaputtgeht, fängt genau an dieser Stelle an. Es lohnt sich also, die Deployment-Secrets zu öffnen und die Namen zu lesen, bevor du irgendetwas für kaputt hältst. Ein Name, der an einer Stelle OPENAI_KEY heißt und an der anderen OPENAI_API_KEY, erzeugt denselben leeren Wert wie ein fehlendes Secret.

Ein Deployment, das um Mitternacht scheitert, ist der Moment, in dem die Abkürzung genommen wird. Den Wert direkt in den Code zu schreiben löst die Blockade in Sekunden, die App ist zurück, und der Schlüssel steckt von da an in deinem veröffentlichten Bündel.

Der Schlüssel ist schon in meiner veröffentlichten App. Was jetzt?

Tausche ihn, bevor du irgendeinen Code änderst. Erzeuge im Dashboard des Anbieters einen neuen Schlüssel und ziehe den alten zurück.

Diese Reihenfolge zählt, weil nur der Tausch dafür sorgt, dass der offengelegte Wert nicht mehr funktioniert. Deinen Code zu bearbeiten entfernt ihn aus der aktuellen Version und lässt ihn in deiner Projekthistorie stehen, und gegen die Kopien deines Bündels, die längst heruntergeladen, zwischengespeichert und gecrawlt wurden, tut es überhaupt nichts. Dass deine App klein ist, hilft ebenfalls nicht: Automatische Crawler lesen öffentliche Seiten fortlaufend nach schlüsselförmigen Zeichenketten ab, ohne eine Ahnung davon, wer du bist.

Dann, in dieser Reihenfolge:

1. Leg den neuen Schlüssel in Secrets und lies ihn nur aus Server-Code.
2. Verschiebe den Aufruf, der ihn brauchte. Alles, was mit OpenAI, Anthropic, Stripe oder deiner Datenbank mit einem administrativen Schlüssel spricht, gehört hinter eine Route, die deine App aufruft, damit der Browser deinen Server fragt und dein Server den Schlüssel hält.
3. Sieh dir die Nutzungs- und Abrechnungsseiten des Anbieters für den Zeitraum an, in dem der alte Schlüssel öffentlich war. Der Tausch stoppt, was als Nächstes passiert, und sagt nichts über das, was schon passiert ist.

Schlüssel von Modellanbietern sind auf Replit die, die zuerst zu prüfen sind. OPENAI_API_KEY ist das Beispiel, zu dem Replits eigene Dokumentation greift, wenn sie dir das Anlegen eines Secrets zeigt, und von einem OpenAI- oder Anthropic-Schlüssel gibt es keine veröffentlichbare Variante. Jeder einzelne rechnet direkt über dein Konto ab.

Eine Stelle noch, wenn du schon dabei bist: Wenn dein Projekt Source Maps veröffentlicht, kann ein Besucher dieses Bündel als die Originaldateien lesen, die du geschrieben hast, mit deinen eigenen Variablennamen darauf.

Was du diese Woche tun solltest

Mach zuerst die Suche. Sie dauert eine Minute, braucht nichts Installiertes und sagt dir, welche der Schlüssel in deinem Projekt bereits öffentlich sind. Die 10-Minuten-Sicherheitscheckliste deckt den Rest ab, was bei einer frisch gestarteten App zu prüfen ist, und die Anleitung in einfacher Sprache für diese Plattform ist Ist deine Replit-App sicher.