Anleitung: Testumgebung für Claude Code

Unter meinem letzten YouTube-Video hat jemand kommentiert und gefragt, wie man eigentlich Änderungen an einer App macht, die bereits live ist.

Gute Frage – und ein Punkt, den gerade viele nicht auf dem Schirm haben, die nicht ursprünglich aus der Softwareentwicklung kommen.

Das Problem: Du arbeitest am offenen Herzen

Die meisten bauen ihre App mit Claude Code oder einem ähnlichen Tool, launchen das Ganze – und arbeiten danach eigentlich immer nur noch in der Live-Umgebung weiter.

Das Problem daran: Eine einzige Änderung kann dir die komplette Plattform lahmlegen. Und dann sitzen deine echten Nutzer vor einer kaputten App.

Solange du allein an einem Prototyp baust, ist das egal. Sobald echte Menschen deine App benutzen, wird aus jeder Änderung ein Risiko.

Was du stattdessen willst: zwei getrennte Welten

Was du brauchst, ist eine lokale Development-Umgebung, die komplett getrennt ist von deiner Produktiv-Umgebung. Also ein Ort auf deinem eigenen Rechner, wo du alles ausprobieren und auch mal kaputt machen kannst, ohne dass es irgendjemanden interessiert.

	Lokal (Development)	Live (Produktion)
Wer nutzt es	nur du	deine Nutzer
Daten	Testdaten	echte Daten
Wenn etwas kaputtgeht	egal, neu aufsetzen	Ausfall für alle
Wer darf ändern	du und Claude Code	nur geprüfte Änderungen

Erst wenn eine Änderung bei dir lokal sauber läuft und getestet ist, bringst du sie in deine Live-Umgebung.

Was ist Docker eigentlich?

Deine App besteht meist aus zwei Teilen: dem Frontend, also dem, was deine Nutzer sehen, und dem Backend mit der Datenbank, in der die Daten liegen. Das Frontend läuft ohnehin schon auf deinem Rechner, während du entwickelst. Was fehlt, ist eine Datenbank – und genau dafür brauchst du Docker.

Ursprünglich wurde Docker für Entwicklerteams gebaut, damit alle mit exakt derselben Version einer Software arbeiten.

Du holst dir in wenigen Minuten eine echte Datenbank auf deinen Rechner, ohne sie umständlich zu installieren. Und wenn du sie zerschießt, wirfst du den Container weg und startest einen neuen.

Du musst Docker nicht verstehen. Du musst es einmal installieren – den Rest übernimmt Claude Code.

Schritt für Schritt

1. Docker Desktop installieren

Das ist der einzige Schritt, den du selbst machst. Lade dir Docker Desktop herunter, installiere es und starte das Programm einmal. Es muss im Hintergrund laufen, sonst funktioniert der nächste Schritt nicht.

2. Claude Code den Rest einrichten lassen

Jetzt öffnest du dein Projekt in Claude Code und beschreibst, was du brauchst. Zwei Varianten, je nachdem, was deine App live nutzt.

Variante A: einfache Postgres-Datenbank

Bitte richte mir für dieses Projekt eine lokale Entwicklungsumgebung ein:
eine Postgres-Datenbank in Docker, verbunden mit meinem Projekt.
Die Zugangsdaten kommen in .env.local, die nicht ins Repository gehört.

Variante B: Supabase lokal (meine Empfehlung)

Wenn deine App live mit Supabase arbeitet, solltest du Supabase auch lokal nutzen. Dann sind beide Welten gleich aufgebaut, und du testest wirklich das, was später live geht.

Bitte richte mir Supabase lokal über die Supabase CLI ein und verbinde
mein Projekt mit der lokalen Instanz. Die lokalen Zugangsdaten kommen
in .env.local, die nicht ins Repository gehört.

Claude Code installiert daraufhin die nötigen Werkzeuge, startet die Datenbank in Docker und trägt die Zugangsdaten in deinem Projekt ein. Bei Supabase laufen im Hintergrund im Wesentlichen zwei Befehle: supabase init legt die Konfiguration an, supabase start startet die komplette Umgebung – Datenbank, Authentifizierung, Storage und eine Oberfläche zum Reinschauen. Beenden kannst du das Ganze jederzeit mit supabase stop.

Du musst diese Befehle nicht auswendig können. Es hilft aber zu wissen, was da passiert, damit du erkennst, ob es funktioniert hat.

3. Prüfen, was eingerichtet wurde

Diesen Schritt solltest du nicht überspringen, auch wenn Claude Code die Arbeit gemacht hat. Kontrolliere zwei Dinge:

Läuft die Datenbank wirklich lokal? In deiner Konfigurationsdatei muss die Adresse auf localhost zeigen – also auf deinen eigenen Computer:

# .env.local – bleibt auf deinem Rechner
DATABASE_URL="postgresql://postgres:postgres@localhost:5432/postgres"
APP_ENV="development"

Ist die Datei vom Repository ausgeschlossen? Die Datei .env.local muss in deiner .gitignore stehen, damit sie nicht versehentlich veröffentlicht wird.

Und unabhängig davon, wer das Setup gemacht hat: Die Zugangsdaten deiner Live-Datenbank haben auf deinem Rechner nichts zu suchen. Nicht in einer Datei, nicht in einem Chatfenster, nirgends.

Warum Supabase und Claude Code besonders gut zusammenpassen

Supabase hat ein Kommandozeilen-Werkzeug, die sogenannte CLI. Und genau damit kann Claude Code direkt arbeiten.

Das heißt: Du beschreibst, welche Tabellen und Felder du brauchst, und Claude Code setzt die Datenbank lokal auf, legt Tabellen an, schreibt die passenden Migrationen und kann die Datenbank auf Zuruf komplett zurücksetzen. Alles auf deinem Rechner, alles mit Testdaten.

Der entscheidende Punkt dabei ist nicht die Bequemlichkeit, sondern die Sicherheit:

Alles, was ein Agent ohne deine Prüfung anfassen kann, darf keine echten Nutzerdaten enthalten.

Wenn Claude Code beim Umbauen einer Tabelle etwas zerlegt, verlierst du lokal ein paar Testdatensätze. Passiert dasselbe live, verlierst du die Daten deiner Nutzer.

Erst testen, dann live schalten

Der Ablauf sieht ab jetzt so aus:

1. Du baust die Änderung lokal mit Claude Code.
2. Du klickst sie selbst durch und prüfst, ob wirklich alles funktioniert – auch die Funktionen, die du gar nicht angefasst hast.
3. Erst dann bringst du die Änderung live.

Sobald andere Menschen für dich mittesten, lohnt sich eine dritte Umgebung: Staging. Das ist eine Vorschau-Version deiner App im Internet, die genauso aufgebaut ist wie die Live-Version, aber niemanden stört. Für den Anfang reicht die Trennung von lokal und live völlig aus.

Häufige Fehler

• Produktive Zugangsdaten liegen lokal herum, damit „schnell mal etwas geprüft" werden kann.
• Docker Desktop läuft nicht, und die Befehle brechen mit einer Fehlermeldung ab.
• Lokal wird mit einer anderen Datenbank gearbeitet als live – dann sagt dein Test wenig aus.
• Nach der Änderung wird nur die neue Funktion geprüft, nicht der Rest der App.

Kurz zusammengefasst

Eine lokale Testumgebung kostet dich einmalig eine halbe Stunde Einrichtung. Sie erspart dir den Moment, in dem eine unbedachte Änderung deine App für alle echten Nutzer lahmlegt. Installiere Docker, hol dir deine Datenbank lokal auf den Rechner, halte die Zugangsdaten getrennt – und lass Claude Code ab jetzt dort arbeiten, wo nichts kaputtgehen kann.