Como o Araluma funciona

A resposta curta

O Araluma usa uma arquitetura híbrida: a maioria das ferramentas roda inteiramente no seu navegador, com zero envio, e um punhado encaminha uma única requisição de rede pela nossa própria infraestrutura quando o navegador não consegue igualar a qualidade, sempre com uma alternativa invisível no lado do cliente. Dizemos em qual caminho você está, em cada ferramenta e nesta página.

A tabela abaixo é representativa, não exaustiva (o catálogo continua crescendo). Ela mostra um exemplo de cada tipo de caminho:

Ferramenta de exemplo	Onde o trabalho acontece
Circle Crop (só no navegador)	100% no seu navegador, Canvas API. Sem envio, funciona offline.
Prévia de compressão (só no navegador)	100% no seu navegador, canvas.toBlob. Sem envio. O controle deslizante fica instantâneo.
Download de compressão (toca o servidor)	Uma ida e volta ao nosso serviço em api.araluma.com (sharp mais libvips em um VPS na Alemanha), com alternativa no navegador.
Remover Fundo (toca o servidor)	Uma ida e volta a um Cloudflare Worker rodando o BiRefNet em GPUs de borda, com alternativa em WebAssembly no seu navegador.

As ferramentas de recorte, redimensionamento, PDF e conversão de formatos (exceto o caminho de saída AVIF) ficam do lado exclusivo do navegador. Download de compressão, remoção de fundo, ampliação com IA e conversões com saída AVIF ficam do lado que toca o servidor, cada uma com uma alternativa local.

Você pode verificar as afirmações sobre o navegador em cerca de 30 segundos: abra o DevTools, vá ao painel Network, limpe o registro e então use qualquer ferramenta exclusiva do navegador. Você verá zero requisições levando os bytes da sua imagem para fora da página. Para as ferramentas que tocam o servidor, você verá exatamente um envio por operação, para os endpoints identificados acima.

Por que híbrida

A maioria das ferramentas de imagem online fica em um extremo: enviar tudo para um servidor (você espera pelas idas e voltas e o operador guarda o seu arquivo) ou tudo no navegador (você paga em qualidade e velocidade nas etapas de codificação e de IA). Nenhum dos extremos vence em todo lugar.

Escolhemos o lado do cliente sempre que os navegadores já são excelentes. O elemento <canvas> cuida do recorte, da rotação, do redimensionamento e da codificação de prévia com perdas em JPG ou WebP, e navegadores modernos decodificam todo formato comum de forma nativa. Escolhemos o lado do servidor apenas para as poucas etapas em que o navegador ainda perde de forma mensurável:

• Compressão, no download final. O sharp mais libvips no servidor produz arquivos 10 a 15% menores byte a byte do que os codificadores do navegador na mesma qualidade visual, e expõe ajustes de velocidade e croma do AVIF que o navegador não oferece. O controle deslizante e a prévia continuam rodando no seu navegador para que a iteração fique instantânea. Apenas o toque em “Download” passa pelo nosso serviço.
• Remoção de fundo com IA, no caminho padrão. O modelo BiRefNet que a segmentação de imagens da Cloudflare roda (a mesma arquitetura do remove.bg) precisa de uma GPU de verdade para terminar em um segundo ou dois. A alternativa no navegador (ISNet via ONNX Runtime mais WebAssembly) funciona, mas demora bem mais e produz um recorte visivelmente mais grosseiro em cabelo, pelo e bordas finas.
• Ampliação com IA, no caminho padrão. A super-resolução na nuvem recupera detalhes que uma reamostragem no navegador não consegue, com uma alternativa no navegador quando o serviço não está acessível.

O custo que aceitamos por estar no lado do servidor nesses caminhos é uma ida e volta por operação. O custo que evitamos por permanecer no lado do cliente em todo o resto é essa mesma taxa nas partes do fluxo que iteram mais rápido.

O pipeline, passo a passo

1. Você seleciona um arquivo

Pelo seletor de arquivos, arrastando e soltando ou colando, o navegador entrega ao JavaScript um objeto File. O JavaScript lê os bytes usando FileReader ou Blob.arrayBuffer(). Em nenhum momento desta etapa o arquivo é enviado pela rede, seja qual for a ferramenta que você esteja usando.

2. O navegador decodifica a imagem

Navegadores modernos decodificam JPG, PNG, WebP, GIF e AVIF de forma nativa. Usamos createImageBitmap() para transformar os bytes brutos em um bitmap com que a GPU pode trabalhar, fora da thread principal. Para HEIC em navegadores que não o decodificam de forma nativa, recorremos a um decodificador em WebAssembly que roda localmente no seu navegador.

3. A ferramenta faz o que tem que fazer, onde os caminhos se separam

• Ferramentas só do navegador (recorte, redimensionamento, a prévia e o controle deslizante de compressão, montagem de PDF e a maioria das conversões de formato). Elas rodam como transformações de pixels no Canvas e recodificações canvas.toBlob direto na sua máquina. O quadro de recorte interativo usa o Cropper.js. Nada sai da página.
• Download de compressão. Quando você toca em “Download”, a imagem vai uma vez para api.araluma.com (um serviço Fastify em um VPS da Hostinger na Alemanha, Node mais sharp e libvips, as mesmas bibliotecas C que o Squoosh usa no seu caminho de servidor). Ela é recodificada com os parâmetros que você definiu na prévia, e os bytes voltam em fluxo. O serviço mantém um cache isolado por inquilino e endereçado por conteúdo (um hash dos bytes de entrada mais os parâmetros), de modo que baixar de novo a mesma imagem com as mesmas configurações repete os bytes em cache. Esse cache não é indexado por você, pelo seu IP nem pelo nome do arquivo. Se o serviço estiver inacessível, a ferramenta recorre ao blob de prévia no navegador.
• Remoção de fundo, caminho padrão na nuvem. A imagem é enviada uma vez a um Cloudflare Worker, fica armazenada em um bucket R2 privado, é processada pela segmentação de imagens da Cloudflare rodando o modelo BiRefNet em GPUs de borda, e o recorte volta em fluxo. O objeto armazenado é apagado em até uma hora por uma regra de ciclo de vida do R2, qualquer que seja o resultado. Uma foto comum termina em um segundo ou dois. Limites diários por IP e de tamanho de envio mantêm o plano gratuito sustentável.
• Remoção de fundo, alternativa em WebAssembly. Se o Worker estiver inacessível (sua rede cai, um firewall rígido o bloqueia, a cota diária está cheia ou o arquivo é grande demais para o limite da nuvem), a ferramenta passa em silêncio para o modelo ISNet rodando localmente via ONNX Runtime Web e WebAssembly. A primeira execução baixa o modelo e demora mais, as execuções seguintes são mais rápidas. Sem envio nesse caminho, verificável no DevTools.
• Ampliação com IA. O caminho padrão envia a imagem uma vez a um serviço de super-resolução na nuvem e devolve o resultado ampliado em fluxo, com uma alternativa no navegador se o serviço não puder ser alcançado.

4. Você baixa o resultado

O bitmap de saída é codificado em um Blob, embrulhado em uma URL de objeto e entregue à caixa de diálogo padrão de salvar arquivo do seu navegador. O arquivo cai no seu disco.

Como verificar você mesmo

Escolha o que preferir:

Método 1. Observar a aba Network

1. Abra o Araluma em uma aba nova e abra o DevTools, depois o painel Network.
2. Use uma ferramenta só do navegador como o Circle Crop ou o controle deslizante de prévia de compressão. Você verá requisições apenas de HTML, CSS, JS e fontes, além dos módulos WebAssembly relevantes no primeiro uso. Nenhuma requisição levará os bytes da sua imagem.
3. Agora use uma ferramenta que toca o servidor como o Download de Compressão ou o Remover Fundo. Você verá exatamente um POST levando sua imagem ao endpoint identificado, e uma resposta voltando com o resultado. Passe o mouse sobre qualquer requisição para ler seu tamanho e tempo.

A coluna “Initiator” diz qual script disparou cada requisição, e a coluna “Type” diz o que foi enviado. Não escondemos nenhuma das duas.

Método 2. Usar as ferramentas offline

1. Carregue qualquer página de ferramenta do Araluma. Rode o Remover Fundo uma vez em uma imagem pequena para que o modelo ISNet no navegador fique em cache.
2. Abra o DevTools, vá em Network e marque Offline (ou desligue o Wi-Fi).
3. Recarregue a página. Os recursos estáticos estão em cache, então ela ainda carrega.
4. Experimente as ferramentas:
   • Ferramentas só do navegador continuam funcionando. Elas nunca precisaram da rede.
   • Download de Compressão recorre ao blob de prévia no navegador (uma codificação um pouco menos eficiente, mas funcional).
   • Remover Fundo recorre ao modelo ISNet em WebAssembly e funciona sem nenhuma requisição de saída.

Se essas ferramentas funcionaram offline (algumas degradadas, as só do navegador idênticas), então, por definição, nenhum servidor viu sua imagem.

O que vemos, e o que não vemos

Nos caminhos só do navegador, não vemos nada sobre sua imagem. Não há requisição para olhar, nem cache para guardá-la, nem linha de log para filtrar.

Nos caminhos que tocam o servidor:

• Download de Compressão vê os bytes da imagem durante a codificação (geralmente algumas centenas de milissegundos), mantém uma entrada de cache endereçada por conteúdo pelo seu TTL, e é só isso. O cache não é indexado por usuário, IP, nome de arquivo nem qualquer identificador que pudéssemos usar para encontrar as “suas” imagens. Não registramos o conteúdo da imagem. O serviço de codificação é compartilhado entre os mesmos inquilinos que a v1 atendia antes da migração, com CORS por inquilino, limites de taxa e URLs canônicas assinadas por HMAC.
• Remover Fundo vê a imagem durante o envio de armazenamento temporário e a chamada de segmentação (normalmente um segundo ou dois), após o que a cópia temporária é apagada pela regra de ciclo de vida do R2. Nunca entregamos seus bytes a um provedor de modelo de terceiros. O modelo BiRefNet roda dentro da própria infraestrutura da Cloudflare, não em uma API externa estilo remove.bg, fal.ai ou Replicate.
• Ampliação com IA vê a imagem durante a chamada de super-resolução, devolve o resultado e não retém nada vinculado a você.

Em todos os caminhos, nosso provedor de análise (Cloudflare Web Analytics) registra dados agregados de visualização de página: URL, país, família de navegador, Core Web Vitals. Sem cookies, sem identificadores persistentes, nada vinculado a uma pessoa.

Para ferramentas que baixam um módulo WebAssembly no primeiro uso (o decodificador HEIC, o modelo ISNet ONNX), nosso provedor de hospedagem vê que alguém buscou o módulo, do mesmo jeito que vê um arquivo CSS sendo buscado. O módulo em si não carrega nenhuma informação sobre sua imagem.

O inventário completo de dados está na nossa política de privacidade.

A pilha de tecnologia

Para os curiosos:

• Astro, o gerador de site estático. Toda página é entregue como HTML puro com “ilhas” de JavaScript progressivamente aprimoradas apenas onde existem ferramentas interativas.
• CSS puro com propriedades personalizadas, sem Tailwind, sem CSS-in-JS. Todo o sistema de design é um único arquivo tokens.css.
• canvas.toBlob e <canvas>, a codificação JPEG, PNG, WebP e AVIF para as ferramentas e prévias no lado do navegador.
• Cropper.js, a camada de interação do retângulo de recorte.
• ONNX Runtime Web, que roda a alternativa ISNet em WebAssembly para o Remover Fundo.
• Cloudflare hospeda o build estático e o serve a partir da borda, e roda os Workers, o R2 e o pipeline de segmentação de imagens (BiRefNet) por trás do caminho padrão do Remover Fundo.
• Fastify com sharp e libvips no Node, o serviço de download de compressão em api.araluma.com, em um VPS da Hostinger na Alemanha.
• Cloudflare Web Analytics, contagens agregadas e sem cookies de visualização de página.

Compatibilidade com navegadores

Toda ferramenta funciona na versão atual e na anterior do Chrome, Firefox, Safari e Edge, no desktop e no celular. O site usa aprimoramento progressivo: onde um navegador oferece uma API mais nova (por exemplo showSaveFilePicker ou OffscreenCanvas), nós a usamos, e onde não oferece, recorremos ao equivalente mais antigo. Não há nenhuma barreira de “seu navegador não é compatível”.

Os únicos requisitos rígidos são o JavaScript (para qualquer ferramenta) e uma conexão de rede (apenas ao usar um caminho que toca o servidor, as ferramentas só do navegador rodam totalmente offline depois do primeiro carregamento da página).

Dúvidas

Algo que não cobrimos? Escreva para support@araluma.com. Perguntas técnicas são bem-vindas.