Wie Araluma funktioniert

Die kurze Antwort

Araluma verwendet eine hybride Architektur: Die meisten Werkzeuge laufen vollständig in deinem Browser ohne jeden Upload, und eine Handvoll leitet eine einzige Netzwerkanfrage durch unsere eigene Infrastruktur, wenn der Browser die Qualität nicht erreichen kann, immer mit einem unsichtbaren clientseitigen Rückfallweg. Wir sagen dir, auf welchem Weg du bist, in jedem Werkzeug und auf dieser Seite.

Die folgende Tabelle ist repräsentativ, nicht vollständig (der Katalog wächst stetig weiter). Sie zeigt je ein Beispiel für jede Art von Weg:

Beispielwerkzeug	Wo die Arbeit geschieht
Kreis-Zuschnitt (nur Browser)	100 % in deinem Browser, Canvas-API. Kein Upload, funktioniert offline.
Komprimierungsvorschau (nur Browser)	100 % in deinem Browser, canvas.toBlob. Kein Upload. Der Regler bleibt sofort.
Komprimierungs-Download (serverberührend)	Ein Hin und Zurück zu unserem Dienst unter api.araluma.com (sharp plus libvips auf einem VPS in Deutschland), mit einem Browser-Rückfallweg.
Hintergrund entfernen (serverberührend)	Ein Hin und Zurück zu einem Cloudflare Worker, der BiRefNet auf Edge-GPUs ausführt, mit einem WebAssembly-Rückfallweg in deinem Browser.

Die Werkzeuge zum Zuschneiden, zur Größenänderung, für PDF und zur Formatumwandlung (außer dem Weg mit AVIF-Ausgabe) liegen auf der reinen Browser-Seite. Komprimierungs-Download, Hintergrundentfernung, KI-Hochskalierung und Umwandlungen mit AVIF-Ausgabe liegen auf der serverberührenden Seite, jeweils mit einem lokalen Rückfallweg.

Die reinen Browser-Aussagen kannst du in etwa 30 Sekunden überprüfen: Öffne die DevTools, geh zum Netzwerk-Tab, leere das Protokoll und nutze dann ein beliebiges reines Browser-Werkzeug. Du wirst sehen, dass keine Anfrage mit deinen Bildbytes die Seite verlässt. Bei den serverberührenden Werkzeugen siehst du genau einen Upload pro Operation, an die oben genannten Endpunkte.

Warum hybrid

Die meisten Online-Bildwerkzeuge liegen an einem Extrem: alles-auf-einen-Server-hochladen (du wartest auf Hin- und Rückwege, und der Betreiber behält deine Datei) oder alles-im-Browser (du zahlst bei den Encode- und KI-Schritten mit Qualität und Geschwindigkeit). Kein Extrem gewinnt überall.

Wir haben uns für die Client-Seite entschieden, wo Browser bereits hervorragend sind. Das <canvas>-Element erledigt das Zuschneiden, Drehen, Skalieren und die verlustbehaftete Vorschau-Kodierung in JPG oder WebP, und moderne Browser dekodieren jedes gängige Format nativ. Für die Server-Seite haben wir uns nur bei den wenigen Schritten entschieden, bei denen der Browser noch messbar verliert:

• Komprimierung, beim finalen Download. Serverseitiges sharp plus libvips erzeugt Dateien, die 10 bis 15 % kleiner Byte für Byte sind als Browser-Encoder bei gleicher sichtbarer Qualität, und bietet AVIF-Geschwindigkeit und Chroma-Feineinstellungen, die der Browser nicht hat. Der Regler und die Vorschau laufen weiterhin in deinem Browser, damit das Ausprobieren sofort bleibt. Nur das Antippen von “Download” geht durch unseren Dienst.
• KI-Hintergrundentfernung, auf dem Standardweg. Das BiRefNet-Modell, das die Bildsegmentierung von Cloudflare ausführt (dieselbe Architektur wie remove.bg), braucht eine echte GPU, um in ein, zwei Sekunden fertig zu werden. Der Rückfallweg im Browser (ISNet über ONNX Runtime plus WebAssembly) funktioniert, dauert aber weit länger und erzeugt einen sichtbar gröberen Freisteller bei Haaren, Fell und feinen Kanten.
• KI-Hochskalierung, auf dem Standardweg. Die Cloud-Superauflösung holt Details zurück, die ein Resample im Browser nicht kann, mit einem Browser-Rückfallweg, wenn der Dienst nicht erreichbar ist.

Die Kosten, die wir auf diesen Wegen für die Server-Seite in Kauf nehmen, sind ein Hin und Zurück pro Operation. Die Kosten, die wir durch das Bleiben auf der Client-Seite überall sonst vermeiden, sind genau dieselbe Gebühr bei den Teilen des Arbeitsablaufs, die am schnellsten iterieren.

Der Ablauf, Schritt für Schritt

1. Du wählst eine Datei aus

Über den Dateiauswähler, per Ziehen und Ablegen oder per Einfügen übergibt der Browser dem JavaScript ein File-Objekt. JavaScript liest die Bytes mit FileReader oder Blob.arrayBuffer(). Zu keinem Zeitpunkt in diesem Schritt wird die Datei über das Netzwerk gesendet, egal welches Werkzeug du verwendest.

2. Der Browser dekodiert das Bild

Moderne Browser dekodieren JPG, PNG, WebP, GIF und AVIF nativ. Wir nutzen createImageBitmap(), um die rohen Bytes in eine Bitmap zu verwandeln, mit der die GPU arbeiten kann, abseits des Hauptthreads. Für HEIC in Browsern, die es nicht nativ dekodieren, greifen wir auf einen WebAssembly-Dekoder zurück, der lokal in deinem Browser läuft.

3. Das Werkzeug tut seine Sache, wo sich die Wege trennen

• Reine Browser-Werkzeuge (Zuschneiden, Größenänderung, die Komprimierungsvorschau und der Regler, PDF-Zusammenbau und die meisten Formatumwandlungen). Diese laufen als Canvas-Pixeltransformationen und canvas.toBlob-Neukodierungen direkt auf deinem Gerät. Der interaktive Zuschnittsrahmen nutzt Cropper.js. Nichts verlässt die Seite.
• Komprimierungs-Download. Wenn du auf “Download” tippst, geht das Bild einmal an api.araluma.com (ein Fastify-Dienst auf einem Hostinger-VPS in Deutschland, Node plus sharp und libvips, dieselben C-Bibliotheken, die Squoosh auf seinem Serverweg nutzt). Es wird mit den Parametern neu kodiert, die du in der Vorschau gesetzt hast, und die Bytes strömen zurück. Der Dienst hält einen mandantengetrennten, inhaltsadressierten Cache (ein Hash der Eingabebytes plus Parameter), sodass das erneute Herunterladen desselben Bildes mit denselben Einstellungen die zwischengespeicherten Bytes wiedergibt. Dieser Cache ist nicht nach dir, deiner IP oder dem Dateinamen indexiert. Ist der Dienst nicht erreichbar, greift das Werkzeug auf das Vorschau-Blob im Browser zurück.
• Hintergrundentfernung, Standard-Cloud-Weg. Das Bild wird einmal zu einem Cloudflare Worker hochgeladen, in einem privaten R2-Bucket zwischengelagert, von der Bildsegmentierung von Cloudflare mit dem BiRefNet-Modell auf Edge-GPUs verarbeitet, und der Freisteller strömt zurück. Das zwischengelagerte Objekt wird innerhalb einer Stunde durch eine R2-Lebenszyklusregel gelöscht, unabhängig vom Ergebnis. Ein typisches Foto ist in ein, zwei Sekunden fertig. Tägliche Grenzen pro IP und pro Uploadgröße halten den kostenlosen Tarif tragfähig.
• Hintergrundentfernung, WebAssembly-Rückfallweg. Ist der Worker nicht erreichbar (dein Netzwerk fällt aus, eine strenge Firewall blockiert ihn, das Tageskontingent ist voll, oder die Datei ist zu groß für die Cloud-Grenze), wechselt das Werkzeug still zum ISNet-Modell, das lokal über ONNX Runtime Web und WebAssembly läuft. Der erste Lauf lädt das Modell und dauert länger, spätere Läufe sind schneller. Kein Upload auf diesem Weg, in den DevTools überprüfbar.
• KI-Hochskalierung. Der Standardweg sendet das Bild einmal an einen Cloud-Dienst für Superauflösung und streamt das vergrößerte Ergebnis zurück, mit einem Browser-Rückfallweg, falls der Dienst nicht erreichbar ist.

4. Du lädst das Ergebnis herunter

Die Ausgabe-Bitmap wird in ein Blob kodiert, in eine Objekt-URL gepackt und an den Standard-Speicherdialog deines Browsers übergeben. Die Datei landet auf deiner Festplatte.

Wie du es selbst überprüfst

Wähl, was dir lieber ist:

Methode 1. Den Netzwerk-Tab beobachten

1. Öffne Araluma in einem frischen Tab und öffne die DevTools, dann den Netzwerk-Tab.
2. Nutze ein reines Browser-Werkzeug wie den Kreis-Zuschnitt oder den Komprimierungs-Vorschauregler. Du wirst nur Anfragen für HTML, CSS, JS und Schriften sehen, dazu die jeweiligen WebAssembly-Module bei der ersten Nutzung. Keine Anfrage trägt deine Bildbytes.
3. Nutze nun ein serverberührendes Werkzeug wie Komprimierungs-Download oder Hintergrund entfernen. Du wirst genau ein POST sehen, das dein Bild an den genannten Endpunkt trägt, und eine Antwort, die mit dem Ergebnis zurückkommt. Fahr über eine Anfrage, um ihre Größe und Zeit zu lesen.

Die Spalte “Initiator” sagt dir, welches Skript jede Anfrage ausgelöst hat, und die Spalte “Type” sagt dir, was gesendet wurde. Wir verbergen keines von beidem.

Methode 2. Die Werkzeuge offline nutzen

1. Lade eine beliebige Araluma-Werkzeugseite. Führe Hintergrund entfernen einmal an einem kleinen Bild aus, damit das ISNet-Modell im Browser zwischengespeichert ist.
2. Öffne die DevTools, geh zum Netzwerk-Tab und setze einen Haken bei Offline (oder schalte das WLAN aus).
3. Lade die Seite neu. Die statischen Inhalte sind zwischengespeichert, also lädt sie weiterhin.
4. Probier die Werkzeuge:
   • Reine Browser-Werkzeuge funktionieren weiter. Sie brauchten das Netzwerk nie.
   • Komprimierungs-Download greift auf das Vorschau-Blob im Browser zurück (eine etwas weniger effiziente Kodierung, aber funktionsfähig).
   • Hintergrund entfernen greift auf das ISNet-WebAssembly-Modell zurück und funktioniert ohne jede ausgehende Anfrage.

Wenn diese Werkzeuge offline funktioniert haben (einige abgeschwächt, die reinen Browser-Werkzeuge identisch), dann hat per Definition kein Server dein Bild gesehen.

Was wir sehen und was nicht

Auf den reinen Browser-Wegen sehen wir nichts über dein Bild. Es gibt keine Anfrage zum Ansehen, keinen Cache zum Speichern, keine Logzeile zum Durchsuchen.

Auf den serverberührenden Wegen:

• Komprimierungs-Download sieht die Bildbytes für die Dauer der Kodierung (meist ein paar hundert Millisekunden), hält einen inhaltsadressierten Cache-Eintrag für dessen Lebensdauer, und das war’s. Der Cache ist nicht nach Nutzer, IP, Dateiname oder einer Kennung indexiert, mit der wir “deine” Bilder finden könnten. Wir protokollieren keine Bildinhalte. Der Kodierungsdienst wird über dieselben Mandanten geteilt, die v1 vor der Umstellung bediente, mit mandantenbezogenem CORS, Ratengrenzen und HMAC-signierten kanonischen URLs.
• Hintergrund entfernen sieht das Bild für die Dauer des Zwischenlager-Uploads und des Segmentierungsaufrufs (typischerweise ein, zwei Sekunden), danach wird die zwischengelagerte Kopie durch die R2-Lebenszyklusregel gelöscht. Wir geben deine Bytes niemals an einen Modellanbieter Dritter weiter. Das BiRefNet-Modell läuft innerhalb der eigenen Infrastruktur von Cloudflare, nicht auf einer externen API im Stil von remove.bg, fal.ai oder Replicate.
• KI-Hochskalierung sieht das Bild für die Dauer des Superauflösungsaufrufs, gibt das Ergebnis zurück und behält nichts, das mit dir verknüpft ist.

Auf jedem Weg erfasst unser Analyse-Anbieter (Cloudflare Web Analytics) aggregierte Seitenaufruf-Daten: URL, Land, Browser-Familie, Core Web Vitals. Keine Cookies, keine dauerhaften Kennungen, nichts, das mit einer Person verknüpft ist.

Bei Werkzeugen, die bei der ersten Nutzung ein WebAssembly-Modul herunterladen (der HEIC-Dekoder, das ISNet-ONNX-Modell), sieht unser Hosting-Anbieter, dass jemand das Modul abgerufen hat, genauso wie er sieht, dass eine CSS-Datei abgerufen wurde. Das Modul selbst trägt keine Information über dein Bild.

Das vollständige Datenverzeichnis steht in unserer Datenschutzerklärung.

Der Technologie-Stack

Für die Neugierigen:

• Astro, der Generator für statische Seiten. Jede Seite wird als reines HTML ausgeliefert, mit fortschreitend verbesserten JavaScript-”Inseln” nur dort, wo interaktive Werkzeuge leben.
• Reines CSS mit benutzerdefinierten Eigenschaften, kein Tailwind, kein CSS-in-JS. Das gesamte Designsystem ist eine einzige tokens.css-Datei.
• canvas.toBlob und <canvas>, die JPEG-, PNG-, WebP- und AVIF-Kodierung für die browserseitigen Werkzeuge und Vorschauen.
• Cropper.js, die Interaktionsschicht für das Zuschnittsrechteck.
• ONNX Runtime Web, das den ISNet-WebAssembly-Rückfallweg für Hintergrund entfernen ausführt.
• Cloudflare hostet den statischen Build und liefert ihn vom Edge aus, und betreibt die Workers, R2 und die Bildsegmentierungs-Pipeline (BiRefNet) hinter dem Standardweg von Hintergrund entfernen.
• Fastify mit sharp und libvips auf Node, der Komprimierungs-Download-Dienst unter api.araluma.com, auf einem Hostinger-VPS in Deutschland.
• Cloudflare Web Analytics, aggregierte, cookie-lose Seitenaufruf-Zahlen.

Browser-Unterstützung

Jedes Werkzeug funktioniert in der aktuellen und der vorigen Version von Chrome, Firefox, Safari und Edge, auf Desktop und Mobil. Die Seite nutzt fortschreitende Verbesserung: Wo ein Browser eine neuere API unterstützt (zum Beispiel showSaveFilePicker oder OffscreenCanvas), nutzen wir sie, und wo nicht, greifen wir auf das ältere Gegenstück zurück. Es gibt keine “Dein Browser wird nicht unterstützt”-Mauer.

Die einzigen harten Voraussetzungen sind JavaScript (für jedes Werkzeug) und eine Netzwerkverbindung (nur bei der Nutzung eines serverberührenden Wegs, die reinen Browser-Werkzeuge laufen nach dem ersten Seitenaufruf vollständig offline).

Fragen

Etwas, das wir nicht behandelt haben? Schreib an support@araluma.com. Technische Fragen sind willkommen.