Inventar selbst hosten: Komponenten und Betriebsaufgaben
Next.js, PostgreSQL und Upload-Speicher lassen sich selbst betreiben. Dafür müssen Backups, TLS, Updates und externe Datenpfade sauber konfiguriert werden.
Open Inventory
Technische Notizen · MIT-lizenziert
Kurz zusammengefasst
- Anwendung und PostgreSQL laufen im Docker-Compose-Stack
- Uploads können lokal oder über Openinary gespeichert werden
- Backup, Restore-Test, TLS, Monitoring und Updates bleiben eigene Aufgaben
Echte App-Aufnahme
API-Zugriff in der selbst gehosteten Instanz
Begriffe klären
Welche Komponenten selbst laufen
Der eingecheckte Compose-Stack startet PostgreSQL, führt Migrationen aus und startet die Next.js-Anwendung. Persistente Volumes halten Datenbank und lokale Uploads außerhalb des Container-Dateisystems.
Der Upload-Pfad ist konfigurierbar. Mit lokalem Storage bleiben Medien auf dem eigenen Volume. Mit Openinary werden Dateien an dessen Upload-API gesendet. Self-Hosting der Anwendung bedeutet also nicht automatisch, dass jeder Blob lokal bleibt.
Fotos, Werte, Standorte und Zuweisungen sind Betriebsdaten. Du musst festlegen, wer den Host erreicht, wie TLS terminiert wird, wo Backups liegen und wie Restore-Tests dokumentiert werden.
Open Source unter MIT
MIT-Lizenz, Quellcode und API
Open Inventory steht unter der MIT-Lizenz. Server, Web-Client, Datenbankschema und iOS-App liegen im selben offenen Repository und können geprüft, verändert und intern verteilt werden, solange die Lizenzbedingungen eingehalten werden.
Offener Code ist kein Sicherheitsaudit. Er macht aber Berechtigungsprüfungen, Datenflüsse und Migrationen nachvollziehbar. Issues und Pull Requests sind öffentlich und technische Änderungen müssen nicht aus einer Produktbeschreibung abgeleitet werden.
Die REST-Endpunkte sind in public/openapi.yaml dokumentiert. CSV deckt Kernfelder des Inventars ab, ist aber kein vollständiges Backup aller Medien, Nutzer und Workspace-Daten. Für Wiederherstellung brauchst du Datenbank und Upload-Speicher.
Praktischer Start
Lokaler Start mit Docker Compose
- 01
Host und persistente Volumes vorbereiten
Du brauchst Docker, ausreichend Speicher, eine Domain oder interne Adresse und ein Backup-Ziel für PostgreSQL und Uploads.
- 02
Repository und
.envvorbereitenKlone das MIT-lizenzierte Repository, kopiere
.env.exampleund setze eigene Secrets, Hostnamen und Storage-Konfiguration. - 03
Migrationen und Anwendung starten
Der eingecheckte Stack startet PostgreSQL, führt die gebündelten Migrationen aus und startet anschließend die Next.js-Anwendung mit persistenten Volumes.
- 04
TLS und Rollen testen
Veröffentliche die Anwendung nicht ungeschützt. Teste Anmeldung, Rollen und einen Restore, bevor echte Daten importiert werden.
- 05
Mit Testdaten prüfen
Prüfe Import, Bilder, Bestandsbewegungen und Etikettendruck zuerst in einem kleinen Workspace.
Betrieb
Backups, Updates, TLS und Monitoring
- Backups: PostgreSQL und Uploads gemeinsam sichern; einen Restore regelmäßig auf einem getrennten Ziel testen.
- Updates: Diff und Migrationen lesen; neue Images zuerst gegen eine Kopie der Datenbank starten.
- TLS und Secrets: öffentliche Hosts nur über HTTPS betreiben; Secrets nicht in Compose-Dateien oder Images einchecken.
- Monitoring: freien Speicher, Datenbank, HTTP-Fehler und externe Bildverarbeitung beobachten.
Gute Passung
Wann Self-Hosting sinnvoll ist
Self-Hosting passt, wenn bereits Docker-Anwendungen betrieben werden, interne API-Integrationen nötig sind oder Datenflüsse selbst dokumentiert werden müssen. Ein kleiner Heimserver reicht für einen Test; produktiver Betrieb braucht trotzdem Backups und Updates.
Wenn niemand Restore, TLS und Aktualisierungen übernimmt, ist der eigene Betrieb keine technische Abkürzung. Die MIT-Lizenz erlaubt Anpassungen, übernimmt aber keinen Betrieb für dich.
Weiterführend