Cómo funciona Araluma

La respuesta corta

Araluma usa una arquitectura híbrida: la mayoría de las herramientas funcionan por completo en tu navegador sin ninguna subida, y unas pocas dirigen una única petición de red a través de nuestra propia infraestructura cuando el navegador no puede igualar la calidad, siempre con un respaldo del lado del cliente invisible. Te decimos en qué camino estás, en cada herramienta y en esta página.

La tabla de abajo es representativa, no exhaustiva (el catálogo sigue creciendo). Muestra un ejemplo de cada tipo de camino:

Herramienta de ejemplo	Dónde ocurre el trabajo
Circle Crop (solo navegador)	100% en tu navegador, Canvas API. Sin subida, funciona sin conexión.
Vista previa de Compress (solo navegador)	100% en tu navegador, canvas.toBlob. Sin subida. El slider se mantiene instantáneo.
Descarga de Compress (toca el servidor)	Un viaje de ida y vuelta a nuestro servicio en api.araluma.com (sharp más libvips en un VPS en Alemania), con un respaldo en el navegador.
Remove Background (toca el servidor)	Un viaje de ida y vuelta a un Cloudflare Worker que ejecuta BiRefNet en las GPUs de edge, con un respaldo WebAssembly en tu navegador.

Las herramientas de recorte, redimensionado, PDF y conversión de formato (salvo el camino de salida AVIF) están del lado solo-navegador. La descarga de compresión, la eliminación de fondo, el escalado con IA y las conversiones con salida AVIF están del lado que toca el servidor, cada una con un respaldo local.

Puedes verificar las afirmaciones de solo-navegador en unos 30 segundos: abre DevTools, ve al panel Network, limpia el log y usa cualquier herramienta solo-navegador. Verás cero peticiones que lleven los bytes de tu imagen fuera de la página. Para las herramientas que tocan el servidor verás exactamente una subida por operación, a los endpoints mencionados arriba.

Por qué híbrido

La mayoría de las herramientas de imagen online se sitúa en un extremo: subir-todo-a-un-servidor (esperas los viajes de ida y vuelta y el operador guarda tu archivo), o todo-en-el-navegador (pagas en calidad y velocidad en los pasos de codificación e IA). Ninguno de los dos extremos gana en todas partes.

Elegimos el lado del cliente allí donde los navegadores ya son excelentes. El elemento <canvas> se encarga del recorte, la rotación, el redimensionado y la codificación con pérdida de la vista previa en JPG o WebP, y los navegadores modernos decodifican de forma nativa todos los formatos comunes. Elegimos el lado del servidor solo para los pocos pasos en los que el navegador todavía pierde de forma medible:

• Compresión, en la descarga final. El sharp más libvips del lado del servidor produce archivos un 10-15% más pequeños byte a byte que los codificadores del navegador con la misma calidad visual, y expone un ajuste de velocidad y croma para AVIF que el navegador no ofrece. El slider y la vista previa siguen corriendo en tu navegador para que la iteración sea instantánea. Solo el toque de “Descargar” pasa por nuestro servicio.
• Eliminación de fondo con IA, en el camino predeterminado. El modelo BiRefNet que ejecuta la segmentación de imágenes de Cloudflare (la misma arquitectura que remove.bg) necesita una GPU real para terminar en uno o dos segundos. El respaldo en el navegador (ISNet vía ONNX Runtime más WebAssembly) funciona, pero tarda mucho más y produce un recorte visiblemente más tosco en cabello, pelaje y bordes finos.
• Escalado con IA, en el camino predeterminado. La superresolución en la nube recupera detalle que un remuestreo del lado del navegador no consigue, con un respaldo en el navegador cuando el servicio no está disponible.

El costo que aceptamos por estar del lado del servidor en esos caminos es un viaje de ida y vuelta por operación. El costo que evitamos al permanecer del lado del cliente en todo lo demás es esa misma tarifa en las partes del flujo de trabajo que iteran más rápido.

El pipeline, paso a paso

1. Seleccionas un archivo

Mediante el selector de archivos, arrastrando y soltando, o pegando, el navegador le entrega a JavaScript un objeto File. JavaScript lee los bytes usando FileReader o Blob.arrayBuffer(). En ningún momento de este paso se envía el archivo por la red, sea cual sea la herramienta que estés usando.

2. El navegador decodifica la imagen

Los navegadores modernos decodifican de forma nativa JPG, PNG, WebP, GIF y AVIF. Usamos createImageBitmap() para convertir los bytes en bruto en un bitmap con el que la GPU puede trabajar, fuera del hilo principal. Para HEIC en navegadores que no lo decodifican de forma nativa, recurrimos a un decodificador WebAssembly que se ejecuta localmente en tu navegador.

3. La herramienta hace su trabajo, aquí los caminos divergen

• Herramientas solo-navegador (recorte, redimensionado, la vista previa y el slider de compresión, el ensamblado de PDF y la mayoría de las conversiones de formato). Corren como transformaciones de píxeles Canvas y recodificaciones canvas.toBlob en tu propia máquina. El marco de recorte interactivo usa Cropper.js. Nada sale de la página.
• Descarga de compresión. Cuando tocas “Descargar”, la imagen va una vez a api.araluma.com (un servicio Fastify en un VPS de Hostinger en Alemania, Node más sharp y libvips, las mismas bibliotecas C que usa Squoosh en su camino de servidor). Se recodifica con los parámetros que fijaste en la vista previa y los bytes regresan en streaming. El servicio mantiene una caché aislada por tenant y direccionada por contenido (un hash de los bytes de entrada más los parámetros), de modo que volver a descargar la misma imagen con los mismos ajustes reproduce los bytes en caché. Esa caché no está indexada por ti, tu IP ni el nombre del archivo. Si el servicio no está disponible, la herramienta recurre al blob de vista previa en el navegador.
• Eliminación de fondo, camino predeterminado en la nube. La imagen se sube una vez a un Cloudflare Worker, se almacena de forma temporal en un bucket R2 privado, se procesa mediante la segmentación de imágenes de Cloudflare que ejecuta el modelo BiRefNet en las GPUs de edge, y el recorte regresa en streaming. El objeto temporal se elimina en el plazo de una hora por una regla de ciclo de vida de R2, sea cual sea el resultado. Una foto típica termina en uno o dos segundos. Límites diarios por IP y de tamaño de subida mantienen sostenible el plan gratuito.
• Eliminación de fondo, respaldo WebAssembly. Si el Worker no está disponible (tu red cae, un firewall estricto lo bloquea, la cuota diaria está llena, o el archivo supera el límite de la nube), la herramienta cambia en silencio al modelo ISNet que se ejecuta localmente vía ONNX Runtime Web y WebAssembly. La primera ejecución descarga el modelo y tarda más, las siguientes son más rápidas. Sin subida en este camino, verificable en DevTools.
• Escalado con IA. El camino predeterminado envía la imagen una vez a un servicio de superresolución en la nube y devuelve en streaming el resultado ampliado, con un respaldo del lado del navegador si el servicio no se puede alcanzar.

4. Descargas el resultado

El bitmap de salida se codifica en un Blob, se envuelve en un object URL y se entrega al diálogo estándar de guardar archivo de tu navegador. El archivo aparece en tu disco.

Cómo verificarlo tú mismo

Elige el método que prefieras:

Método 1. Observa la pestaña Network

1. Abre Araluma en una pestaña nueva y abre DevTools, luego el panel Network.
2. Usa una herramienta solo-navegador como Circle Crop o el slider de vista previa de Compress. Verás peticiones solo de HTML, CSS, JS y fuentes, más los módulos WebAssembly pertinentes en el primer uso. Ninguna petición llevará los bytes de tu imagen.
3. Ahora usa una herramienta que toca el servidor como Descarga de Compress o Remove Background. Verás exactamente un POST que lleva tu imagen al endpoint indicado, y una respuesta que regresa con el resultado. Pasa el cursor sobre cualquier petición para leer su tamaño y su tiempo.

La columna “Initiator” te dice qué script activó cada petición, y la columna “Type” te dice qué se envió. No ocultamos ninguna de las dos.

Método 2. Usa las herramientas sin conexión

1. Carga cualquier página de herramienta de Araluma. Usa Remove Background una vez en una imagen pequeña para que el modelo ISNet en el navegador quede en caché.
2. Abre DevTools, ve a Network y marca Offline (o desactiva el Wi-Fi).
3. Recarga la página. Los assets estáticos están en caché, así que sigue cargando.
4. Prueba las herramientas:
   • Las herramientas solo-navegador siguen funcionando. Nunca necesitaron la red.
   • Descarga de Compress recurre al blob de vista previa en el navegador (una codificación algo menos eficiente, pero funcional).
   • Remove Background recurre al modelo WebAssembly ISNet y funciona sin ninguna petición saliente.

Si esas herramientas funcionaron sin conexión (algunas degradadas, las de solo-navegador idénticas), entonces por definición ningún servidor vio tu imagen.

Qué vemos nosotros, y qué no

En los caminos solo-navegador, no vemos nada sobre tu imagen. No hay ninguna petición que examinar, ninguna caché donde almacenarla, ninguna línea de log que buscar.

En los caminos que tocan el servidor:

• Descarga de Compress ve los bytes de la imagen durante el tiempo de la codificación (normalmente unos cientos de milisegundos), mantiene una entrada de caché direccionada por contenido durante su TTL, y nada más. La caché no está indexada por usuario, IP, nombre de archivo ni ningún identificador que pudiéramos usar para encontrar “tus” imágenes. No registramos el contenido de las imágenes. El servicio de codificación es compartido entre los mismos tenants que servía v1 antes del traspaso, con CORS por tenant, límites de tasa y URLs canónicas firmadas con HMAC.
• Remove Background ve la imagen durante el tiempo de la subida temporal y la llamada de segmentación (normalmente uno o dos segundos), tras lo cual la copia temporal es eliminada por la regla de ciclo de vida de R2. Nunca entregamos tus bytes a un proveedor de modelos de terceros. El modelo BiRefNet corre dentro de la infraestructura de Cloudflare, no en una API externa del estilo de remove.bg, fal.ai o Replicate.
• Escalado con IA ve la imagen durante el tiempo de la llamada de superresolución, devuelve el resultado y no retiene nada ligado a ti.

En todos los caminos, nuestro proveedor de analytics (Cloudflare Web Analytics) registra datos agregados de páginas vistas: URL, país, familia de navegador, Core Web Vitals. Sin cookies, sin identificadores persistentes, nada vinculado a una persona.

Para las herramientas que descargan un módulo WebAssembly en el primer uso (el decodificador HEIC, el modelo ISNet ONNX), nuestro proveedor de alojamiento sabe que alguien obtuvo el módulo, igual que sabe que alguien obtuvo un archivo CSS. El módulo en sí no contiene ninguna información sobre tu imagen.

El inventario completo de datos está en nuestra política de privacidad.

El stack tecnológico

Para los curiosos:

• Astro, el generador de sitios estáticos. Cada página se entrega como HTML plano con “islands” JavaScript de mejora progresiva solo donde viven las herramientas interactivas.
• CSS vanilla con propiedades personalizadas, sin Tailwind, sin CSS-in-JS. El sistema de diseño completo es un único archivo tokens.css.
• canvas.toBlob y <canvas>, la codificación JPEG, PNG, WebP y AVIF para las herramientas y vistas previas del lado del navegador.
• Cropper.js, la capa de interacción del marco de recorte.
• ONNX Runtime Web, que ejecuta el respaldo ISNet en WebAssembly para Remove Background.
• Cloudflare aloja el build estático y lo sirve desde el edge, y ejecuta los Workers, R2 y la pipeline de segmentación de imágenes (BiRefNet) detrás del camino predeterminado de Remove Background.
• Fastify con sharp y libvips en Node, el servicio de descarga de Compress en api.araluma.com, en un VPS de Hostinger en Alemania.
• Cloudflare Web Analytics, conteos de páginas vistas agregados y sin cookies.

Compatibilidad con navegadores

Cada herramienta funciona en la versión actual y la anterior de Chrome, Firefox, Safari y Edge, escritorio y móvil. El sitio usa mejora progresiva: donde un navegador soporta una API más nueva (por ejemplo showSaveFilePicker u OffscreenCanvas), la usamos, y donde no, recurrimos al equivalente más antiguo. No hay barrera de “tu navegador no está soportado”.

Los únicos requisitos imprescindibles son JavaScript (para cualquier herramienta) y una conexión de red (solo al usar un camino que toca el servidor, las herramientas solo-navegador corren por completo sin conexión tras la primera carga de página).

Preguntas

¿Algo que no hayamos cubierto? Escríbenos a support@araluma.com. Las preguntas técnicas son bienvenidas.