Come funziona Araluma

La risposta breve

Araluma utilizza un’architettura ibrida: la maggior parte degli strumenti gira interamente nel tuo browser senza alcun upload, e una piccola parte instrada una singola richiesta di rete attraverso la nostra infrastruttura quando il browser non riesce a eguagliare la qualità, sempre con un fallback lato client invisibile. Ti diciamo su quale percorso ti trovi, in ogni strumento e in questa pagina.

La tabella qui sotto è rappresentativa, non esaustiva (il catalogo continua a crescere). Mostra un esempio per ciascun tipo di percorso:

Strumento di esempio	Dove avviene il lavoro
Circle Crop (solo browser)	100% nel tuo browser, Canvas API. Nessun upload, funziona offline.
Anteprima Compress (solo browser)	100% nel tuo browser, canvas.toBlob. Nessun upload. Lo slider resta immediato.
Download Compress (tocca il server)	Un round-trip al nostro servizio su api.araluma.com (sharp più libvips su un VPS in Germania), con un fallback nel browser.
Remove Background (tocca il server)	Un round-trip a un Cloudflare Worker che esegue BiRefNet sulle GPU edge, con un fallback WebAssembly nel tuo browser.

Gli strumenti di ritaglio, ridimensionamento, PDF e conversione di formato (a parte il percorso di output AVIF) stanno sul lato solo-browser. Download della compressione, rimozione dello sfondo, ingrandimento con AI e conversioni con output AVIF stanno sul lato che tocca il server, ognuno con un fallback locale.

Puoi verificare le affermazioni solo-browser in circa 30 secondi: apri i DevTools, vai al pannello Network, svuota il log, poi usa un qualsiasi strumento solo-browser. Vedrai zero richieste che portano i byte della tua immagine fuori dalla pagina. Per gli strumenti che toccano il server vedrai esattamente un upload per operazione, verso gli endpoint indicati sopra.

Perché ibrida

La maggior parte degli strumenti immagine online si colloca a un estremo: carica-tutto-su-un-server (aspetti i round-trip e l’operatore conserva il tuo file), oppure tutto-nel-browser (paghi in qualità e velocità sui passaggi di codifica e AI). Nessuno dei due estremi vince ovunque.

Abbiamo scelto il lato client ovunque i browser siano già eccellenti. L’elemento <canvas> gestisce ritaglio, rotazione, ridimensionamento e la codifica con perdita in anteprima in JPG o WebP, e i browser moderni decodificano nativamente ogni formato comune. Abbiamo scelto il lato server solo per i pochi passaggi in cui il browser perde ancora in modo misurabile:

• Compressione, nel download finale. sharp più libvips lato server produce file del 10-15% più piccoli byte per byte rispetto agli encoder del browser a parità di qualità visiva, ed espone una regolazione di velocità e chroma per AVIF che il browser non offre. Lo slider e l’anteprima continuano a girare nel tuo browser così l’iterazione resta immediata. Solo il tocco su “Scarica” passa attraverso il nostro servizio.
• Rimozione dello sfondo con AI, nel percorso predefinito. Il modello BiRefNet eseguito dalla segmentazione di immagini di Cloudflare (la stessa architettura di remove.bg) ha bisogno di una GPU reale per concludere in un secondo o due. Il fallback nel browser (ISNet via ONNX Runtime più WebAssembly) funziona, ma impiega molto più tempo e produce un ritaglio visibilmente più grezzo su capelli, pelliccia e bordi sottili.
• Ingrandimento con AI, nel percorso predefinito. La super-risoluzione cloud recupera dettaglio che un ricampionamento lato browser non riesce a ottenere, con un fallback nel browser quando il servizio non è raggiungibile.

Il costo che accettiamo per stare sul lato server su questi percorsi è un round-trip per operazione. Il costo che evitiamo restando sul lato client ovunque altro è quella stessa spesa sulle parti del flusso di lavoro che iterano più rapidamente.

La pipeline, passo dopo passo

1. Selezioni un file

Tramite il selettore file, il trascinamento o l’incolla, il browser passa a JavaScript un oggetto File. JavaScript legge i byte usando FileReader o Blob.arrayBuffer(). In nessun momento di questo passaggio il file viene inviato sulla rete, qualunque strumento tu stia usando.

2. Il browser decodifica l’immagine

I browser moderni decodificano nativamente JPG, PNG, WebP, GIF e AVIF. Usiamo createImageBitmap() per trasformare i byte grezzi in una bitmap con cui la GPU può lavorare, fuori dal thread principale. Per HEIC sui browser che non lo decodificano nativamente, ricorriamo a un decoder WebAssembly che gira localmente nel tuo browser.

3. Lo strumento fa il suo lavoro, qui i percorsi divergono

• Strumenti solo-browser (ritaglio, ridimensionamento, l’anteprima e lo slider della compressione, l’assemblaggio del PDF e la maggior parte delle conversioni di formato). Girano come trasformazioni di pixel Canvas e ricodifiche canvas.toBlob proprio sulla tua macchina. Il riquadro di ritaglio interattivo usa Cropper.js. Niente lascia la pagina.
• Download della compressione. Quando tocchi “Scarica”, l’immagine va una sola volta a api.araluma.com (un servizio Fastify su un VPS Hostinger in Germania, Node più sharp e libvips, le stesse librerie C che Squoosh usa sul suo percorso server). Viene ricodificata con i parametri impostati nell’anteprima e i byte tornano in streaming. Il servizio mantiene una cache isolata per tenant e indirizzata per contenuto (un hash dei byte di input più i parametri), così che riscaricare la stessa immagine con le stesse impostazioni riproponga i byte in cache. Quella cache non è indicizzata per te, per il tuo IP o per il nome del file. Se il servizio non è raggiungibile, lo strumento ripiega sul blob di anteprima nel browser.
• Rimozione dello sfondo, percorso cloud predefinito. L’immagine viene caricata una sola volta su un Cloudflare Worker, archiviata temporaneamente in un bucket R2 privato, elaborata dalla segmentazione di immagini di Cloudflare che esegue il modello BiRefNet sulle GPU edge, e il ritaglio torna in streaming. L’oggetto temporaneo viene eliminato entro un’ora da una regola del ciclo di vita R2, indipendentemente dall’esito. Una foto tipica si conclude in un secondo o due. Limiti giornalieri per IP e per dimensione dell’upload mantengono sostenibile il tier gratuito.
• Rimozione dello sfondo, fallback WebAssembly. Se il Worker non è raggiungibile (la rete cade, un firewall restrittivo lo blocca, la quota giornaliera è esaurita, o il file supera il limite cloud), lo strumento passa in silenzio al modello ISNet in esecuzione locale tramite ONNX Runtime Web e WebAssembly. La prima esecuzione scarica il modello e richiede più tempo, le successive sono più rapide. Nessun upload su questo percorso, verificabile nei DevTools.
• Ingrandimento con AI. Il percorso predefinito invia l’immagine una sola volta a un servizio cloud di super-risoluzione e restituisce in streaming il risultato ingrandito, con un fallback lato browser se il servizio non è raggiungibile.

4. Scarichi il risultato

La bitmap di output viene codificata in un Blob, avvolta in un object URL e passata alla finestra di dialogo standard di salvataggio file del tuo browser. Il file appare sul disco.

Come verificarlo da solo

Scegli il metodo che preferisci:

Metodo 1. Osserva la scheda Network

1. Apri Araluma in una scheda nuova e apri i DevTools, poi il pannello Network.
2. Usa uno strumento solo-browser come Circle Crop o lo slider di anteprima Compress. Vedrai richieste solo per HTML, CSS, JS e font, più i moduli WebAssembly pertinenti al primo utilizzo. Nessuna richiesta porterà i byte della tua immagine.
3. Ora usa uno strumento che tocca il server come Download Compress o Remove Background. Vedrai esattamente un POST che porta la tua immagine all’endpoint indicato, e una risposta che torna con il risultato. Passa il cursore su qualsiasi richiesta per leggerne dimensione e tempi.

La colonna “Initiator” ti dice quale script ha attivato ciascuna richiesta, e la colonna “Type” ti dice cosa è stato inviato. Non nascondiamo nessuna delle due.

Metodo 2. Usa gli strumenti offline

1. Carica una qualsiasi pagina strumento di Araluma. Esegui Remove Background una volta su un’immagine piccola così il modello ISNet nel browser viene messo in cache.
2. Apri i DevTools, vai su Network e spunta Offline (oppure disattiva il Wi-Fi).
3. Ricarica la pagina. Gli asset statici sono in cache, quindi si carica comunque.
4. Prova gli strumenti:
   • Gli strumenti solo-browser continuano a funzionare. Non hanno mai avuto bisogno della rete.
   • Download Compress ripiega sul blob di anteprima nel browser (una codifica leggermente meno efficiente, ma funzionale).
   • Remove Background ripiega sul modello WebAssembly ISNet e funziona senza alcuna richiesta in uscita.

Se quegli strumenti hanno funzionato offline (alcuni degradati, quelli solo-browser identici), allora per definizione nessun server ha visto la tua immagine.

Cosa vediamo, e cosa no

Sui percorsi solo-browser, non vediamo nulla della tua immagine. Non c’è alcuna richiesta da esaminare, nessuna cache in cui archiviarla, nessuna riga di log da cercare.

Sui percorsi che toccano il server:

• Download Compress vede i byte dell’immagine per la durata della codifica (di solito poche centinaia di millisecondi), mantiene una voce di cache indirizzata per contenuto per il suo TTL, e nient’altro. La cache non è indicizzata per utente, IP, nome file o qualsiasi identificatore che potremmo usare per trovare le “tue” immagini. Non registriamo il contenuto delle immagini. Il servizio di codifica è condiviso tra gli stessi tenant che v1 serviva prima del passaggio, con CORS per tenant, rate limit e URL canonici firmati HMAC.
• Remove Background vede l’immagine per la durata dell’upload temporaneo e della chiamata di segmentazione (tipicamente un secondo o due), dopo di che la copia temporanea viene eliminata dalla regola del ciclo di vita R2. Non consegniamo mai i tuoi byte a un provider di modelli terzo. Il modello BiRefNet gira dentro l’infrastruttura di Cloudflare, non su un’API esterna in stile remove.bg, fal.ai o Replicate.
• Ingrandimento con AI vede l’immagine per la durata della chiamata di super-risoluzione, restituisce il risultato e non conserva nulla che sia legato a te.

Su ogni percorso, il nostro provider di analytics (Cloudflare Web Analytics) registra dati aggregati di visualizzazione delle pagine: URL, paese, famiglia di browser, Core Web Vitals. Nessun cookie, nessun identificatore persistente, nulla riconducibile a una persona.

Per gli strumenti che scaricano un modulo WebAssembly al primo utilizzo (il decoder HEIC, il modello ISNet ONNX), il nostro provider di hosting vede che qualcuno ha recuperato il modulo, allo stesso modo in cui vede recuperare un file CSS. Il modulo stesso non porta alcuna informazione sulla tua immagine.

L’inventario completo dei dati è nella nostra informativa sulla privacy.

Lo stack tecnologico

Per i curiosi:

• Astro, il generatore di siti statici. Ogni pagina viene consegnata come HTML semplice con “islands” JavaScript a miglioramento progressivo solo dove vivono gli strumenti interattivi.
• CSS vanilla con proprietà personalizzate, senza Tailwind, senza CSS-in-JS. L’intero sistema di design è un singolo file tokens.css.
• canvas.toBlob e <canvas>, la codifica JPEG, PNG, WebP e AVIF per gli strumenti e le anteprime lato browser.
• Cropper.js, il layer di interazione del rettangolo di ritaglio.
• ONNX Runtime Web, che esegue il fallback WebAssembly ISNet per Remove Background.
• Cloudflare ospita la build statica e la serve dall’edge, ed esegue i Workers, R2 e la pipeline di segmentazione di immagini (BiRefNet) dietro il percorso predefinito di Remove Background.
• Fastify con sharp e libvips su Node, il servizio di download Compress su api.araluma.com, su un VPS Hostinger in Germania.
• Cloudflare Web Analytics, conteggi di visualizzazione delle pagine aggregati e senza cookie.

Supporto dei browser

Ogni strumento funziona sulla versione attuale e su quella precedente di Chrome, Firefox, Safari ed Edge, desktop e mobile. Il sito usa il miglioramento progressivo: dove un browser supporta un’API più recente (per esempio showSaveFilePicker o OffscreenCanvas), la usiamo, e dove non la supporta, ricadiamo sull’equivalente più vecchio. Non c’è alcuna barriera “il tuo browser non è supportato”.

Gli unici requisiti indispensabili sono JavaScript (per qualsiasi strumento) e una connessione di rete (solo quando usi un percorso che tocca il server, gli strumenti solo-browser girano completamente offline dopo il primo caricamento della pagina).

Domande

Qualcosa che non abbiamo trattato? Scrivi a support@araluma.com. Le domande tecniche sono benvenute.