Services & Datenbank

Welche Services gibt es?

Nutze diese Services für lokale Anwendungsdaten, abgefangene E-Mails und Datenbankverwaltung. Sie benötigen eine aktive Backend-Rolle; reine Frontend-Projekte haben diese Datenbank und Services nicht.

• MariaDB ist Teil jeder Backend-Runtime und kein optionaler Service-Schalter.
• Mailpit und phpMyAdmin sind bei neuen Backend-Projekten standardmäßig aktiviert.
• Elasticsearch und Mercure sind optionale Services und standardmäßig deaktiviert. Aktiviere sie nur, wenn deine Anwendung sie benötigt.

MariaDB

Die Anwendung im Stack erreicht die Datenbank unter mariadb:3306.

Mailpit

Fängt lokale E-Mails ab. Die Browser-Inbox liegt beispielsweise unter http://tools.mein-projekt.localhost/mp/; SMTP im Stack ist mailpit:1025.

phpMyAdmin

Browser-Zugang zur Datenbank, beispielsweise unter http://tools.mein-projekt.localhost/pma/. Melde dich mit den von access phpmyadmin ausgegebenen Projektzugangsdaten an.

Elasticsearch

Optionaler interner Suchdienst unter elasticsearch:9200.

Mercure

Optionaler Hub unter /.well-known/mercure auf Projekt-Hosts der Backend-Runtime. Die Anwendung verwaltet die Publikations-Tokens; anonyme Subscriptions sind im lokalen Container erlaubt.

Services verwalten

Arbeite im Projektordner. services list zeigt die konfigurierten optionalen Services, keine Prüfung ihrer Erreichbarkeit. Wenn Mailpit deaktiviert wurde, kannst du es gezielt wieder aktivieren:

dwell services list

dwell services enable mailpit
dwell up

Zum Deaktivieren funktioniert entsprechend dwell services disable mailpit. Änderungen synchronisieren den lokalen Zustand und können laufende Services neu starten. up startet ein zuvor gestopptes Projekt.

Zugänge verwenden

Starte die Umgebung mit dwell up. Die folgenden Abfragen zeigen die konfigurierten Zugänge; verwende die tatsächlich ausgegebene URL inklusive eines möglichen Gateway-Ports.

dwell access db

dwell access phpmyadmin

dwell access mailpit

Die allgemeine Übersicht dwell access blendet Passwörter aus. Die expliziten Abfragen für db und phpmyadmin zeigen Benutzer und Passwort des Projekts; behandle die Ausgabe vertraulich, auch bei JSON. Das MariaDB-Root-Passwort wird nicht ausgegeben. Deaktivierte Tools haben keinen nutzbaren Access-Eintrag.

mariadb ist ein interner Stack-Host. Dwell veröffentlicht keinen Datenbank-Port auf deinem Rechner; die Zugangsdaten funktionieren deshalb nicht automatisch in einem Desktop-Client unter localhost:3306. Für den normalen Browser-Zugang nutze phpMyAdmin. Access prüft nicht, ob der Service läuft.

Daten exportieren und importieren

Export speichert die aktuelle Projektdatenbank in einer SQL-Datei. Wähle für jede Sicherung einen neuen Dateinamen: db export überschreibt vorhandene Dateien nicht. Das folgende Beispiel schreibt relativ zum Projektordner.

dwell db export backups/vor-update.sql

Ohne Dateiangabe schreibt dwell db export nach .dwell/backups/[data-namespace]-db.sql. Die CLI nennt den konkreten Zielpfad. Für wiederholte Sicherungen nutze neue Export-Dateinamen oder benannte Snapshots.

Import ersetzt die aktuelle Projektdatenbank durch eine SQL-Datei. Prüfe Quelle und Inhalt und sichere wichtige Daten, bevor du bestätigst. Das Beispiel verwendet die zuvor exportierte Datei:

dwell db import backups/vor-update.sql

Dwell verlangt eine Bestätigung und erstellt zuerst einen Safety-Snapshot. Bei einem Fehler versucht es, den vorherigen Datenstand daraus wiederherzustellen. Lies das Ergebnis; wenn die Wiederherstellung fehlschlägt, bewahre den gemeldeten Snapshot für die manuelle Rettung auf. Ein Safety-Snapshot ist kein Ersatz für eine separate Sicherung.

Vor Änderungen einen Snapshot anlegen

Ein Snapshot ist ein benannter SQL-Sicherungsstand in .dwell/backups/. Lege ihn vor einem Update oder einer riskanten Datenänderung an. Verwende für weitere Stände neue Namen; doppelte Namen werden abgelehnt.

dwell db snapshot vor-update

Wenn du später zu diesem Stand zurückkehren möchtest, nutze restore. Es ersetzt die aktuelle Projektdatenbank nach Bestätigung und legt vorher ebenfalls einen Safety-Snapshot an.

dwell db restore vor-update

Bewahre Dwell-Sicherungen mit ihren Begleitdateien und den zugehörigen persistenten Projektzustand auf. Veränderte oder unvollständige Sicherungen können abgelehnt werden; die exakten Integritäts- und Restore-Regeln stehen in der technischen Referenz.

Persistenz, Runtime und Backup

down stoppt die Umgebung, ohne Projektdateien oder persistente Docker-Volumes zu löschen. Datenbankdaten liegen im Volume; erfasste Mailpit-Nachrichten bleiben im persistenten Projektzustand erhalten.

Persistente Daten

Datenbank-Volumes, lokale Secrets, Mailpit-Dateien und Sicherungen müssen bewusst erhalten und bei Bedarf separat gesichert werden.

Runtime

.dwell/runtime/ enthält erzeugte Dateien, Prozesszustand und Logs. Sie wird erneuert und ist keine Datensicherung.

Backup

SQL-Exporte und Snapshots sichern Datenbankinhalte. Sie ersetzen kein Backup deiner Projektdateien, Uploads oder sämtlicher anderer Service-Daten. Bewahre wichtige Sicherungen auch außerhalb des Projektordners auf.

Hinweise & Grenzen

Datenbank-Commands brauchen Docker und eine funktionierende Backend-Runtime. Sie können eine gestoppte MariaDB vorübergehend starten und stoppen sie danach wieder, wenn sie dafür gestartet wurde. Importiere SQL nur aus vertrauenswürdigen Quellen. Die Abfrage von Zugangsdaten erzeugt oder repariert keine Secrets; bei fehlenden Zugangsdaten stelle die ursprünglichen Secrets wieder her. Das Löschen von Datenbank-Volumes löscht die darin enthaltene Datenbank.

Als Nächstes

Prüfe im Routing-Guide, wo Anwendungen und Tools erreichbar sind. Der Projekte-Guide erklärt Start, Status und Stopp der Umgebung.

Technische Referenz