„Warum sind meine Testdaten schon wieder weg? Ich hab doch nur den Dev-Server neu gestartet!“ Diese Frage hören wir in Consulting-Projekten regelmäßig, wenn Teams mit Astro DB arbeiten. Das Standardverhalten ist beabsichtigt: Bei jedem astro dev wird die lokale Datenbank zurückgesetzt und neu geseeded. Für manche Workflows ist das praktisch – für andere ein echtes Produktivitätskiller. Nach über 15 Jahren Erfahrung in Softwarequalität, Open Source und Remote Consulting zeigen wir euch, wie ihr mit dem --remote Flag und alternativen Strategien eure Entwicklungsdaten dauerhaft behaltet.
Das Kernproblem: Lokale Datenbank wird bei jedem Neustart gelöscht
Astro DB nutzt standardmäßig eine lokale SQLite-basierte Datenbank unter .astro/content.db. Bei jedem Start des Development-Servers passiert folgendes: Die Datenbank wird komplett neu erstellt, das Schema aus db/config.ts wird angewendet und die Seed-Daten aus db/seed.ts werden eingefügt. Das ist gewollt – ihr bekommt reproduzierbare, saubere Entwicklungsumgebungen ohne manuelle Resets.
Das Problem entsteht, wenn ihr während der Entwicklung Testdaten manuell anlegt oder komplexe Szenarien testet. Ein Neustart vernichtet alles. Besonders frustrierend bei längeren Debug-Sessions oder wenn ihr mit realistischen Datensätzen arbeiten müsst.
1. Was macht das –remote Flag bei astro dev genau?
Das --remote Flag verbindet euren lokalen Development-Server direkt mit einer entfernten libSQL-Datenbank statt mit der lokalen Entwicklungsdatenbank. Alle Lese- und Schreiboperationen gehen dann gegen die Remote-Datenbank.
npx astro dev --remoteDie Verbindung benötigt zwei Environment-Variablen:
ASTRO_DB_REMOTE_URL=libsql://euer-db-name.turso.io
ASTRO_DB_APP_TOKEN=euer-auth-tokenWichtig: Änderungen sind sofort persistent. Es gibt keinen Rollback-Mechanismus. Wenn ihr versehentlich Produktionsdaten löscht, sind sie weg.
2. Welche Alternativen gibt es zu Astro Studio nach dem Shutdown?
Astro Studio wurde im September 2024 offiziell eingestellt. Die gute Nachricht: Astro DB funktioniert jetzt mit jeder libSQL-kompatiblen Datenbank. Eure Optionen sind vielfältig und bieten sogar mehr Flexibilität als zuvor.
Turso (empfohlen): Das Unternehmen hinter libSQL bietet einen managed Service mit großzügigem Free Tier. Die Migration von Astro Studio ist straightforward, da beide auf der gleichen Technologie basieren.
Self-Hosted libSQL: Ihr könnt sqld (den libSQL Server) selbst hosten – auf einem VPS, in Docker oder in eurer bestehenden Infrastruktur. Volle Datenkontrolle, keine Abhängigkeit von externen Diensten.
Lokale libSQL-Datei: Für Entwicklung ohne Netzwerk könnt ihr eine persistente lokale Datei nutzen:
ASTRO_DB_REMOTE_URL=file:./data/persistent.db3. Wie richte ich Turso als Astro DB Backend ein?
Die Einrichtung dauert keine fünf Minuten. Installiert zuerst die Turso CLI und erstellt eine Datenbank:
# Turso CLI installieren
curl -sSfL https://get.tur.so/install.sh | bash
# Login (GitHub OAuth)
turso auth login
# Neue Datenbank erstellen
turso db create mein-astro-projekt
# Connection URL abrufen
turso db show mein-astro-projekt --url
# Auth Token generieren
turso db tokens create mein-astro-projektTragt die Werte in eure .env ein und pushed das Schema:
npx astro db push --remoteAb jetzt könnt ihr npx astro dev --remote nutzen und eure Daten bleiben erhalten – auch nach Server-Neustarts.
4. Kann ich libSQL selbst hosten ohne externe Dienste?
Absolut. Für Teams mit strikten Compliance-Anforderungen oder voller Datenkontrolle ist Self-Hosting die beste Wahl. Der sqld-Server läuft problemlos in Docker:
# docker-compose.yml
services:
libsql:
image: ghcr.io/tursodatabase/libsql-server:latest
ports:
- "8080:8080"
volumes:
- ./data:/var/lib/sqld
environment:
- SQLD_NODE=primaryStartet den Container und konfiguriert Astro DB:
ASTRO_DB_REMOTE_URL=http://localhost:8080Für Produktionsumgebungen empfehlen wir JWT-basierte Authentifizierung. Die Turso-Dokumentation bietet ausführliche Anleitungen zur Token-Generierung und Absicherung.
5. Warum werden meine Daten bei astro build ebenfalls gelöscht?
Das ist ein häufiges Missverständnis. Sowohl astro dev als auch astro build erstellen standardmäßig eine frische lokale Datenbank. Das Verhalten ist identisch – und beabsichtigt.
Für Production Builds mit persistenten Daten müsst ihr ebenfalls das --remote Flag nutzen:
{
"scripts": {
"dev": "astro dev",
"dev:remote": "astro dev --remote",
"build": "astro build --remote",
"build:local": "astro build"
}
}Ein GitHub Issue (#13115) diskutiert aktuell Möglichkeiten für persistente lokale Datenbanken ohne Remote-Verbindung. Bis dahin bleibt --remote die sauberste Lösung.
6. Wie sichere ich meine Remote-Datenbank vor versehentlichen Änderungen?
Vorsicht ist geboten: --remote in Development bedeutet, dass ihr gegen echte Daten arbeitet. Hier unsere bewährten Strategien aus der Praxis:
Separate Entwicklungsdatenbank: Legt für jeden Entwickler oder jede Umgebung eine eigene Datenbank an. In Turso kostet das nichts extra im Free Tier.
turso db create projekt-dev-roland
turso db create projekt-dev-team
turso db create projekt-staging
turso db create projekt-productionEnvironment-spezifische Konfiguration: Nutzt unterschiedliche .env-Dateien:
# Entwicklung mit lokaler DB
npx astro dev
# Entwicklung mit persönlicher Remote-DB
npx dotenv -e .env.dev -- astro dev --remote
# Staging
npx dotenv -e .env.staging -- astro build --remoteRegelmäßige Backups: Turso bietet Point-in-Time Recovery. Für Self-Hosted-Setups: Kopiert regelmäßig die SQLite-Datei.
7. Was passiert mit meinem Schema wenn ich –remote nutze?
Das Schema wird aus eurer db/config.ts generiert. Bei Änderungen müsst ihr diese explizit zur Remote-Datenbank pushen:
npx astro db push --remoteAstro DB prüft automatisch auf Breaking Changes. Wenn ihr Spalten entfernt oder Typen ändert, die nicht migrierbar sind, erhaltet ihr eine Warnung. Für Entwicklungsumgebungen könnt ihr mit --force-reset einen kompletten Reset erzwingen:
npx astro db push --remote --force-resetAchtung: Alle Daten in der Remote-Datenbank werden gelöscht. Nutzt das nur für Dev/Test-Umgebungen.
8. Wie migriere ich bestehende Daten zu einer neuen Remote-Datenbank?
Astro DB bietet keine eingebaute Migrationsfunktion für Daten. Hier der praktische Workaround:
Option 1: Seed-File erweitern
Exportiert eure Daten und fügt sie der db/seed.ts hinzu:
// db/seed.ts
import { db, Users, Posts } from 'astro:db';
export default async function seed() {
await db.insert(Users).values([
{ id: 1, name: 'Admin', email: 'admin@example.com' },
// Weitere exportierte Daten
]);
}Option 2: SQL-Export/Import
Nutzt die Astro DB Shell für direkten SQL-Zugriff:
# Daten exportieren (von alter DB)
npx astro db shell --query "SELECT * FROM Users" --remote > users_backup.json
# Schema zur neuen DB pushen
ASTRO_DB_REMOTE_URL=neue-url npx astro db push --remote
# Daten importieren via Execute-Script
npx astro db execute ./scripts/import-data.ts --remote9. Welche Performance-Unterschiede gibt es zwischen lokal und remote?
Die lokale Entwicklungsdatenbank ist naturgemäß schneller – keine Netzwerklatenz, kein HTTP-Overhead. Bei typischen Development-Workloads mit wenigen Queries pro Seitenaufruf ist der Unterschied aber vernachlässigbar.
Turso-Datenbanken in europäischen Regionen liefern Latenzen unter 50ms. Für kritische Performance-Tests empfehlen wir trotzdem lokale Datenbanken oder Embedded Replicas – ein Feature, bei dem eine lokale Kopie der Remote-Datenbank automatisch synchronisiert wird.
// Embedded Replica Konfiguration
import { createClient } from '@libsql/client';
const client = createClient({
url: 'file:local-replica.db',
syncUrl: process.env.ASTRO_DB_REMOTE_URL,
authToken: process.env.ASTRO_DB_APP_TOKEN,
});10. Wie kombiniere ich –remote mit CI/CD Pipelines?
Für automatisierte Deployments ist die Trennung von Umgebungen essenziell. Hier ein bewährtes Setup für GitHub Actions:
# .github/workflows/deploy.yml
name: Deploy
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Node
uses: actions/setup-node@v4
with:
node-version: 20
- name: Install Dependencies
run: npm ci
- name: Push DB Schema
run: npx astro db push --remote
env:
ASTRO_DB_REMOTE_URL: ${{ secrets.PROD_DB_URL }}
ASTRO_DB_APP_TOKEN: ${{ secrets.PROD_DB_TOKEN }}
- name: Build
run: npm run build -- --remote
env:
ASTRO_DB_REMOTE_URL: ${{ secrets.PROD_DB_URL }}
ASTRO_DB_APP_TOKEN: ${{ secrets.PROD_DB_TOKEN }}Speichert die Credentials als GitHub Secrets. Für Preview Deployments könnt ihr dynamisch neue Datenbanken erstellen oder einen Pool von Test-Datenbanken rotieren.
Best Practices aus der Consulting-Praxis
Bei Never Code Alone setzen wir Astro DB in verschiedenen Kundenprojekten ein. Diese Patterns haben sich bewährt:
Drei-Umgebungen-Strategie: Lokale Entwicklung ohne --remote für schnelles Prototyping, persönliche Remote-DB für Feature-Development, Shared Staging-DB für Integration-Tests.
Schema-Versionierung: Führt ein Changelog für Schema-Änderungen. Astro DB hat keine automatischen Migrations-Files – dokumentiert Breaking Changes manuell.
Seed-Daten pflegen: Investiert Zeit in realistische Seed-Daten. Sie sind euer Sicherheitsnetz und ermöglichen reproduzierbare Tests ohne Remote-Abhängigkeit.
Monitoring einrichten: Turso bietet Usage-Metriken im Dashboard. Für Self-Hosted: Integriert SQLite-Monitoring in euer bestehendes Observability-Setup.
Direkte Unterstützung für euer Team
Ihr plant eine Astro-Anwendung mit Datenbankanbindung oder migriert von einem anderen System? Mit über 15 Jahren Expertise in Softwarequalität, Open Source und Remote Consulting helfen wir euch gerne weiter.
Kontakt: roland@nevercodealone.de
Gemeinsam finden wir die passende Architektur – ob Turso, Self-Hosted libSQL oder hybride Setups. Keine theoretischen Frameworks, sondern praktische Lösungen, die im Alltag funktionieren.
Fazit: Persistente Entwicklungsdaten mit dem richtigen Setup
Das --remote Flag löst das Grundproblem der flüchtigen lokalen Datenbank elegant. Mit Turso oder Self-Hosted libSQL habt ihr vollständige Kontrolle über eure Daten – ohne Vendor Lock-in und mit der Flexibilität, jederzeit den Provider zu wechseln.
Startet mit einer kostenlosen Turso-Datenbank für eure Entwicklungsumgebung. Die Einrichtung dauert keine zehn Minuten und spart euch Stunden an verlorener Arbeit durch versehentliche Datenbank-Resets.
Never Code Alone – Gemeinsam für bessere Software-Qualität!
