Workers SSH para processamento remoto, automação e serviços headless

Esta pesquisa avalia tarefas que valem a pena transformar em workers Linux remotos, acionados principalmente por SSH e integráveis a scripts, n8n, aplicações e agentes.

Resumo executivo

O modelo é viável e, para automações pequenas e médias, costuma ser mais fácil de entender e operar do que uma plataforma de filas distribuídas ou um CI completo. O melhor desenho não oferece um shell irrestrito: cada chave SSH entra por um dispatcher com vocabulário fechado, que cria um job, limita recursos e chama uma ferramenta com argumentos já validados. A conexão devolve JSON, um arquivo em stdout ou um identificador consultável depois.

Os melhores primeiros workers são: transformação de mídia, imagens, OCR/PDF, análise tabular com DuckDB, backup, sincronização, transcrição, builds reproduzíveis e verificação defensiva de artefatos. Eles têm três propriedades em comum: trabalho finito, entrada e saída bem definidas e ferramenta CLI madura. Monitoramento contínuo e modelos de IA residentes também são úteis, mas deixam de ser exatamente “um comando por conexão” e precisam de um daemon por trás.

Para um homelab, a recomendação é começar com um worker universal controlado, não com cinco máquinas. Um mini-PC de 4 núcleos e 8–16 GB executa documentos, imagens, dados, rede e jobs leves. Mídia pesada pode usar a mesma máquina com aceleração de vídeo; IA merece worker separado apenas quando houver GPU, modelos grandes ou dados sensíveis. Quando a carga crescer, Pueue resolve a fila local de cada host e o GNU Parallel distribui lotes por SSH, sem Kubernetes.

Resultado central: SSH é excelente como transporte autenticado e auditável, mas não é a política de autorização. A política precisa estar em authorized_keys, sshd_config, dispatcher, permissões Unix, containers e limites de cgroup.

Metodologia e critérios

Foram avaliados 40 serviços por utilidade real, composição Unix, facilidade de automação, maturidade e custo operacional. A verificação de existência, atividade, linguagem e licença foi feita em documentação e repositórios oficiais em 26 de agosto de 2026. Projetos centrais como FFmpeg, libvips, Pandoc, DuckDB, Pueue, restic, Borg, whisper.cpp e llama.cpp apresentavam atividade recente e não estavam arquivados. Quando há imagem oficial ou mantida pelo projeto, isso é indicado; “Docker: fácil” significa que a CLI é simples de empacotar, não que exista imagem oficial.

As necessidades de RAM/CPU quase nunca são prometidas pelos projetos porque variam com arquivo, codec, modelo e paralelismo. Por isso, todos os números abaixo marcados como estimativa operacional são faixas conservadoras para começar, não requisitos oficiais. A maturidade considera documentação, estabilidade da interface, comunidade e histórico, não apenas estrelas.

Legenda das notas

Cada ideia recebe oito notas de 1 a 5: U utilidade prática, F facilidade de implementação, R baixo consumo de recursos, A facilidade de automação, S integração com SSH, N integração com n8n, M maturidade e P potencial de reutilização. A nota geral é a média ponderada qualitativa, privilegiando utilidade, simplicidade e segurança. 🧪 identifica ideias menos óbvias.

Ideias de workers SSH

1. Transcodificador e empacotador de vídeo

O que faz e caso real: converte gravações grandes em MP4/WebM/MKV, escala resolução, troca codecs, extrai áudio, corta/junta, faz mux/demux, adiciona hard-sub, cria HLS/DASH e proxies de edição. Um NAS envia aula.mkv; o worker devolve MP4 H.264/AAC e playlist HLS. FFmpeg é a base madura em C (LGPL 2.1+; GPL quando compilado com partes GPL), com HandBrakeCLI para presets e MKVToolNix para Matroska. yt-dlp pode ser um conector somente para conteúdo próprio/licenciado e quando o download obedecer aos termos da plataforma; não é justificativa para contornar DRM. Docker é fácil; imagens de terceiros exigem pin por digest.

SSH: rsync -P aula.mkv worker:/srv/jobs/123/in/ && ssh worker 'worker-cli media transcode 123 web-1080p'. Para entrada pipeável: cat clip.ts | ssh worker 'worker-cli media stdin mp4' > clip.mp4; nem todo container/formato aceita saída não-seekable, então arquivos grandes preferem rsync.

Automação, recursos e segurança: n8n faz upload, executa, consulta JSON e baixa o resultado. Estimativa operacional: 2–8 vCPU, 2–8 GB RAM; GPU Intel Quick Sync, NVENC ou VA-API opcional. Complexidade média. Limitar duração, pixels, codecs, tempo e disco; nunca interpolar opções livres em shell.

Avaliação: 🟢 Excelente candidato · 4,9/5 · U5 F4 R3 A5 S5 N5 M5 P5.

2. Inspeção, validação e reparo leve de mídia

O que faz e caso real: recebe um arquivo suspeito de estar truncado, gera inventário JSON de streams, codecs, duração, bitrate, loudness e erros de decodificação; tenta remux sem recodificar quando apropriado. Usa ffprobe/FFmpeg, MediaInfo (C++, BSD-2-Clause) e MKVToolNix. A saída estruturada é ótima para decidir automaticamente se transcodificar, rejeitar ou apenas remuxar.

SSH: ssh worker 'worker-cli media probe --json' < video.mkv > report.json; remux usa arquivo no workspace. Automação: n8n ramifica pelo código de saída e pelos campos JSON. Estimativa operacional: 1–2 vCPU, 256 MB–2 GB; análise completa cresce com o arquivo. Docker fácil; maturidade alta. Complexidade baixa.

Segurança: parsers de mídia processam entrada hostil; execute sem rede, usuário não root, sistema de arquivos somente no job e timeout. “Reparar” não recupera conteúdo ausente e deve preservar o original.

Avaliação: 🟢 · 4,7/5 · U5 F5 R4 A5 S5 N5 M5 P4.

3. Fábrica de previews, thumbnails, GIFs e contact sheets

O que faz e caso real: extrai frames por intervalo ou cena, produz miniaturas, sprites para player, GIF/WebP animado, waveform, espectrograma e folha de contato para catalogar vídeos. Combina filtros documentados do FFmpeg, ImageMagick e montage. Útil para DAM, acervo escolar ou aprovação de edição sem baixar o vídeo inteiro.

SSH: ssh worker 'worker-cli media preview JOB --interval 60 --format webp'; saída pode ser TAR em stdout. Automação: webhook cria job e publica artefatos no S3. Estimativa operacional: 2–4 vCPU, 512 MB–4 GB; GPU raramente necessária. Docker fácil, complexidade baixa.

Segurança: imponha limite de frames, dimensão e duração; o ImageMagick recomenda políticas de recursos para evitar exaustão e pode bloquear codificadores como PDF/PS.

Avaliação: 🟢 · 4,7/5 · U5 F5 R4 A5 S5 N5 M5 P5.

4. Normalização, limpeza e conversão de áudio

O que faz e caso real: padroniza WAV/FLAC/MP3/Opus, resampleia, divide por silêncio, remove canais, gera espectrogramas e aplica normalização EBU R128. SoX é a ferramenta Unix clássica; o filtro loudnorm suporta modos de uma e duas passagens. Exemplo: nivelar 200 entrevistas antes de publicar podcast.

SSH: cat entrada.wav | ssh worker 'worker-cli audio normalize wav' > saida.wav. Automação: um nó SSH do n8n dispara lote e lê medições JSON. Estimativa operacional: 1–4 vCPU, 256 MB–2 GB; CPU apenas. Docker fácil, complexidade baixa.

Segurança: presets fixos e limites de duração/tamanho; mantenha masters porque normalização e filtros alteram amostras.

Avaliação: 🟢 · 4,6/5 · U5 F5 R5 A5 S5 N5 M5 P4.

5. Conversão e otimização de imagens em lote

O que faz e caso real: redimensiona, corrige orientação, muda JPEG/PNG/WebP/AVIF/TIFF, comprime e gera derivados. libvips (C, LGPL-2.1+) trabalha bem em streaming e costuma ser eficiente; ImageMagick oferece ecossistema maior; GraphicsMagick é alternativa conservadora. Um e-commerce envia diretório e recebe tamanhos responsivos.

SSH: ssh worker 'worker-cli image web-variants JOB'; para operação simples, cat foto.jpg | ssh worker 'vipsthumbnail stdin --size 1600x1600 -o .jpg[Q=82]' > foto-web.jpg. Estimativa operacional: 1–8 vCPU, 256 MB–4 GB; depende de pixels e concorrência. Docker fácil, complexidade baixa.

Segurança: limite largura×altura, frames e memória; bloqueie delegados desnecessários e URL remota na policy do ImageMagick.

Avaliação: 🟢 · 4,9/5 · U5 F5 R4 A5 S5 N5 M5 P5.

6. Extração, auditoria e saneamento de metadados

O que faz e caso real: inventaria EXIF/IPTC/XMP, GPS, câmera, timestamps e tags de documentos; remove dados pessoais antes da publicação e organiza fotos por data. ExifTool (Perl, Artistic/GPL) lê muitos formatos, entrega JSON e aceita stdin. O próprio autor alerta que apagar tags de PDF não remove necessariamente os bytes antigos e que perfis de cor podem ser necessários; para PDF sensível, renderização/reconstrução controlada é mais segura.

SSH: ssh worker 'worker-cli metadata inspect --json' < foto.jpg; saneamento devolve novo arquivo, nunca sobrescreve o original. Estimativa operacional: 1 vCPU, 128–512 MB. Docker fácil, complexidade baixa.

Segurança: allowlist de formatos/tags, cópia imutável e validação posterior; não prometer anonimização total apenas com -all=.

Avaliação: 🟢 · 4,8/5 · U5 F5 R5 A5 S5 N5 M5 P5.

7. OCR e PDF pesquisável

O que faz e caso real: converte digitalizações em PDF com camada de texto, deskew, rotação e PDF/A, mantendo imagem original quando possível. OCRmyPDF (Python, MPL-2.0) integra Tesseract, qpdf e Ghostscript; tem imagens Docker oficiais e documenta docker ... - - <input.pdf >output.pdf como caminho portátil. Exemplo: tornar pesquisável um arquivo de notas fiscais.

SSH: cat scan.pdf | ssh worker 'worker-cli pdf ocr --lang por' > pesquisavel.pdf. Automação: n8n envia PDF, recebe exit code e texto lateral. Estimativa operacional: 2–8 vCPU, 2–8 GB RAM e temporário proporcional aos pixels; a documentação alerta que usa todos os cores se não limitado. Complexidade média.

Segurança: --jobs, limite de páginas/pixels, container efêmero sem rede e validação qpdf; documentos confidenciais não devem ir a APIs externas.

Avaliação: 🟢 · 4,9/5 · U5 F4 R3 A5 S5 N5 M5 P5.

8. Reparo, otimização, divisão e inspeção de PDF

O que faz e caso real: lineariza para web, verifica estrutura, descriptografa somente com senha autorizada, divide/junta, remove páginas, comprime streams e corrige tabelas xref. qpdf (C++, Apache-2.0) é excelente para transformação estrutural; MuPDF/mutool e Ghostscript cobrem renderização e otimização. Exemplo: validar PDFs recebidos e gerar versão web.

SSH: arquivos pequenos aceitam pipe; operações multi-arquivo usam SCP/workspace. Estimativa operacional: 1–4 vCPU, 256 MB–4 GB; renderização cresce com pixels. Docker fácil; maturidade alta, complexidade baixa/média.

Segurança: PDF é entrada ativa complexa; desative rede, JavaScript e acesso fora do job, imponha timeout e nunca use senha na linha de comando/log.

Avaliação: 🟢 · 4,7/5 · U5 F5 R4 A5 S5 N5 M5 P5.

9. Conversor universal de documentos e ebooks

O que faz e caso real: converte Markdown, HTML, DOCX, ODT, EPUB, LaTeX e outros formatos; aplica templates e gera manuais ou apostilas. Pandoc (Haskell, GPL-2.0) é o núcleo; LibreOffice em modo --headless cobre documentos Office; ebook-convert do Calibre trata ebooks. Exemplo: gerar DOCX, EPUB e HTML do mesmo Markdown versionado.

SSH: cat livro.md | ssh worker 'worker-cli doc convert --from gfm --to epub' > livro.epub. Estimativa operacional: Pandoc 1 vCPU/128–512 MB; LibreOffice/LaTeX 1–4 vCPU e 1–4 GB. Docker fácil, complexidade média por causa de fontes/templates.

Segurança: filtros Lua e templates são código; só use catálogo administrado. Macros Office ficam desabilitadas e a saída passa por validação.

Avaliação: 🟢 · 4,8/5 · U5 F4 R4 A5 S5 N5 M5 P5.

10. Extração de texto e estrutura de documentos

O que faz e caso real: transforma PDFs, Office, emails e arquivos em texto/JSON para indexação, classificação ou IA. Apache Tika (Java, Apache-2.0) detecta e extrai metadados/conteúdo de muitos formatos; pdftotext/Poppler e antiword são opções menores. Exemplo: alimentar busca interna com milhares de anexos.

SSH: cat contrato.docx | ssh worker 'worker-cli extract text --mime application/vnd.openxmlformats-officedocument.wordprocessingml.document' > contrato.txt. Estimativa operacional: Tika 1–4 vCPU e 512 MB–4 GB; Poppler 128 MB–1 GB. Docker oficial disponível para Tika, complexidade média.

Segurança: desabilite parsers externos e recursão excessiva, limite ZIP aninhado, páginas e memória; nunca permita que conteúdo extraído vire prompt/comando confiável.

Avaliação: 🟢 · 4,6/5 · U5 F4 R3 A5 S5 N5 M5 P5.

11. Arquivamento, recompressão e validação de pacotes

O que faz e caso real: cria/extrai TAR, ZIP, 7z, zstd, gzip e xz; recomprime acervos, lista conteúdo sem extrair e testa integridade. bsdtar, 7-Zip, zstd e pigz são maduros; archives oferece biblioteca/CLI moderna em Go (MIT). Exemplo: receber diretório via rsync e devolver .tar.zst com manifesto SHA-256.

SSH: tar -C pasta -cf - . | ssh worker 'worker-cli archive zstd' > pacote.tar.zst. Estimativa operacional: 1–8 vCPU, 128 MB–4 GB conforme nível e dicionário; Docker fácil. Complexidade baixa.

Segurança: bloqueie path traversal, links absolutos, device nodes e “zip bombs”; extraia em diretório efêmero com quota e conte tamanho descompactado antes de promover.

Avaliação: 🟢 · 4,8/5 · U5 F5 R5 A5 S5 N5 M5 P5.

12. Identificação e triagem de arquivos desconhecidos 🧪

O que faz e caso real: calcula hashes, detecta MIME por conteúdo, lista strings, entropia, cabeçalhos e metadados sem abrir o arquivo em desktop. Usa file/libmagic, sha256sum, xxd, strings, ExifTool e TrID quando desejado. Exemplo: um sistema recebe upload sem extensão e precisa decidir qual pipeline aceitar.

SSH: cat blob | ssh worker 'worker-cli inspect file --json'. Estimativa operacional: 1 vCPU, 128–512 MB; Docker fácil. Complexidade baixa.

Segurança: é triagem, não prova de inocuidade. Nunca execute o arquivo; faça leitura somente, limite bytes inspecionados e trate nome/MIME fornecidos pelo cliente como não confiáveis.

Avaliação: 🟢 · 4,7/5 · U5 F5 R5 A5 S5 N5 M5 P5.

13. Deduplicação, hashing e inventário de armazenamento 🧪

O que faz e caso real: encontra duplicatas por tamanho+hash, gera manifestos, mede espaço e compara árvores antes de apagar. fclones (Rust, MIT) e jdupes são rápidos; hashdeep gera auditorias. Exemplo: identificar cópias duplicadas em duas bibliotecas sem executar remoção automática.

SSH: ssh worker 'worker-cli storage duplicates /data/media --json'. Estimativa operacional: 1–8 vCPU, 256 MB–2 GB; I/O e disco dominam. Instalação nativa é preferível para acesso ao filesystem; complexidade baixa.

Segurança: modo inicial sempre read-only; não exponha /; allowlist de mounts e operação destrutiva separada com aprovação. Hash igual é evidência forte, mas caminho e metadados ainda precisam ser preservados.

Avaliação: 🟢 · 4,5/5 · U5 F5 R4 A4 S5 N4 M4 P5.

14. Diff semântico e forense de artefatos 🧪

O que faz e caso real: compara diretórios, arquivos compactados, pacotes e binários decompondo-os; útil para responder “o que mudou entre estes builds?”. diffoscope (Python, GPL-3.0+) gera HTML/texto e invoca comparadores especializados; difftastic (Rust, MIT) entende sintaxe de código. Exemplo: verificar se duas compilações diferem apenas em timestamp.

SSH: SCP dos dois artefatos e ssh worker 'worker-cli diff artifacts JOB --html'. Estimativa operacional: 2–8 vCPU, 1–8 GB e muito temporário para pacotes grandes. Docker útil para congelar dependências; complexidade média.

Segurança: ferramentas auxiliares processam conteúdo hostil; container sem rede, limites de recursão e tempo, relatório HTML tratado como conteúdo não confiável.

Avaliação: 🟡 Interessante · 4,1/5 · U4 F3 R2 A4 S4 N4 M5 P4.

15. Captura reprodutível de páginas, screenshot e PDF

O que faz e caso real: carrega uma URL em Chromium headless, espera seletor, define viewport, captura PNG/PDF e registra console/HTTP. Playwright (TypeScript, Apache-2.0) mantém navegadores e imagem Docker; Chromium também imprime PDF. Exemplo: gerar comprovante visual diário de uma página interna.

SSH: ssh worker 'worker-cli web capture --url-id 42 --profile desktop'; URL vem de cadastro, não de argumento livre. Estimativa operacional: 2–4 vCPU, 1–4 GB por navegador; Docker oficial, complexidade média.

Segurança: risco de SSRF. Bloqueie loopback, metadata cloud e redes privadas salvo allowlist explícita; DNS precisa ser revalidado após resolução e redirects; execute navegador em sandbox/container sem credenciais.

Avaliação: 🟢 · 4,6/5 · U5 F4 R3 A5 S5 N5 M5 P5.

16. Auditoria de desempenho e qualidade web

O que faz e caso real: executa Lighthouse, coleta Core Web Vitals de laboratório, acessibilidade, SEO e boas práticas; armazena HTML/JSON para comparação. Lighthouse (JavaScript, Apache-2.0) tem CLI e imagem/container facilmente reproduzível. Exemplo: n8n testa páginas após deploy e bloqueia regressão grave. Para comparar versões de uma CLI/site de forma repetível, hyperfine mede várias execuções com aquecimento e exporta JSON/Markdown.

SSH: ssh worker 'worker-cli web lighthouse --site catalogo --preset mobile' > report.json. Estimativa operacional: 2–4 vCPU, 1–3 GB por job; complexidade média.

Segurança: mesma proteção SSRF do worker de captura, concorrência baixa e timeout; pontuação de laboratório varia, portanto compare mediana de execuções e não trate um número como verdade absoluta.

Avaliação: 🟢 · 4,5/5 · U5 F4 R3 A5 S5 N5 M5 P4.

17. Verificador de links e redirects

O que faz e caso real: extrai URLs de Markdown/HTML, checa status, redirects, fragmentos e produz relatório de links mortos. lychee (Rust, Apache-2.0/MIT) é assíncrono, stream-based, possui binários, Docker e saída adequada a CI. Exemplo: validar um site estático inteiro antes de publicar.

SSH: tar -cf - site | ssh worker 'worker-cli web links --stdin-tar --json' > links.json. Estimativa operacional: 1–2 vCPU, 128 MB–1 GB; rede domina. Docker oficial, complexidade baixa.

Segurança: allowlist de esquemas, bloqueio de IPs internos, taxa/concorrência moderadas, user-agent identificável e respeito a termos; não transformar em crawler agressivo.

Avaliação: 🟢 · 4,8/5 · U5 F5 R5 A5 S5 N5 M5 P5.

18. Arquivamento de páginas autocontidas 🧪

O que faz e caso real: baixa uma página autorizada e empacota HTML, CSS e assets em um único arquivo para pesquisa, evidência ou leitura offline. monolith (Rust, CC0-1.0) é pequeno e focado; wget --page-requisites é alternativa clássica. Exemplo: guardar documentação externa usada por um projeto junto do snapshot da licença.

SSH: ssh worker 'worker-cli web archive --url-id 17' > pagina.html. Estimativa operacional: 1 vCPU, 128 MB–1 GB. Docker fácil, complexidade baixa.

Segurança: respeitar copyright, robots/termos quando aplicáveis, limites de tamanho e SSRF; conteúdo arquivado continua ativo, então servir com CSP forte ou como download, nunca no mesmo domínio de administração.

Avaliação: 🟡 · 4,2/5 · U4 F5 R5 A5 S5 N4 M4 P4.

19. Diagnóstico HTTP, DNS, TLS e RDAP

O que faz e caso real: resolve A/AAAA/MX/TXT, segue redirects, mede tempos de HTTP, inspeciona certificado/cadeia/SNI/ALPN e consulta RDAP. curl, kdig/dig, openssl s_client e RDAP compõem um worker quase sem estado. Exemplo: entregar JSON explicando por que um domínio não abre de três redes diferentes.

SSH: ssh net-worker 'worker-cli net diagnose --target site-cadastrado --json'. Estimativa operacional: 1 vCPU, 128–512 MB; Docker ou nativo, complexidade baixa.

Segurança: apenas alvos cadastrados/autorizados, taxa limitada, sem opção de comando arbitrário; não exponha respostas internas a clientes externos. Para certificado, capture data e cadeia, não chaves.

Avaliação: 🟢 · 4,9/5 · U5 F5 R5 A5 S5 N5 M5 P5.

20. Latência, rota e throughput autorizado

O que faz e caso real: roda ping, traceroute/MTR e teste de banda entre pontos próprios. MTR combina traceroute/ping; iperf3 mede TCP/UDP/SCTP e fornece JSON/JSON-stream. Exemplo: comparar VPS, escritório e casa antes/depois de mudança de rota.

SSH: ssh net-worker 'worker-cli net mtr site-a --cycles 20 --json'; iperf só contra endpoints autorizados. Estimativa operacional: 1 vCPU, 128–512 MB; throughput consome a própria banda. Nativo é mais simples; complexidade baixa.

Segurança: allowlist de destinos, duração e banda; capabilities mínimas para ICMP/captura, nunca container privilegiado genérico; testes ativos podem afetar produção.

Avaliação: 🟢 · 4,7/5 · U5 F5 R5 A5 S5 N5 M5 P4.

21. Análise offline de PCAP e evidência de rede

O que faz e caso real: recebe captura feita legalmente, filtra protocolos, extrai campos, conversas e estatísticas em CSV/JSON. TShark usa os dissecadores do Wireshark e aceita PCAP/PCAPNG inclusive por stdin em formatos compatíveis. Exemplo: descobrir retransmissões e falhas DNS em uma captura do próprio ambiente.

SSH: cat incidente.pcapng | ssh net-worker 'worker-cli pcap summarize --profile dns-http' > relatorio.json. Estimativa operacional: 2–8 vCPU, 1–8 GB conforme captura; Docker bom para análise, captura ao vivo deve ficar separada e minimamente privilegiada. Complexidade média.

Segurança: PCAP pode conter senhas, cookies e dados pessoais; criptografia em repouso, retenção curta, acesso por função e log. Captura somente em redes próprias/autorizadas.

Avaliação: 🟢 · 4,5/5 · U5 F4 R3 A5 S5 N5 M5 P4.

22. Monitor sintético sob demanda e por localidade

O que faz e caso real: um comando testa HTTP, TCP, DNS e certificado a partir de cada VPS e devolve estado/latência; timers fazem execução periódica. curl, promtool, Gatus (Go, Apache-2.0) ou scripts pequenos cobrem perfis distintos. O mesmo host pode receber logs próprios, resumir status/códigos com jq/awk ou gerar relatório HTML com GoAccess, sem virar stack de observabilidade. Exemplo: confirmar se indisponibilidade é global ou apenas de um provedor.

SSH: ssh worker-eu 'worker-cli check service api-prod --json'. Automação: n8n consulta três regiões em paralelo; systemd timer guarda séries pequenas. Estimativa operacional: CLI 64–256 MB; Gatus 128 MB–1 GB conforme checks. Docker disponível, complexidade baixa/média.

Segurança: catálogo de destinos, segredo separado por check, redigir cabeçalhos e não permitir proxy/redirect para rede interna.

Avaliação: 🟢 · 4,6/5 · U5 F5 R5 A5 S5 N5 M4 P4.

23. Transformação Unix de JSON, YAML, XML e texto 🧪

O que faz e caso real: filtra, valida, reestrutura e converte pequenos documentos sem escrever aplicação. jq (C, MIT), yq (Go, MIT), xq e dasel são composáveis. Exemplo: receber JSON de API, extrair campos, combinar com YAML e devolver NDJSON.

SSH: curl ... | ssh worker 'worker-cli transform jq customer-public-v2' > saida.json. O filtro é um ID pré-instalado, não texto fornecido pelo cliente. Estimativa operacional: 1 vCPU, 32–512 MB; Docker ou binários únicos. Complexidade baixa.

Segurança: tamanho/profundidade limitados; não aceitar eval, imports ou caminho arbitrário. Use esquema de entrada e JSON no protocolo.

Avaliação: 🟢 · 4,9/5 · U5 F5 R5 A5 S5 N5 M5 P5.

24. Limpeza e conversão tabular com Miller/qsv

O que faz e caso real: seleciona, ordena, agrupa, junta, valida e converte CSV/TSV/JSON/NDJSON em streaming. Miller (Go, BSD-2-Clause) tem linguagem própria; qsv (Rust, dual MIT/Unlicense em componentes) oferece dezenas de subcomandos. xsv é popular, mas seu repositório foi arquivado; em projeto novo, prefira qsv/Miller.

SSH: cat vendas.csv | ssh worker 'worker-cli table clean vendas-v3' > vendas-limpo.csv. Estimativa operacional: 1–4 vCPU, 64 MB–2 GB; depende de sort/join. Docker fácil, complexidade baixa.

Segurança: presets versionados, limites de linha/campo, CSV formula injection ao exportar para planilha e encoding validado.

Avaliação: 🟢 · 4,8/5 · U5 F5 R5 A5 S5 N5 M5 P5.

25. SQL analítico local sobre CSV, JSON e Parquet 🧪

O que faz e caso real: executa consultas, joins, agregações e conversões sem servidor de banco. DuckDB (C++, MIT) lê CSV/JSON/Parquet, trabalha em memória ou arquivo e documenta /dev/stdin e /dev/stdout. Exemplo: resumir 20 GB de Parquet no NVMe do worker e devolver CSV de 2 MB.

SSH: cat dados.csv | ssh worker 'worker-cli data query relatorio-mensal' > resultado.csv. Estimativa operacional: 2–8 vCPU, 1–16 GB e temporário; threads e memory_limit devem ser configurados. Docker oficial, complexidade baixa/média.

Segurança: consultas são templates parametrizados; extensões e acesso externo desabilitados por padrão. O safe mode bloqueia leitura externa, mas também impede esse pipeline, portanto isolamento por workspace/container continua necessário.

Avaliação: 🟢 · 5,0/5 · U5 F5 R4 A5 S5 N5 M5 P5.

26. Validação de datasets e contratos de dados

O que faz e caso real: verifica tipos, campos obrigatórios, unicidade, faixa, regex, chaves e estatísticas antes de importar. Frictionless Framework (Python, MIT) valida Data Package/CSV; JSON Schema com check-jsonschema cobre JSON/YAML; Great Expectations é mais pesado. Exemplo: bloquear planilha de fornecedor quando colunas mudam.

SSH: cat lote.csv | ssh worker 'worker-cli validate fornecedor-x/v4' > resultado.json. Estimativa operacional: 1–4 vCPU, 256 MB–4 GB. Docker fácil, complexidade média.

Segurança: schemas somente administrativos, amostras de erro redigidas para não vazar dados e limites para regex catastrófica/arquivos gigantes.

Avaliação: 🟢 · 4,6/5 · U5 F4 R4 A5 S5 N5 M4 P5.

27. ETL leve e relatórios reproduzíveis

O que faz e caso real: encadeia download autorizado, limpeza, consulta DuckDB, gráfico e entrega HTML/PDF/CSV. Python com Polars/Pandas, Quarto e scripts make/just são suficientes. Exemplo: consolidar exportações de três sistemas toda madrugada.

SSH: ssh data-worker 'worker-cli pipeline run faturamento --input-job 123'; retorno imediato é ID e status vem depois. Estimativa operacional: 2–8 vCPU, 2–16 GB conforme dataset. Container por pipeline, complexidade média.

Segurança: ambientes travados por lockfile, segredos injetados por arquivo/credential store, saída sem células fórmulas perigosas e logs sem dados pessoais.

Avaliação: 🟢 · 4,7/5 · U5 F4 R3 A5 S5 N5 M5 P5.

28. Build machine simples para Go, Rust, Node e C/C++

O que faz e caso real: recebe commit/tarball, compila, testa, faz lint e devolve artefatos/checksums. Toolchains oficiais, make, just e containers substituem CI pesado em equipes pequenas. Exemplo: compilar binários Linux ARM64 numa máquina mais forte sem instalar Rust no notebook.

SSH: git archive HEAD | ssh build-worker 'worker-cli build projeto-x linux-arm64' > artifact.tar.zst. Estimativa operacional: 4–16 vCPU, 8–32 GB, NVMe; depende do projeto. Docker/Podman recomendado, complexidade média.

Segurança: build é execução de código não confiável. Use container/VM sem segredos e sem socket Docker, rede bloqueada ou allowlist, limites e usuário efêmero. Nunca compile PR externo no mesmo contexto que chaves de release.

Avaliação: 🟢 · 4,8/5 · U5 F4 R2 A5 S5 N5 M5 P5.

29. Cache e compilação distribuída 🧪

O que faz e caso real: evita recompilar objetos iguais e distribui compilações. sccache (Rust, Apache-2.0) suporta C/C++, Rust, CUDA/HIP, caches locais/remotos e modo distribuído autenticado; a documentação de distribuição usa scheduler e build servers, portanto já ultrapassa “SSH+script”. distcc é mais simples para C/C++.

SSH: SSH ainda provisiona, reinicia e coleta status, mas o caminho quente usa protocolo próprio. Para poucos builds, ssh worker cargo build + cache local é mais simples. Estimativa operacional: daemon leve em idle; 4–32 vCPU, 4–32 GB e cache 10+ GB em carga. Complexidade média/alta.

Segurança: TLS/autenticação, toolchains fixas, sandbox do servidor e cache sem segredos. Não exponha scheduler publicamente sem proteção.

Avaliação: 🟡 · 4,0/5 · U4 F2 R4 A4 S3 N3 M5 P5.

30. Geração de releases, changelogs e documentação

O que faz e caso real: renderiza MkDocs/Sphinx/Doxygen, produz manpages, changelog e pacote versionado. MkDocs, Sphinx, Doxygen e git-cliff são maduros. Exemplo: a cada tag, devolver site estático, PDF e notas de versão.

SSH: git archive v1.4 | ssh build-worker 'worker-cli docs projeto-x' > site.tar.zst. Estimativa operacional: 1–4 vCPU, 512 MB–4 GB; LaTeX pode exigir mais disco/RAM. Docker ótimo para fontes/dependências, complexidade média.

Segurança: plugins e temas executam código; somente versões pinadas, sem token de publicação dentro do job. Assinatura/publicação é etapa separada.

Avaliação: 🟢 · 4,5/5 · U5 F4 R4 A5 S5 N5 M5 P4.

31. Transcrição, legendas e diarização local

O que faz e caso real: transforma áudio/vídeo em texto, SRT/VTT e timestamps sem enviar conteúdo à nuvem. whisper.cpp (C/C++, MIT) roda em CPU e suporta CUDA, Vulkan, ROCm e Metal; faster-whisper é alternativa Python/CTranslate2. Exemplo: gerar rascunho de legenda de aulas e entrevistas para revisão humana.

SSH: upload por rsync e ssh ai-worker 'worker-cli speech transcribe JOB --model small --lang pt --format vtt'. Estimativa operacional: modelo pequeno em CPU, 4–8 vCPU e 4–8 GB; modelos grandes/GPU podem exigir 8–16 GB RAM e VRAM compatível. Docker disponível, complexidade média.

Segurança: mídia confidencial permanece local; modelos pinados, workspace cifrado/efêmero e revisão humana. Nomes, pontuação e falantes podem estar errados.

Avaliação: 🟢 · 4,8/5 · U5 F4 R3 A5 S5 N5 M5 P5.

32. Embeddings, classificação e sumarização com LLM local

O que faz e caso real: gera vetores, classifica tickets/documentos, extrai JSON e resume lotes em máquina própria. llama.cpp (C/C++, MIT) oferece CLI, CPU/GPU, modelos quantizados e servidor com endpoints de chat/embeddings; Ollama simplifica gerenciamento. Exemplo: n8n envia texto redigido e recebe categoria JSON.

SSH: para lotes finitos, ssh ai-worker 'worker-cli llm classify support-v3' < texto.txt; para alta frequência, SSH apenas cria túnel/aciona job e um daemon local atende. Estimativa operacional: 8–32 GB RAM ou 8–24+ GB VRAM conforme modelo/contexto. Docker disponível; complexidade média/alta.

Segurança: modelo não é autoridade e saída é não confiável; schema estrito, limite de contexto, sem ferramentas arbitrárias, prompt injection tratada como dado. Licença do modelo é separada da licença do runtime.

Avaliação: 🟡 · 4,2/5 · U5 F3 R1 A5 S4 N5 M4 P5.

33. Classificação, OCR visual e deduplicação perceptual

O que faz e caso real: etiqueta imagens, detecta objetos em acervo próprio, calcula embeddings/pHash e encontra imagens visualmente semelhantes. ONNX Runtime, OpenCV e modelos CLIP/YOLO adequadamente licenciados são opções; o runtime pode ser aberto, mas pesos e datasets têm licenças próprias. Exemplo: separar recibos, screenshots e fotos em pastas de revisão.

SSH: rsync do lote e ssh ai-worker 'worker-cli vision classify JOB catalog-v2' > labels.json. Estimativa operacional: CPU 4–16 vCPU/4–16 GB para lote pequeno; GPU 8+ GB VRAM acelera. Docker recomendado; complexidade alta para calibrar.

Segurança: não usar reconhecimento biométrico ou decisões sensíveis sem base legal e revisão; guardar score, modelo e versão. Imagens não confiáveis ficam isoladas.

Avaliação: 🟡 · 3,9/5 · U4 F2 R2 A4 S4 N5 M4 P4.

34. Antimalware e regras YARA defensivas

O que faz e caso real: escaneia anexos e arquivos com ClamAV (C/C++, GPL-2.0) e regras YARA (C, BSD-3-Clause), entregando JSON e quarentena. Exemplo: analisar upload antes de importá-lo ao armazenamento corporativo.

SSH: cat upload | ssh scan-worker 'worker-cli security malware --profile uploads' > result.json; o arquivo não volta se política bloquear. Estimativa operacional: clamscan 1–4 GB e mais lento; clamd mantém base em RAM para maior frequência. Docker oficial comunitário/projeto, complexidade média.

Segurança: scanner reduz risco, não prova segurança; base atualizada, arquivo nunca executado, quarentena sem servir conteúdo, logs sem material sensível. YARA de terceiros passa por revisão para evitar lentidão/vazamento.

Avaliação: 🟢 · 4,7/5 · U5 F4 R3 A5 S5 N5 M5 P5.

35. SBOM, vulnerabilidades, segredos e análise de imagens

O que faz e caso real: gera SBOM SPDX/CycloneDX, compara pacotes com CVEs, procura segredos e inspeciona camadas de container. Syft e Grype (Go, Apache-2.0), Trivy (Go, Apache-2.0), Gitleaks (Go, MIT) e dive compõem o worker. Syft escreve SBOM em stdout e Grype aceita SBOM por pipe.

SSH: tar -cf - projeto | ssh scan-worker 'worker-cli security sbom-scan --stdin-tar' > report.json. Estimativa operacional: 2–8 vCPU, 1–8 GB e cache de bases. Docker oficial, complexidade média.

Segurança: atualize bases, trate achado como sinal a validar, redija segredos do relatório e nunca passe socket Docker; prefira OCI tar enviado por arquivo.

Avaliação: 🟢 · 4,8/5 · U5 F4 R3 A5 S5 N5 M5 P5.

36. Cofre de backup deduplicado via SSH

O que faz e caso real: recebe backups criptografados/deduplicados, verifica repositórios, aplica retenção e restaura sob demanda. restic (Go, BSD-2-Clause) suporta repositório SFTP; Borg (Python/Cython, BSD-3-Clause) possui protocolo borg serve via SSH e restrição a repositório/quota. Exemplo: VPS envia snapshot noturno ao NAS sem ganhar shell nele.

SSH: Borg recomenda command="borg serve --restrict-to-repository /srv/borg/vps1",restrict; restic usa sftp:user@host:/srv/restic. Estimativa operacional: 1–4 vCPU, 1–4 GB, disco conforme retenção; sem Docker é mais simples para permissões. Complexidade média.

Segurança: chave exclusiva, repo exclusivo, cópia offline/imutável e teste de restore. --append-only de Borg é proteção de baixo nível e não substitui snapshot do storage.

Avaliação: 🟢 · 5,0/5 · U5 F4 R4 A5 S5 N4 M5 P5.

37. Sincronização, replicação e movimentação entre nuvens

O que faz e caso real: replica árvores por rsync, move objetos com rclone (Go, MIT), verifica hashes e espelha S3. Exemplo: puxar uploads da VPS, verificar e enviar cópia criptografada a storage S3.

SSH: rsync -a --partial --append-verify retoma grandes arquivos; rrsync restringe chave a um diretório e modos read/write/no-delete. Estimativa operacional: 1–4 vCPU, 256 MB–2 GB; rede/disco dominam. Nativo, complexidade baixa/média.

Segurança: rclone config contém credenciais; permissões 0600/secret store, remotes mínimos e log redigido. Leia a ressalva do rrsync sobre bash e diretório gravável; “sync” pode apagar, portanto comece com copy/dry-run/versionamento.

Avaliação: 🟢 · 4,9/5 · U5 F5 R5 A5 S5 N5 M5 P5.

38. Criptografia e assinatura de artefatos 🧪

O que faz e caso real: cifra para destinatários e assina/valida releases sem montar serviço web. age (Go, BSD-3-Clause) é composável por stdin/stdout; minisign (C, ISC) faz assinaturas pequenas. Exemplo: pipeline gera backup, cifra com chave pública do cofre e assina manifesto.

SSH: cat arquivo | ssh crypto-worker 'worker-cli crypto encrypt backup-team' > arquivo.age. Assinatura privada deve ocorrer em worker mais protegido e só sobre hash/artefato aprovado. Estimativa operacional: 1 vCPU, 64–256 MB. Docker ou binário estático; complexidade baixa.

Segurança: idealmente chaves privadas não atravessam SSH; destinatários são IDs allowlisted. Sem eval, sem senha em argumento/log, rotação e recuperação documentadas.

Avaliação: 🟢 · 4,6/5 · U5 F5 R5 A5 S5 N4 M5 P4.

39. Renderizador técnico, códigos e assets tipográficos 🧪

O que faz e caso real: converte DOT/Mermaid/Typst em SVG/PDF/PNG, gera QR/barcodes e cria subset WOFF2 de fontes. Graphviz, Mermaid CLI, Typst, qrencode/zbar e FontTools pyftsubset formam uma pequena “gráfica Unix”. Exemplo: documentação envia diagrama e caracteres usados; recebe SVG e fonte web mínima.

SSH: cat arquitetura.dot | ssh worker 'worker-cli render graphviz svg' > arquitetura.svg. Estimativa operacional: Graphviz/FontTools 1–2 vCPU e 128 MB–1 GB; Mermaid/Chromium 1–2 GB. Docker fácil, complexidade baixa/média.

Segurança: fontes têm licença própria; SVG/HTML pode conter conteúdo ativo, sanitize antes de publicar. Limite nós, tamanho e tempo de layout; QR decodificado é dado, não URL a abrir automaticamente.

Avaliação: 🟢 · 4,5/5 · U4 F4 R4 A5 S5 N5 M5 P5.

40. Conversão e análise geoespacial com GDAL 🧪

O que faz e caso real: converte GeoJSON, Shapefile, GeoPackage, KML e raster; reprojeta, recorta, junta camadas e gera tiles/estatísticas. GDAL/OGR (C/C++, MIT) é a infraestrutura madura; ogr2ogr e gdal_translate são excelentes CLIs. Exemplo: receber GeoJSON municipal, validar CRS e devolver GeoPackage simplificado.

SSH: cat dados.geojson | ssh geo-worker 'worker-cli geo vector geojson-to-gpkg' > dados.gpkg; transformações que precisam seek usam workspace. Estimativa operacional: 2–8 vCPU, 1–16 GB e temporário conforme raster. Imagens Docker oficiais do projeto existem; complexidade média.

Segurança: desabilite drivers de rede desnecessários, limite dimensões/feature count, valide CRS e paths. Arquivos geográficos podem incluir credenciais/URLs e consumir disco enorme.

Avaliação: 🟡 · 4,2/5 · U4 F3 R3 A5 S4 N4 M5 P5.

Dez modelos de arquitetura

Modelo 1 — comando SSH direto

Bom para tarefa curta, idempotente e retorno textual. Use subcomandos fechados, não o executável bruto:

ssh -T media-worker 'worker-cli probe job-01'

Vantagem: nenhuma infraestrutura além do OpenSSH. Limite: desconexão pode deixar processo órfão e o cliente não ganha histórico. Para trabalho acima de poucos minutos, o dispatcher deve criar job persistente.

Modelo 2 — stdin/stdout

É a forma mais Unix e evita permissões/temporários. Excelente para jq/yq, Miller, age, hash, ExifTool, DuckDB, OCRmyPDF e conversões com saída streamable:

cat entrada.json | ssh -T worker 'worker-cli transform customer-v2' > saida.json
cat scan.pdf | ssh -T worker 'worker-cli pdf ocr --lang por' > scan-ocr.pdf

Não use PTY (-T) porque ele pode alterar bytes. Evite para ferramentas que precisam seek, múltiplos arquivos ou retomada.

Modelo 3 — SCP + comando + SCP

Adequado a lote pequeno/médio e ferramentas que exigem nomes de arquivo:

scp entrada.pdf worker:/srv/drop/job-42/input.pdf
ssh -T worker 'worker-cli submit pdf-ocr job-42'
scp worker:/srv/results/job-42/output.pdf ./

O servidor deve criar o ID, e não confiar em path escolhido pelo cliente. SFTP interno é melhor que shell quando a conta serve apenas arquivos.

Modelo 4 — rsync para arquivos grandes

rsync --partial retoma transferências e evita retransmitir blocos iguais. É ideal para mídia, datasets e backups. Use rrsync ou módulo daemon-over-SSH para restringir diretório; o manual atual documenta read-only, write-only, no-delete e cuidados de segurança.

Modelo 5 — diretório compartilhado

/srv/jobs/incoming/<id>   upload incompleto
/srv/jobs/ready/<id>      entrada promovida atomicamente
/srv/jobs/running/<id>    job em execução
/srv/jobs/done/<id>       resultado + result.json
/srv/jobs/error/<id>      erro sanitizado + log

Upload termina com rename atômico de incoming para ready; um watcher/systemd path ou timer coleta. É robusto para NAS, mas precisa quota, limpeza e ownership rigoroso. Não processe arquivo enquanto ainda está sendo enviado.

Modelo 6 — fila por SSH

Pueue mantém fila, logs, dependências, grupos, paralelismo e JSON mesmo após logout. É ótimo dentro de cada worker, mas o próprio projeto não se propõe a centenas de tarefas, multiusuário ou scheduler distribuído.

ssh worker 'worker-cli job submit media-transcode --input 42'
{"job_id":"01J...","state":"queued"}
ssh worker 'worker-cli job status 01J...'
ssh worker 'worker-cli job cancel 01J...'

O dispatcher mapeia a operação para pueue add sem aceitar comando de shell do chamador. Para uma fila multiusuário real, use banco SQLite/PostgreSQL e um pequeno daemon Python/Node, ainda sem Kubernetes.

Modelo 7 — forced command: SSH como uma API estreita

É sólido quando o comando forçado implementa protocolo próprio e parser seguro. OpenSSH ignora o comando do cliente, coloca o original em SSH_ORIGINAL_COMMAND e aplica as restrições da chave. Borg e rrsync são exemplos reais. Nunca faça eval "$SSH_ORIGINAL_COMMAND".

from="10.20.0.15",restrict,command="/usr/local/libexec/worker-dispatch" ssh-ed25519 AAAA... n8n-media

restrict desliga forwarding de porta/agente/X11, PTY e ~/.ssh/rc, incluindo futuras restrições. from= é defesa adicional, não substitui a chave; IP muda em NAT/VPN.

Modelo 8 — SSH como transporte RPC

O protocolo pode ser NDJSON: uma requisição em stdin e uma resposta em stdout. O dispatcher lê no máximo uma linha, valida JSON Schema e chama processo com array de argumentos. Git usa isso há décadas: git-shell permite somente upload-pack, receive-pack, upload-archive e comandos administrativos autorizados. Borg também transporta seu protocolo por stdin/stdout do SSH.

{"v":1,"op":"image.thumbnail","job":"01J...","args":{"width":1280}}

Versão, códigos de erro estáveis e limite de mensagem tornam a automação previsível.

Modelo 9 — worker em Docker/Podman

O desenho recomendado é um sshd no host/bastion + dispatcher + docker run --rm/Podman rootless por job. A documentação Docker explica que o host normalmente gerencia SSH e que containers não precisam de sshd. docker exec apenas roda comando enquanto o PID 1 do container existe; para jobs isolados, run --rm com limites é mais limpo.

Um container com sshd faz sentido quando precisa parecer VM autônoma, tem ciclo de chaves próprio ou será distribuído como appliance. Em troca, duplica sshd, atualização, logs, usuários e superfície. Nunca monte /var/run/docker.sock no dispatcher: acesso ao socket equivale, na prática, a controle do host. Prefira rootless Podman/Docker, --network none, filesystem read-only e mounts mínimos.

Modelo 10 — SSH restrito em camadas

Conta sem shell livre + Match User + forced command + permissões Unix + container/cgroup. Chroot muda a raiz do filesystem, mas não cria limite de CPU/RAM, namespace de rede, defesa contra bugs de kernel nem substitui container; além disso, diretórios do caminho precisam pertencer a root e um shell interativo exige bibliotecas/devices. É útil para internal-sftp, menos atraente para toolchains complexas.

Dispatcher seguro: exemplo de desenho

Em /etc/ssh/sshd_config.d/workers.conf:

AllowUsers admin worker-media worker-data

Match User worker-media,worker-data
    PasswordAuthentication no
    KbdInteractiveAuthentication no
    AuthenticationMethods publickey
    PermitTTY no
    DisableForwarding yes
    X11Forwarding no
    PermitUserRC no
    ForceCommand /usr/local/libexec/worker-dispatch

DisableForwarding yes desliga todos os forwardings; se a versão distribuída não oferecer essa diretiva, aplique explicitamente AllowTcpForwarding no, AllowAgentForwarding no, X11Forwarding no e PermitTunnel no. Uma linha de chave por automação permite revogar e auditar separadamente:

from="10.20.0.15",restrict,command="/usr/local/libexec/worker-dispatch --client n8n" ssh-ed25519 AAAAC3... n8n-2026-08

O dispatcher deve:

1. rejeitar requisição vazia, grande, com NUL ou newline extra;
2. analisar JSON ou tokenizar com parser próprio, nunca eval/sh -c;
3. aceitar operação e parâmetros por allowlist, com tipos/faixas;
4. gerar UUID/ULID no servidor e resolver caminho com realpath dentro do workspace;
5. abrir arquivos com proteção contra symlink e ownership esperado;
6. chamar execve/subprocess.run([...], shell=False) com ambiente mínimo;
7. executar como unidade/container limitado e retornar JSON sem segredo;
8. registrar cliente, chave/fingerprint, operação, hash de entrada, tempo, exit code e bytes.

Exemplo conceitual em Python, deliberadamente sem shell:

#!/usr/bin/env python3
import json, os, subprocess, sys

OPS = {
    "hash.sha256": ["/usr/bin/sha256sum", "-"],
    "metadata.json": ["/usr/bin/exiftool", "-json", "-"],
}

raw = sys.stdin.buffer.readline(16_385)
if len(raw) > 16_384 or sys.stdin.buffer.read(1):
    raise SystemExit(64)
request = json.loads(raw)
argv = OPS.get(request.get("op"))
if argv is None or set(request) != {"op"}:
    raise SystemExit(64)

env = {"PATH": "/usr/bin:/bin", "LANG": "C.UTF-8"}
result = subprocess.run(argv, env=env, stdin=sys.stdin.buffer,
                        stdout=sys.stdout.buffer, stderr=sys.stderr.buffer,
                        timeout=300, check=False)
raise SystemExit(result.returncode)

Em produção, o protocolo deve usar o JSON ou o payload binário no stdin; não os dois misturados. Para binário, envie a operação no SSH_ORIGINAL_COMMAND estritamente tokenizado ou use cabeçalho length-prefixed.

Limites de CPU, memória, tempo e disco

timeout mata um processo simples; systemd-run cria unidade transitória no cgroup e permite contabilização/controle. A documentação systemd confirma que ele é wrapper de StartTransientUnit() e que limites se aplicam a services/scopes/slices.

systemd-run --quiet --wait --collect --pipe \
  --unit="worker-${JOB_ID}" \
  --property=User=worker-media \
  --property=CPUQuota=200% \
  --property=MemoryMax=4G \
  --property=TasksMax=256 \
  --property=RuntimeMaxSec=2h \
  --property=PrivateTmp=yes \
  /usr/local/libexec/run-approved-job "$JOB_ID"

O dispatcher não deve receber JOB_ID arbitrário; ele mesmo gera/valida [A-Za-z0-9_-]+. Disco requer quota de filesystem/projeto, volume com tamanho limitado ou workspace por job em storage separado. MemoryMax evita derrubar o host, mas jobs que ultrapassam podem ser mortos: isso precisa aparecer como erro distinto.

Integração com n8n, aplicações e agentes

O nó SSH oficial do n8n executa comando, faz upload e download. Isso é diferente do nó Execute Command, que roda no host do n8n e está desativado por padrão desde n8n 2.0 por risco. Fluxo recomendado:

Webhook/Schedule
  → gerar job e salvar entrada
  → SSH Upload ou rsync externo
  → SSH: worker-cli job submit <tipo> <id>
  → Wait/loop com backoff
  → SSH: worker-cli job status <id> --json
  → SSH Download / S3
  → validar hash e notificar

• Node.js: ssh2 com exec() e array/JSON no protocolo; não concatene entrada de usuário.
• Python: Paramiko/AsyncSSH ou, para simplicidade e verificação igual à CLI, subprocess.run(["ssh", ...], shell=False).
• Shell: set -euo pipefail, ssh -T, BatchMode=yes, StrictHostKeyChecking=yes e UserKnownHostsFile administrado.
• cron/systemd timers: systemd oferece logs, estado e limites melhores; timer chama script cliente idempotente.
• agentes de IA: exponha ferramentas de alto nível (ocr_document, probe_media), não run_shell; valide tamanho/tipo e exija confirmação para efeitos destrutivos.

Chaves privadas ficam no credential store do n8n ou arquivo 0600 montado somente no processo; uma chave por workflow/worker, sem agent forwarding. known_hosts deve ser provisionado fora da primeira conexão; aceitar host key automaticamente anula proteção contra MITM.

Worker universal ou especializados?

O melhor meio-termo é um host físico universal com containers efêmeros especializados. O SSH vê um único worker-cli, enquanto mídia, PDF, dados e scan rodam em imagens distintas, sem sshd dentro delas.

SSH Worker Farm prática, sem Kubernetes

                  n8n / scripts / apps / agentes
                              │
                    SSH com chaves dedicadas
                              │
                    bastion/dispatcher opcional
          ┌───────────────────┼────────────────────┐
          │                   │                    │
  worker-core           worker-media          worker-ai-gpu
  docs, image, data     vídeo/áudio/QC         Whisper/LLM/visão
  scan, render, web     iGPU/Quick Sync        liga sob demanda
          │                   │                    │
          └────────────── storage/S3/NAS ─────────┘
                              │
                      manifests + resultados

Implantação recomendada:

• worker-core: 4–8 núcleos, 16 GB, NVMe; Pandoc, OCR, libvips, DuckDB, GDAL, Syft/Grype, Playwright. Pode ser o worker universal inicial.
• worker-media: pode ser o mesmo core enquanto a carga for baixa; separar quando houver fila, iGPU dedicada ou biblioteca grande.
• worker-ai-gpu: modelos e drivers tornam imagem/segurança diferentes; desligado e acordado por IPMI/Wake-on-LAN quando possível.
• backup fica no NAS/cofre e aceita apenas Borg/restic/rrsync, nunca jobs gerais.
• diagnóstico de rede roda em 2–3 VPS pequenas por localidade; captura ao vivo é conta/host separado.

Cada host usa Pueue com grupos (cpu, io, gpu) e paralelismo local. Um coordenador simples mantém tabela SQLite jobs, mede pueue status --json, espaço e load, então escolhe o worker por capability + slots. Para lotes efêmeros, GNU Parallel já distribui por --sshlogin, transfere/retorna/limpa arquivos, registra --joblog e retenta; é excelente quando o chamador controla a lista e não precisa de API multiusuário.

Estado mínimo do job: queued, running, succeeded, failed, cancelled, expired; registre tentativas, worker, PID/unidade, timestamps, exit code, hashes, tamanho e URI do resultado. Cancelamento chama systemctl stop worker-<id>; retry automático apenas para falhas transitórias e jobs idempotentes. Logs vão para journald com job ID e são exportados sem segredos; resultados têm TTL e garbage collection.

Segurança operacional: checklist que deve virar configuração

• Identidade: Ed25519 por serviço/workflow, comentários com dono/data, sem reutilização. OpenSSH CA (TrustedUserCAKeys) vale a pena em dezenas de clientes; para poucos, chaves separadas são mais simples.
• Conta: usuário dedicado sem sudo, grupos mínimos, home não gravável quando scripts/configs residem nele. Scripts root-owned e não graváveis pelo worker.
• Autorização: restrict, from=, command= por chave; no servidor, AllowUsers, Match User, ForceCommand, PermitTTY no, DisableForwarding yes e autenticação só por chave.
• Host key: fixe fingerprints/CA em known_hosts; não use StrictHostKeyChecking=no em automação.
• Segredos: nada em argumento, variável exibida por ps, stdout ou log. Use arquivos 0600, credenciais do n8n ou secret store; não encaminhe SSH_AUTH_SOCK.
• Input: extensões e MIME não bastam. Limite bytes, pixels, páginas, duração, arquivos internos de archive, profundidade, redirects e quantidade de registros.
• Shell injection: jamais eval, bash -c "$input", os.system() ou template de comando. Use parser, enums, números com faixa e execve/array de argumentos; rejeite opção começando por - quando o campo é nome e use -- onde suportado.
• Filesystem: workspace criado pelo servidor, path canônico dentro dele, umask 077, sem seguir symlink, mount read-only para input e resultado promovido atomicamente.
• Isolamento: container rootless sem rede/capabilities, seccomp/AppArmor/SELinux quando disponível. Chroot ajuda a esconder filesystem, mas não limita recursos ou rede.
• Recursos: MemoryMax, CPUQuota, TasksMax, RuntimeMaxSec, quota de disco, concorrência por grupo e limite de output/log.
• Rede: egress negado por padrão. Workers web usam allowlist + proteção SSRF; worker de PCAP não precisa internet; build baixa apenas registries autorizados.
• Auditoria: fingerprint/chave, client ID, operação, hash, job ID, início/fim, limites, exit code e destino. Nunca registrar conteúdo completo ou segredo.
• Ciclo de vida: atualizações pinadas e testadas, inventário/SBOM do próprio worker, revogação de chaves, TTL de resultados, backup da configuração e restauração testada.

Tabela-resumo das 40 ideias

Estado dos projetos principais

“Ativo” abaixo significa repositório/documentação com atividade ou release recente observado na data da pesquisa; não é promessa de manutenção futura. Licenças são do software citado, não dos codecs, modelos, fontes ou dados processados.

TOP 20 workers SSH que realmente valeria a pena montar

1. DuckDB analítico: transforma arquivos enormes em respostas pequenas, sem banco residente e com excelente stdin/stdout.
2. Backup Borg/restic: SSH já faz parte do desenho e uma chave forced-command pode aceitar backup sem oferecer shell.
3. Imagens com libvips: enorme reutilização, baixo idle e processamento rápido para sites, acervos e automações.
4. OCRmyPDF: entrega valor concreto a documentos escaneados e possui pipeline/container bem documentado.
5. Diagnóstico HTTP/DNS/TLS: quase zero idle, resultado JSON e utilidade diária em qualquer infraestrutura.
6. Transformações jq/yq: representa a essência do worker Unix e elimina muitos scripts pequenos frágeis.
7. rsync/rclone: resolve movimentação, replicação e verificação entre servidores e nuvens com maturidade alta.
8. Miller/qsv: faz ETL tabular leve e streaming sem subir Python/Pandas para cada CSV.
9. Transcodificação de mídia: aproveita CPU/iGPU ociosa e centraliza codecs/presets, embora exija mais limites.
10. Metadados/ExifTool: inspeção e saneamento baratos, fáceis de encadear antes de publicação.
11. Arquivamento/compressão: universal, confiável e perfeito para pipe TAR+zstd por SSH.
12. SBOM e scan defensivo: produz artefatos úteis de segurança em máquina isolada e sem contaminar o build host.
13. Documentos/Pandoc: uma única toolchain consistente evita instalar LaTeX/fontes em todas as máquinas.
14. Verificador de links: rápido, programável e ótimo para n8n/timers antes de publicar.
15. Build machine isolada: centraliza toolchains e libera notebooks, desde que código rode sem segredos.
16. Transcrição local: preserva privacidade e transforma uma GPU/CPU forte em serviço realmente útil.
17. QC de mídia: muitas vezes evita transcodificação desnecessária; JSON de ffprobe/MediaInfo é excelente para regras.
18. ClamAV/YARA: bom portão de entrada para uploads, desde que não seja confundido com garantia de segurança.
19. Triagem de arquivos: worker minúsculo que decide com segurança qual pipeline vem depois.
20. Screenshot/PDF web: muito útil para evidência e relatórios, mas deve nascer com proteção SSRF.

Recomendações práticas

Fase 1 — protótipo seguro em uma máquina

1. Debian/Ubuntu atualizado, usuário worker, SSH apenas em Tailscale/VPN ou firewall por origem.
2. Um worker-cli com quatro operações: inspect, image, pdf-ocr e data-query.
3. Protocolos com presets versionados e resposta JSON; entrada em /srv/jobs, umask 077 e TTL de sete dias.
4. Chave Ed25519 exclusiva do cliente e forced command com restrict/from=.
5. systemd-run por job com CPU, RAM, processos e tempo; quota separada de disco.
6. Containers rootless efêmeros para parsers de arquivo; sem rede salvo worker web.
7. Testes com arquivo vazio, grande, nome estranho, archive bomb controlada, desconexão, timeout e disco cheio.

Fase 2 — fila e automação

Adicione Pueue por host, grupos cpu=2, io=1 e gpu=1, mais job submit/status/result/cancel. n8n guarda somente o ID e URI do resultado, não um processo SSH aberto por horas. Salve manifestos request.json, result.json, checksums e versão da imagem/ferramenta. O upload entra como .partial e só é promovido após hash/tamanho conferidos.

Fase 3 — especialização seletiva

Separe ai-worker quando GPU/modelos justificarem e transforme o NAS em backup-worker restrito ao protocolo. Só crie media-worker separado quando a fila competir com OCR/dados. Para quatro hosts idênticos e lote administrado, experimente GNU Parallel antes de construir scheduler. Para múltiplos usuários e prioridades, pequeno coordenador com SQLite/PostgreSQL é o ponto em que vale escrever serviço.

O que não vale transformar em worker SSH

• tarefa instantânea já disponível no cliente, sem dependência especial ou ganho de centralização;
• serviço interativo de baixa latência que deveria ter API/stream persistente;
• aplicação que requer shell irrestrito ou acesso root como “feature”;
• job que recebe código não confiável no mesmo host de segredos/dados;
• monitor contínuo em que a conexão SSH seria apenas um wrapper artificial;
• operação destrutiva sem idempotência, dry-run, aprovação e recuperação.

Conclusão

Uma SSH Worker Farm é especialmente boa quando o trabalho pode ser descrito como entrada → ferramenta madura → resultado, leva segundos ou minutos, beneficia-se de hardware/dependências centralizados e não precisa de interface gráfica. O primeiro investimento não deve ser cluster: deve ser um protocolo estreito, um dispatcher sem shell injection, storage de jobs e limites por cgroup.

O conjunto inicial mais equilibrado é um worker universal com containers de libvips/ImageMagick, OCRmyPDF/qpdf/Pandoc, DuckDB/Miller/jq, FFmpeg/MediaInfo e Syft/Grype, além de ferramentas nativas de rede. Backup precisa de conta/protocolo próprios; IA/GPU pode ficar desligada e subir sob demanda. Pueue e systemd bastam para a fila local; GNU Parallel cobre distribuição de lotes. Só depois de observar fila, falhas e conflitos reais faz sentido separar hosts ou criar coordenador.

As aplicações mais surpreendentes não são as mais pesadas: DuckDB por stdin, diffoscope, ExifTool, age, Graphviz/Typst, FontTools e GDAL mostram como uma CLI pequena, encapsulada por SSH, pode virar um serviço remoto poderoso sem virar uma plataforma difícil de administrar.

Fontes consultadas

• OpenSSH sshd — opções de authorized_keys e restrict
• OpenSSH sshd_config — Match, ForceCommand, forwarding e chroot
• systemd — interface de cgroups e unidades transitórias
• Docker — segurança do Engine, namespaces, capabilities e cgroups
• Docker — boas práticas de imagens e separação de responsabilidades
• Docker — executar comando em container existente
• Podman Quadlet e systemd
• n8n — nó SSH
• n8n — Execute Command e risco operacional
• Pueue — fila persistente de comandos
• GNU Parallel — execução e transferência por SSH
• Git shell — shell restrito para protocolo Git
• rrsync — rsync restrito por forced command
• Borg serve — restrição por repositório e quota
• restic — repositório SFTP
• rclone — documentação oficial
• FFmpeg — documentação atual
• FFmpeg — licença e componentes GPL/LGPL
• FFmpeg — filtros, incluindo loudnorm
• HandBrakeCLI — referência
• MKVToolNix — mkvmerge
• MediaInfo — SDK e CLI
• ImageMagick — política de segurança e recursos
• libvips — uso pela linha de comando
• ExifTool — site e documentação oficial
• ExifTool — FAQ de remoção segura de metadados
• OCRmyPDF — container e stdin/stdout
• OCRmyPDF — limites em implantação online
• qpdf — referência CLI
• MuPDF — mutool
• Pandoc — manual
• Calibre — ebook-convert
• Apache Tika — primeiros passos
• Playwright — screenshots
• Lighthouse — repositório oficial
• lychee — verificador de links
• monolith — página autocontida
• iperf3 — manual e JSON
• TShark — manual oficial
• jq — manual
• yq — documentação
• Miller — documentação
• qsv — repositório oficial
• DuckDB CLI — stdin/stdout e formatos
• DuckDB — safe mode
• Frictionless Framework
• sccache — cache e compilação distribuída
• whisper.cpp — transcrição local CPU/GPU
• llama.cpp — inferência e embeddings
• ClamAV — scanning
• YARA — documentação
• Syft — SBOM
• Grype — vulnerabilidades em imagens/filesystems/SBOM
• Trivy — documentação
• Gitleaks — detecção de segredos
• age — criptografia de arquivos
• minisign — assinaturas
• Graphviz — documentação
• Mermaid CLI
• Typst — repositório oficial
• FontTools — subset de fontes
• GDAL — programas CLI

Nota sobre atualidade

Pesquisa concluída em 26 de agosto de 2026. Informações sujeitas a mudanças devem ser confirmadas nas fontes oficiais antes de decisões importantes.