Come funziona Araluma

La risposta breve

Araluma utilizza un’architettura ibrida: due strumenti operano interamente nel browser dell’utente senza alcun upload, mentre altri due instradano una singola richiesta di rete attraverso la nostra infrastruttura quando il browser non è in grado di garantire la stessa qualità. In ogni strumento e in questa pagina viene indicato quale percorso è attivo.

Strumento	Dove avviene l’elaborazione
Circle Crop	100% nel browser, Canvas API. Nessun upload, funziona offline.
Anteprima Compress (slider + confronto formati)	100% nel browser, canvas.toBlob. Nessun upload.
Download finale Compress	Un unico round-trip verso il nostro servizio su api.araluma.com (Fastify + sharp + libvips su un VPS in Germania).
Remove Background	Un unico round-trip verso un Cloudflare Worker che esegue BiRefNet sulle GPU edge di Cloudflare, con un fallback WebAssembly nel browser quando il cloud non è raggiungibile.

È possibile verificare le affermazioni relative al lato client in circa 30 secondi: aprire DevTools → Network, svuotare il log, quindi utilizzare Circle Crop o lo slider di anteprima Compress — non si vedrà alcuna richiesta che trasporti i byte dell’immagine fuori dalla pagina. Per i due strumenti che coinvolgono il server si vedrà esattamente un upload per operazione, verso gli endpoint indicati sopra.

Perché ibrida

La maggior parte degli strumenti immagine online si colloca a uno degli estremi: upload di tutto su un server (si attende il round-trip e l’operatore conserva il file), oppure tutto nel browser (si paga in qualità e velocità nelle fasi di codifica/IA). Nessuno dei due estremi è vincente in ogni situazione.

Abbiamo scelto il lato client dove i browser sono già eccellenti — l’elemento <canvas> gestisce il ritaglio, la rotazione e la codifica in anteprima con perdita in JPG/WebP — e il lato server dove il browser perde in modo misurabile:

• Compressione immagini, nel download finale. sharp + libvips 8.17 lato server produce file del 10-15% più piccoli byte per byte rispetto ai codificatori del browser a parità di qualità visiva, e consente l’accesso alla regolazione di velocità/chroma AVIF e all’output JPEG XL che il browser non espone. Lo slider e l’anteprima continuano a girare nel browser, così le iterazioni restano immediate; solo il tap “Scarica” transita attraverso il nostro servizio.
• Rimozione dello sfondo con IA, nel percorso predefinito. Il modello BiRefNet eseguito da cf.image.segment di Cloudflare (stessa architettura di remove.bg) richiede una GPU reale per completare l’operazione in 1-3 secondi. Il fallback nel browser (ISNet via ONNX Runtime + WebAssembly) funziona, ma richiede 20-40 secondi alla prima esecuzione e 2-10 secondi nelle successive, producendo un ritaglio visibilmente meno preciso su capelli, pellicce e bordi sottili.

Il costo accettato per il lato server su questi due percorsi è un round-trip per operazione. Il costo evitato rimanendo lato client altrove (Circle Crop, anteprima Compress) è il costo del round-trip sulle parti del flusso di lavoro che iterano più velocemente.

La pipeline, passo dopo passo

1. Si seleziona 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, indipendentemente dallo strumento utilizzato.

2. Il browser decodifica l’immagine

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

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

• Circle Crop. Una trasformazione pixel Canvas 2D con un percorso di ritaglio circolare. La bitmap viene disegnata in un <canvas> alla rotazione e allo zoom scelti, viene applicato il ritaglio circolare e l’interno del cerchio viene riletto come ImageData. Cropper.js gestisce l’interazione del riquadro di ritaglio. Interamente nel browser.
• Compress — anteprima e slider. Ricodifica JPG, PNG, WebP o AVIF usando canvas.toBlob, così l’anteprima affiancata si aggiorna mentre si sposta il cursore della qualità. Interamente nel browser. Nessun upload ancora.
• Compress — Download. Quando si preme “Scarica”, l’immagine viene inviata una sola volta a api.araluma.com (un servizio Fastify in esecuzione su un VPS in Germania gestito da Hostinger, Node 24 + sharp 0.34 + libvips 8.17, le stesse librerie C usate da Squoosh nel suo percorso server). Viene ricodificata con gli stessi parametri impostati nell’anteprima e i byte vengono trasmessi al browser in streaming. Il servizio mantiene una cache con indirizzamento per contenuto e isolamento per tenant (un hash dei byte di input + parametri) limitata a 500 MB, così che il re-download della stessa immagine con gli stessi parametri replichi i byte memorizzati nella cache — la cache non è indicizzata per utente, IP o nome file. Se il servizio non è raggiungibile, lo strumento ricade sul blob di anteprima nel browser.
• Remove Background — percorso cloud predefinito. L’immagine viene caricata una sola volta su un Cloudflare Worker (araluma-bg-remover), archiviata temporaneamente in un bucket R2 privato (araluma-bg-temp), elaborata dalla trasformazione cf.image.segment di Cloudflare che esegue il modello BiRefNet sulle GPU edge di Cloudflare, e il ritaglio viene restituito in streaming. L’oggetto R2 archiviato viene eliminato entro un’ora da una regola del ciclo di vita R2, indipendentemente dall’esito. Una foto tipica viene elaborata in 1-3 secondi. Limiti giornalieri per IP e un tetto di 5 MB per l’upload mantengono il tier gratuito sostenibile.
• Remove Background — fallback WebAssembly. Se il Worker non è raggiungibile (connessione interrotta, firewall restrittivo, quota giornaliera esaurita o file superiore al limite cloud di 5 MB), lo strumento passa in modo trasparente al modello ISNet in esecuzione localmente nel browser tramite ONNX Runtime Web con WebAssembly. Alla prima esecuzione viene scaricato il modello (~80 MB) e il processo richiede 20-40 secondi; le esecuzioni successive richiedono 2-10 secondi. Nessun upload su questo percorso — verificabile nelle DevTools.

4. Si scarica il risultato

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

Come verificarlo autonomamente

Si può scegliere il metodo preferito:

Metodo 1 — Osservare la scheda Network

1. Aprire Araluma in una nuova scheda e aprire DevTools → Network.
2. Usare Circle Crop o lo slider di anteprima Compress. Si vedranno richieste solo per HTML/CSS/JS/font, più i moduli WebAssembly rilevanti al primo utilizzo. Nessuna richiesta trasporterà i byte dell’immagine.
3. Usare ora Compress → Scarica o Remove Background. Si vedrà esattamente un POST a api.araluma.com (Compress) o al Worker di Remove Background, contenente l’immagine — e una risposta con il risultato. Passando il cursore su una richiesta si visualizzano dimensione e tempi.

La colonna “Initiator” indica quale script ha attivato ciascuna richiesta, e la colonna “Type” indica cosa è stato inviato. Non viene nascosto nulla.

Metodo 2 — Usare gli strumenti offline

1. Caricare qualsiasi pagina strumento di Araluma. Usare Remove Background una volta su un’immagine piccola affinché il modello ISNet nel browser venga memorizzato nella cache.
2. Aprire DevTools → Network → spuntare Offline (oppure disattivare il Wi-Fi).
3. Ricaricare la pagina: gli asset statici sono in cache, quindi la pagina si carica comunque.
4. Provare ogni strumento:
   • Circle Crop e l’anteprima Compress continuano a funzionare — non hanno mai avuto bisogno della rete.
   • Compress Download ricade sul blob di anteprima nel browser (codifica leggermente meno efficiente, ma funzionale).
   • Remove Background ricade sul modello WebAssembly ISNet e funziona senza alcuna richiesta in uscita.

Se i quattro strumenti funzionano offline (uno leggermente degradato, tre identici), per definizione nessun server ha visto l’immagine.

Cosa vediamo — e cosa no

Nei percorsi lato client, non vediamo nulla dell’immagine. Non c’è nessuna richiesta da esaminare, nessuna cache in cui archiviarla, nessuna riga di log.

Nei percorsi lato server:

• Compress Download vede i byte dell’immagine per la durata della codifica (tipicamente alcune centinaia di millisecondi), mantiene una voce di cache con indirizzamento per contenuto per il TTL della cache, e nulla di più. La cache non è indicizzata per utente, IP, nome file o qualsiasi identificatore che potrebbe essere usato per risalire alle immagini di un determinato utente. Il contenuto delle immagini non viene registrato nei log. Il servizio di codifica è condiviso tra i due stessi tenant già serviti da v1 prima del passaggio, con CORS, rate limit e URL canonici firmati HMAC per tenant.
• Remove Background vede l’immagine per la durata dell’upload temporaneo e della chiamata di segmentazione (tipicamente 1-3 secondi in totale), dopo di che la copia archiviata viene eliminata dalla regola del ciclo di vita R2. I byte dell’utente non vengono mai inviati ad alcun provider di modelli terzo — il modello BiRefNet gira all’interno dell’infrastruttura di Cloudflare, non su un’API esterna di tipo remove.bg / fal.ai / Replicate.

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 ONNX ISNet), il nostro provider di hosting vede che qualcuno ha recuperato il modulo — allo stesso modo in cui vede qualcuno recuperare il file CSS. Il modulo stesso non contiene alcuna informazione sull’immagine.

L’inventario completo dei dati si trova 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 migliorati progressivamente solo dove sono presenti 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 / <canvas> — codifica JPEG, PNG, WebP, AVIF (supportata dal browser) nell’anteprima Compress e in tutto Circle Crop.
• Cropper.js — il layer di interazione del rettangolo di ritaglio.
• ONNX Runtime Web — esegue il fallback WebAssembly ISNet per Remove Background.
• Cloudflare Pages — ospita la build statica e la serve dall’edge.
• Cloudflare Workers + R2 + cf.image.segment (BiRefNet) — la pipeline predefinita di Remove Background.
• Fastify + sharp 0.34 + libvips 8.17 su Node 24 — il servizio di download Compress su api.araluma.com, su un VPS Hostinger in Germania.
• Cloudflare Web Analytics — conteggi di visualizzazioni di pagina aggregati, senza cookie.

Supporto dei browser

Tutti gli strumenti funzionano 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 (es. showSaveFilePicker, OffscreenCanvas), viene utilizzata; dove non la supporta, si ricorre all’equivalente più vecchio. Non è presente alcuna barriera “il tuo browser non è supportato”.

Gli unici requisiti indispensabili sono JavaScript (per qualsiasi strumento) e una connessione di rete (solo per Compress Download o il percorso predefinito di Remove Background — gli altri percorsi funzionano completamente offline dopo il primo caricamento della pagina).

Domande

Qualcosa che non è stato trattato? Scrivere a support@araluma.com. Le domande tecniche sono benvenute.