just.locker

01

Einbindung über SSH

Bindet eine neue Maschine eines beliebigen Anbieters über SSH ein.

02

Ein eigener Schlüssel

Erzeugt und installiert einen eigenen ed25519-Schlüssel und deaktiviert die Passwortanmeldung.

03

Von Anfang an abgesichert

Sichert den Server mit ufw, fail2ban, unattended-upgrades und Docker ab.

04

Zugangsdaten im Tresor

Alle bei der Einbindung erzeugten Zugangsdaten landen im Tresor.

01

Quellen

Ein Git-Repository oder ein vorhandenes OCI-Image verknüpfen. Builds über Dockerfile, Compose, Railpack, Nixpacks oder das statische Verfahren.

02

Automatisches Deployment nach einem Push

Über HMAC-geprüfte Webhooks, mit Git-Polling als Ersatz, wenn ein Webhook die Steuerungsebene nicht erreicht.

03

Container betreiben

Live-Buildprotokolle, Rollback mit einem Klick, Start, Stopp und Neustart von Containern, Protokolle und Befehlsausführung sowie ein interaktives Terminal.

04

Unabhängige Builds

Builds laufen unabhängig und überstehen deshalb einen API-Neustart. Der Worker verbindet sich anschließend wieder mit dem laufenden Build.

01

Eingehender Zugriff

Traefik pro Domain mit Let’s Encrypt oder Cloudflare Tunnel.

Das verwaltete Traefik wird über einen festen Digest referenziert und verwendet einen gefilterten Docker-API-Proxy mit Lesezugriff statt des direkten Sockets.

02

VPN

Mandantenfähiges WireGuard mit standardmäßiger Verweigerung je Benutzer, Projektrolle und Ressource sowie privaten Anwendungs-VIPs.

Ein hybrider Modus kombiniert öffentlichen eingehenden Zugriff mit reinem VPN-Zugriff.

01

Was gesichert wird

Geplante, mit age verschlüsselte Backups von Docker-Volumes und logischen Datenbank-Exports mit einem deterministischen, authentifizierten Manifest.

02

Speicherziel

Eine eingebundene Storage Box oder S3-kompatibler Speicher. Zugangsdaten bleiben auf den Tresor beschränkt; nur verschlüsselte Pakete verlassen den Server.

03

Server ersetzen

Stellt Datenbanken und Volumes wieder her und deployt anschließend das gespeicherte unveränderliche Release.

01

Ihre eigene Buchführung

Kunden, wiederkehrende Leistungen und Rechnungen mit einer Übersicht des monatlich wiederkehrenden Umsatzes (MRR).

02

Ihre deployten Projekte

SaaS-Abrechnung mit anbieterunabhängigen Produkten und Preisen, gehosteter Zahlungsabwicklung, Abonnements, Erstattungen und Zugriffsrechten über Stripe Connect oder Paddle.

01

Selbstaktualisierung

ECDSA-signiert und über Digest festgelegt, nach Vorabprüfungen, einem Datenbank-Backup und einer Zustandsprüfung, mit automatischem Rollback.

02

Wechsel von Coolify

Eine Migration in zwei Phasen vereinheitlicht eine vorhandene Coolify-Installation und führt danach die Umstellung durch.

Grenze 01

Nur neue Projekte

Produktionsbetrieb mit kritischen Daten erfordert einen repräsentativen Canary-Test mit Beobachtungsphase, vereinbarte RPO und RTO sowie regelmäßige Wiederherstellungstests.

Grenze 02

Keine Builds aus Quellcode

Builds aus Quellcode werden erst zugelassen, wenn ein kurzlebiger Builder ohne Root-Rechte existiert. Images werden deshalb bereits fertig gebaut bereitgestellt.