Objektspeicher, derseine Rechnung offenlegt.
Lockwell ist ein privater, verschlüsselter Objektspeicher mit S3-kompatibler API, nativer JSON-API und offiziellen SDKs für Go, Node und Java: ein Binary, keine zweite Datenbank, kein Klebstoff. Die Aussagen auf dieser Seite sind Messungen, und das Repository liefert die Werkzeuge, um sie zu wiederholen.
- Crash-Übernahme, bestätigte Schreibvorgänge intakt
- 16 s
- Plattenplatz für dieselben Bytes, vs. MinIO
- 0.54x
- Multipart-PUT, 64 MiB mit 64 Clients
- 2.2x MinIO
- S3-Produktionssuite, 24 SDK-Clients
- 0 Fehler
- öffentliche Buckets, anonyme Lesezugriffe
- verweigert
gemessen am 2026-06-11 · ein Host, Docker Compose · Methodik · reproduzieren: make bench · make prod-authority-test
Jede Anfrage trifft auf das Tor
Das ist das gesamte Sicherheitsmodell in einer Szene. Eine Anfrage mit Tenant-Schlüssel passiert, und ihr Objekt liegt versiegelt und verschlüsselt im Speicher. Eine Anfrage ohne Schlüssel wird mit 401 abgewiesen. Es gibt keinen anonymen Pfad, den man sorgfältig konfigurieren müsste: es gibt ihn nicht.
carries a tenant key: passes, sealed at rest ohne Schlüssel: am Tor abgewiesen, 401
Teilen funktioniert weiterhin, auf dem sicheren Weg: ein signierter Link mit Ablaufzeit (ein 7-Tage-Download für Kunden, ein einstündiger Browser-Upload) wird erzeugt und weitergegeben. Der Link trägt die Berechtigung, niemand erhält Schlüssel, und er läuft planmäßig ab.
Das Argument, ein funktionierendes MinIO zu ersetzen
Benchmarks bewegen kein Produktionssystem; niedrigere Rechnungen, weniger bewegliche Teile und ein sicherer Ausstieg schon. Das ändert sich am Tag des Wechsels, und so prüft man es ehrlich, ohne etwas zu riskieren.
Dieselben Bytes, etwa der halbe Plattenplatz
Gemessen: 0,54x des MinIO-Speicherbedarfs für eine identische Schreibmenge, noch bevor Deduplizierung auf echten Daten greift. Speicher ist der Posten, der ewig wächst; das halbiert seine Steigung.
Multi-Tenancy, die man nicht bauen muss
Isolation pro Kunde, Schlüssel mit Geltungsbereich, Quoten und ein Audit-Log sind hier Aufgabe des Servers, keine Auth-Schicht, die das Team um einen Bucket herum schreibt und jahrelang pflegt.
Compliance inklusive
Stets aktive Verschlüsselung im Ruhezustand, Object-Lock-Aufbewahrung und Legal Hold, Audit-Protokoll, Prüfung und Reparatur, geprobte Backup-Restore-Übungen. Der Nachweis, den der Auditor verlangt, ist die normale Ausgabe des Produkts.
Ein Binary im Betrieb
Keine externe Datenbank, kein Broker, kein Cache. Updates ersetzen ein Binary; Wiederherstellung ist eine Übung, die in CI läuft, keine ungetestete Wiki-Seite.
Der Ausstieg ist Standard
Es spricht S3, der Abschied ist also ein aws s3 sync. Ein Speichersystem, das man leicht verlassen kann, ist das einzige, in das sich der Einstieg lohnt.
MinIO weiterlaufen lassen. Den Umzug zuerst prüfen.
Der Migrationsplaner liest das bestehende MinIO oder einen anderen S3-kompatiblen Speicher und verweigert blockierte Funktionen, statt sie still zu verlieren. Lockwell neben der Produktion betreiben, mit Verifikation und Checkpoints kopieren, und erst wechseln, wenn das eigene Hauptbuch überzeugt hat.
Was Teams hier tatsächlich betreiben
Drei konkrete Formen, keine Personas. Jede besteht aus einem Tenant, ein paar Schlüsseln mit Geltungsbereich und Teilen des Servers, die es schon gibt.
Kundenlieferungen mit ablaufenden Links
Eine Agentur hält jeden Kunden in einem eigenen Tenant. Lieferungen werden als signierte Links geteilt, die nach sieben Tagen sterben: keine Kundenkonten, kein öffentlicher Bucket, und das Audit-Log zeigt jeden Download.
Signierte URLs →Nutzerdateien in einem Multi-Tenant-SaaS
Jeder Kunde ist ein Tenant. Browser laden mit signierten PUT-URLs direkt in den Speicher, Webhooks stoßen die Thumbnail-Pipeline an, und ein geleakter Schlüssel sieht höchstens die Welt eines Tenants.
Das App-Kit →Das Archiv, das ein Auditor besucht
Rechnungen und Belege landen unter Object-Lock-Aufbewahrung mit stets aktiver Verschlüsselung. Lifecycle lässt ablaufen, was ablaufen darf, Legal Hold friert ein, was nicht, und die Restore-Übung beweist, dass die Backups echt sind.
Object Lock →Erst zusehen, dann nachrechnen
Das Terminal spielt den echten Lebenszyklus gegen die echte CLI-Oberfläche ab. Die Balken stammen aus der festgehaltenen Benchmark-Evidenz, und das Werkzeug liegt im Repository, sodass jede Zahl auf eigener Hardware wiederholt werden kann.
Alles, was die Speicherschicht einer App braucht
Provisionierung, signierte Uploads, Verschlüsselung, Edge-Support und Webhooks, alles in einem Server und einem SDK. Man näht nicht Bucket, Queue, Signierer und Secret-Store zusammen.
Multi-Tenant-Provisionierung
Mit einem Aufruf sicherstellen, dass ein Tenant existiert, und einen frischen Schlüssel mit Geltungsbereich prägen: Lesen/Schreiben/Löschen, optionaler Bucket-Scope, das Secret nur einmal sichtbar. Jeder Tenant ist standardmäßig isoliert.
Native + S3 + Admin-APIs
Eine native JSON-Datenebene, S3-SigV4-Kompatibilität und eine JSON-Admin-API. Drei Oberflächen über einem Server, erreichbar aus einem SDK. Mit dem Speicher so sprechen, wie es der Stack bevorzugt.
Signierte Browser-URLs
Eine Upload- oder Download-URL serverseitig signieren und direkt dem Browser geben. Die native API signiert auch Schreib-URLs, nicht nur GET, sodass Objekt-Bytes nie durch die eigene App laufen.
Edge-tauglich
Die Native- und Kit-Clients importieren nichts aus node:*, laufen also auf Cloudflare Workers, Vercel Edge, Bun und Deno über einen eigenen /edge-Einstieg ohne node:crypto.
Stets aktive Verschlüsselung
Authentifizierte Verschlüsselung im Ruhezustand ist standardmäßig an: AES-256-GCM oder XChaCha20-Poly1305 über den Objektdaten, mit Schlüsseln pro Tenant. Es gibt kein Flag, das man vergessen könnte.
Verifizierbare Webhooks
Bucket-Benachrichtigungen POSTen an den eigenen Endpoint mit einer HMAC-SHA256-Signatur in konstanter Zeit. verifyWebhook prüft die Signatur in einem Aufruf, auch am Edge.
Drei APIs über demselben verschlüsselten Speicher
Lockwell stellt denselben multi-tenant, verschlüsselten Objektspeicher über drei Schnittstellen bereit. Die passende wählen, oder frei mischen.
Andocken, wo S3 schon ist
SigV4-Auth, Path-Style- und Virtual-Host-Adressierung, Versionen, Multipart, bedingte Schreibvorgänge, vorsignierte URLs, Object Lock, Tags und Lifecycle. Das Paritätsbuch dokumentiert jede Operation, und alles außerhalb schlägt geschlossen fehl, statt zu schauspielern.
Nativ mit dem Speicher sprechen
Eine JSON-Datenebene am öffentlichen Listener, ohne SigV4-Signatur und ohne XML. Bearer-Tokens werden aus Zugriffsschlüsseln geprägt und automatisch erneuert. Native signierte URLs decken GET und PUT ab.
Provisionieren und verwalten
Eine Bearer-authentifizierte JSON-Admin-API an einem privaten Listener: Tenants, Schlüssel mit Geltungsbereich, RBAC, Audit und ein OpenAPI-Dokument. Provisionierung lebt absichtlich außerhalb der Datenebene.
Keine eigene Speicherschicht zu pflegen
Der übliche Stack ist ein Bucket, eine zweite Datenbank für Metadaten, ein Signierdienst, ein Webhook-Verifizierer und der Klebstoff dazwischen. Lockwell faltet das in einen Server und ein SDK: Tenant provisionieren, scoped Client holen, Browser-Upload signieren und den Webhook verifizieren, Ende zu Ende, in derselben Bibliothek, über demselben verschlüsselten Speicher.
import { LockwellKit } from '@kelphect/sdk';
const kit = new LockwellKit({
admin: { endpoint: 'https://admin.example.com', token } },
native: { endpoint: 'https://objects.example.com' },
});
// 1. provision a tenant + mint a fresh scoped key
const { key } = await kit.provisionTenant('acme', {
defaultBucket: 'inbox',
});
// 2. sign a browser upload, then hand the URL to the client
const client = kit.clientForTenant('acme', key);
const up = await kit.signedUploadUrl(client, 'inbox', 'photo.jpg', {
ttl: 300, contentType: 'image/jpeg',
});
Was noch fehlt, und was man bis dahin tut
Eine Funktion erscheint, wenn sie dieselben Release-Tore besteht wie alles andere: Übungen, Suiten, dokumentiertes Verhalten. Bis dahin sagt der Server Nein, und diese Seite sagt es laut.
Multi-Node-Replikation
Lockwell ist heute bewusst Single-Node; das replizierte Profil bleibt ausgesetzt, bis es dieselben Takeover- und Haltbarkeitsübungen besteht. Bis dahin fahren Teams einen warmen Standby: eine zweite Instanz mit geplantem S3-Sync, und Restore-Übungen belegen die Naht.
Event-Busse (SNS, SQS, Lambda)
Benachrichtigungen gehen an signierte Webhooks, verifizierbar in einem Aufruf. Eine Queue zwischen Lockwell und der eigenen Pipeline ist einen Consumer entfernt, auf Infrastruktur, der man bereits vertraut.
Storage-Tiering
Lifecycle-Regeln lassen bereits ablaufen und räumen auf; Kaltarchivierung ist ein geplanter Job, der per S3-API in den Kaltspeicher kopiert, den die eigene Rechnung bevorzugt.