# Ambientes com Poucos Recursos {#low-resource-setups}
O SnapOtter roda bem em hardware modesto: um Raspberry Pi 4 ou 5, um notebook antigo ou um VPS de 2 GB. Esta página é o guia prático para essas máquinas: o que esperar, uma configuração pronta para copiar e colar com limites sensatos e quais features pular. Os dados completos de benchmark por trás desses números estão em [Requisitos de Hardware](/pt-BR/guide/deployment#hardware-requirements).
Antes de tudo, duas restrições rígidas:
- **Apenas 64 bits.** A imagem é construída para `linux/amd64` e `linux/arm64`. ARM de 32 bits (`armv7`/`armhf`) não é suportado, então os Pis de primeira geração e a família Pi Zero ficam de fora.
- **Piso de memória de 2 GB.** Com 512 MB a stack nem inicia, e 1 GB falha em lotes com vários arquivos. 2 GB com 2 núcleos é a menor configuração que funciona com folga.
## O que roda bem em hardware modesto {#what-runs-well}
Toda ferramenta sem IA funciona em uma máquina de 2 GB / 2 núcleos: as seções de Imagem e Arquivos inteiras, as ferramentas de PDF e as operações de vídeo e áudio por stream-copy (cortar, silenciar, remux de contêiner). A maioria termina em menos de um segundo.
Duas cargas de trabalho são as exceções:
- **Recodificação de vídeo** (converter entre codecs) é limitada pela CPU. Um clipe 1080p que leva ~40 s em uma CPU de desktop rápida pode levar vários minutos em uma CPU da classe do Pi. As operações de stream-copy continuam instantâneas.
- **Ferramentas de IA** precisam de RAM (4 GB recomendados) e disco (os bundles maiores têm 4-5 GB cada), e as pesadas (upscale, restauração de fotos, remoção de fundo) não são práticas em CPUs da classe do Pi. IA leve, como detecção de rosto e OCR, é utilizável se você tiver memória para isso.
Nenhuma das duas é instalada ou fica rodando a menos que você a use: sem bundles de IA instalados, o aplicativo fica ocioso em torno de 360 MB, e os bundles de IA só são baixados quando um admin os habilita.
## Passo a passo para Raspberry Pi / notebook antigo {#walkthrough}
Esta é a instalação padrão com Compose de [Primeiros Passos](/pt-BR/guide/getting-started), mais limites de recursos e tetos conservadores. Ela pressupõe um sistema operacional de 64 bits (em um Pi: Raspberry Pi OS 64-bit ou Ubuntu Server arm64).
- **Prefira um SSD USB a um cartão SD** para o volume de dados e o Postgres. As áreas de trabalho dos jobs fazem IO de disco de verdade, e cartões SD são lentos e se desgastam rápido.
- **O contêiner único tudo-em-um também funciona aqui** (Postgres e Redis embutidos quando `DATABASE_URL`/`REDIS_URL` não estão definidos), e em um host com pouca memória você deve reduzir o teto do Redis embutido com `REDIS_MAXMEMORY` (veja [Configuração](/pt-BR/guide/configuration)). O Compose dá um controle mais fino por serviço, e é por isso que este passo a passo o utiliza.
- **Adicione swap em dispositivos de 2 GB.** Isso evita que um pico ocasional (um PDF grande, um lote que você esqueceu de limitar) termine em um kill por falta de memória. zram é a opção amigável ao cartão SD.
- A imagem arm64 é apenas CPU; não há CUDA em placas ARM.
## Os ajustes disponíveis {#tuning-knobs}
Todos os limites são variáveis de ambiente, documentadas por completo em [Configuração](/pt-BR/guide/configuration). `0` significa ilimitado ou automático. Os que importam em hardware modesto:
| Variável | Sugestão para máquinas pequenas | O que protege |
|---|---|---|
| `CONCURRENT_JOBS` | `1` | Quantos jobs rodam em paralelo. A detecção automática usa o número de núcleos de CPU menos um, o que funciona bem em máquinas grandes e é agressivo demais em uma máquina de 2 núcleos sob pressão de memória. |
| `MAX_WORKER_THREADS` | `2` | Pool de threads de processamento de imagem. |
| `MAX_BATCH_SIZE` | `5` | É nos lotes que máquinas de 1-2 GB ficam sem memória primeiro. |
| `MAX_UPLOAD_SIZE_MB` | `100` | Impede que um único arquivo enorme ocupe toda a área de trabalho. |
| `MAX_MEGAPIXELS` | `50` | Decodificar uma imagem de 100+ MP custa RAM independentemente do tamanho do arquivo. |
| `MAX_VIDEO_DURATION_S` | `300` | Transcodificações longas monopolizam uma CPU pequena por minutos ou horas. |
| `PROCESSING_TIMEOUT_S` | `600` | Teto rígido para que um job descontrolado acabe liberando a máquina. |
Esses limites se aplicam ao que o servidor aceita, então defina-os de acordo com o que você realmente usa, e não com o menor valor possível. Se você nunca mexe com vídeo, um limite em `MAX_VIDEO_DURATION_S` não custa nada; se você digitaliza documentos todos os dias, não limite `MAX_PDF_PAGES`.
## O que pular {#what-to-skip}
- **Bundles de IA pesados.** Upscale, restauração de fotos e remoção de fundo pedem uma GPU ou uma CPU rápida com muitos núcleos, e cada bundle custa 4-5 GB de disco. Em uma máquina pequena, simplesmente não os instale; ferramentas cujo bundle está ausente mostram um aviso de instalação em vez de rodar.
- **Recodificação de vídeo como carga de trabalho rotineira.** Transcodificações ocasionais são aceitáveis (só são lentas); uma fila constante de transcodificação pede núcleos de CPU, não um Pi.
- **Ferramentas não usadas em geral.** Um admin pode desligar ferramentas individuais em Configurações, o que as remove da interface e deixa de registrar suas rotas de API. Isso por si só não economiza memória, mas evita que uma instância pequena compartilhada seja usada justamente para a carga de trabalho que o hardware não aguenta.
Se mais tarde você mover a instância para um hardware maior, remova os limites (defina-os de volta para `0`) e o mesmo volume de dados vai junto.
