FFmpeg em produção: VPS para processamento de vídeo

Resposta direta

Para processamento de vídeo com FFmpeg em produção, a VPS deve ser dimensionada principalmente por CPU, concorrência de jobs, espaço temporário em disco e velocidade de leitura e escrita. Um ponto de partida seguro para workloads leves é 2 vCPUs, 4 GB de RAM e 80 GB de SSD. Para converter vídeos em paralelo, gerar múltiplas resoluções ou comprimir arquivos longos, comece em 4 vCPUs, 8 GB de RAM e disco NVMe com folga para arquivos temporários. O FFmpeg costuma usar muita CPU, mas pipelines reais também sofrem com I/O, filas mal configuradas e uploads grandes. Em vez de processar o vídeo durante a requisição HTTP, use uma fila com workers, limite de concorrência e monitore tempo médio por job, uso de CPU, swap, disco livre e falhas por codec.

Resumo rápido

• FFmpeg é intensivo em CPU, especialmente ao fazer transcode entre codecs como H.264, H.265, VP9 ou AV1.
• Para produção pequena, pense em 2 vCPUs, 4 GB de RAM e 80 GB de SSD como base mais realista do que planos mínimos de 1 GB.
• Para múltiplos workers, 4 a 8 vCPUs e 8 a 16 GB de RAM reduzem filas longas e evitam swap durante picos.
• Disco NVMe ajuda quando há muitos arquivos temporários, leitura simultânea, geração de thumbnails e múltiplas saídas por vídeo.
• Processar vídeo dentro da requisição HTTP é um erro comum. Use filas, jobs assíncronos e callbacks.
• Docker funciona bem para isolar FFmpeg, desde que você limite CPU, memória, volume temporário e concorrência.
• Backups devem proteger metadados e arquivos finais, não necessariamente todos os arquivos temporários gerados durante o processamento.
• Latência importa menos no transcode em si, mas conta bastante para uploads, downloads e APIs usadas por usuários no Brasil.

Um projeto que recebe vídeos de 30 segundos para gerar thumbnails tem necessidades bem diferentes de uma plataforma que converte aulas de 2 GB para 1080p, 720p e 480p. A palavra-chave aqui é previsibilidade. A VPS precisa aguentar o pior momento do pipeline, não apenas o consumo médio do servidor em repouso. Se você ainda está escolhendo a base do servidor, o artigo sobre como escolher CPU, RAM e NVMe ajuda a comparar os recursos antes de contratar um plano.

Como o FFmpeg usa CPU, RAM, disco e rede

FFmpeg é uma ferramenta flexível, mas essa flexibilidade cobra recursos de formas diferentes conforme o comando. Copiar um stream sem recodificar, usando -c copy, é relativamente leve. Converter um vídeo H.264 para H.265 com preset lento, filtro de escala e normalização de áudio pode ocupar todas as vCPUs por vários minutos. Na prática, a CPU vira o primeiro gargalo quando há transcode real, compressão agressiva ou múltiplas saídas por arquivo.

CPU é o gargalo mais comum

O parâmetro -preset muda muito o custo. Em H.264 com libx264, presets como ultrafast terminam rápido e geram arquivos maiores. Presets como slow e veryslow comprimem melhor, mas consomem mais tempo de CPU. Para uma API que precisa entregar resultado rápido, veryfast ou fast costuma ser mais aceitável. Para um pipeline offline, que roda de madrugada, medium pode equilibrar qualidade e tamanho. Um comando típico para web ficaria assim:

ffmpeg -i entrada.mp4 -vf scale=-2:720 -c:v libx264 -preset fast -crf 23 -c:a aac -b:a 128k saida-720p.mp4

Esse comando faz escala para 720p, recodifica vídeo e áudio, e cria um arquivo final compatível com navegadores. Em uma VPS de 2 vCPUs, rodar um job desse tipo pode ser tranquilo. Rodar quatro ao mesmo tempo pode travar a API, aumentar a latência do SSH e causar timeout em outros serviços. Por isso, a configuração da fila é tão importante quanto a configuração do plano.

RAM importa mais em paralelismo do que em um único job

Um único processo FFmpeg para vídeos comuns raramente precisa de dezenas de gigabytes de RAM. O problema aparece quando vários processos rodam juntos, quando há filtros complexos, thumbnails em lote, vídeos 4K ou buffers grandes. Se cada job consome entre 300 MB e 1,2 GB em momentos de pico, três workers podem levar uma VPS de 4 GB ao limite junto com sistema operacional, Redis, banco e aplicação. Quando a máquina entra em swap, o tempo por vídeo sobe muito e o disco passa a ser usado como memória improvisada.

Rede também entra na conta. Se a VPS recebe uploads grandes, baixa arquivos de um bucket e depois envia resultados para outro serviço, o tráfego pode ser maior do que o esperado. Em vídeos, um único usuário pode gerar centenas de megabytes. Em escala, isso muda bandwidth, armazenamento e política de retenção. Não adianta ter CPU sobrando se o gargalo está no download do arquivo original ou no upload do resultado final.

Como dimensionar a VPS pelo tipo de vídeo

Dimensionar uma VPS para processamento de vídeo com FFmpeg começa por três perguntas simples: qual o tamanho médio dos arquivos, quantos vídeos chegam por hora e qual o tempo máximo aceitável para concluir cada job. Sem essas respostas, qualquer recomendação vira chute. Um pipeline que gera uma thumbnail de 1280x720 a partir do segundo 5 do vídeo pode rodar em uma VPS modesta. Um pipeline que converte cada upload para 1080p, 720p, 480p e ainda extrai prévias animadas precisa de outro patamar.

Uploads curtos para web e redes sociais

Para vídeos curtos, como clipes de 15 a 90 segundos, um plano com 2 vCPUs, 4 GB de RAM e 80 GB de SSD pode atender bem se a concorrência for controlada. Um worker único processando um vídeo por vez evita disputa por CPU e reduz falhas. Esse cenário serve para SaaS pequenos, área administrativa de e-commerce, geradores de thumbnails e plataformas internas. O comando costuma ser simples, com escala para 720p ou 1080p, CRF entre 22 e 28 e áudio AAC em 128 kbps.

Um exemplo prático: uma aplicação recebe 40 vídeos por dia, com média de 80 MB cada, e precisa gerar uma versão comprimida e uma thumbnail. Se cada job leva 60 a 180 segundos em 2 vCPUs, a fila fica saudável desde que os uploads não cheguem todos no mesmo minuto. Nesse caso, faz sentido limitar o worker para um processo FFmpeg simultâneo, manter pelo menos 30 GB livres para temporários e enviar o arquivo final para armazenamento externo depois do processamento.

Vídeos longos, múltiplas resoluções e produção pesada

Quando os vídeos passam de 20 minutos ou têm resolução 4K, a configuração muda. Para uma plataforma de aulas, webinars ou conteúdo sob demanda, 4 vCPUs e 8 GB de RAM viram um ponto de partida mais seguro. Se o pipeline cria três versões por arquivo, o job pode ser sequencial ou paralelo. Sequencial usa menos recursos e demora mais. Paralelo entrega mais rápido, mas exige mais CPU, RAM e I/O.

Em produção pesada, 8 vCPUs, 16 GB de RAM e NVMe ajudam a manter previsibilidade. Ainda assim, não trate NVMe como milagre. Ele reduz gargalos de leitura e escrita, mas não acelera automaticamente um codec limitado por CPU. O ganho aparece quando vários workers leem fontes grandes, gravam múltiplas saídas e criam arquivos temporários ao mesmo tempo. Para APIs que também atendem usuários, separar processamento e aplicação em servidores diferentes evita que um vídeo pesado derrube endpoints críticos. Essa separação é parecida com o raciocínio usado em VPS para APIs e microsserviços no Brasil, onde cada componente ganha recursos conforme sua função.

Arquitetura de produção com filas, workers e Docker

O erro mais caro em processamento de vídeo é acoplar FFmpeg ao ciclo da requisição HTTP. O usuário envia o vídeo, a aplicação chama FFmpeg, a conexão fica aberta e o servidor tenta devolver a resposta quando tudo termina. Isso funciona em testes locais, mas falha em produção com timeouts, uploads interrompidos, deploys no meio do processo e consumo imprevisível de CPU. O desenho mais robusto é assíncrono: API recebe o arquivo, grava metadados, coloca um job na fila e responde que o processamento começou.

Por que não processar vídeo dentro da requisição HTTP

Com uma fila, você controla concorrência. Em vez de dez uploads dispararem dez processos FFmpeg, a aplicação pode rodar um ou dois workers por servidor. Redis, RabbitMQ, SQS ou uma fila gerenciada cumprem esse papel. O job precisa registrar status como pending, processing, failed e completed, além de salvar logs úteis. Quando um vídeo falha por codec não suportado, arquivo corrompido ou falta de espaço, o usuário recebe uma mensagem clara e o time consegue investigar.

Um fluxo comum em produção fica assim: upload para diretório temporário ou bucket, criação de registro no banco, envio do job, execução do FFmpeg em worker separado, validação do arquivo final, atualização do banco e limpeza dos temporários. Para evitar retrabalho, armazene também duração, resolução, codec de origem e tamanho final. O ffprobe, que acompanha o FFmpeg, ajuda nisso:

ffprobe -v error -show_entries format=duration,size -show_streams -of json entrada.mp4

Exemplo prático com Docker e limite de concorrência

Docker é uma boa escolha quando você quer isolar versão do FFmpeg, bibliotecas de codec e dependências da aplicação. A imagem pode conter somente o necessário, com volumes para entrada, saída e temporários. O cuidado está nos limites. Um container sem limite pode consumir toda a CPU do host. Um exemplo de execução controlada seria:

docker run --rm --cpus="2" --memory="3g" -v /data/videos:/videos ffmpeg-worker:latest

Se a aplicação já usa containers, leia também o guia de VPS para Docker, porque os mesmos pontos aparecem aqui: logs, volumes persistentes, limites de memória, rede interna e estratégia de atualização. Em FFmpeg, esses detalhes ficam ainda mais sensíveis porque um job pode durar muitos minutos. Ao fazer deploy, evite matar containers em processamento sem sinalização. Use shutdown gracioso, marque o job como recuperável e só remova arquivos temporários depois de confirmar o resultado.

Disco, NVMe, armazenamento temporário e rede

Em vídeo, disco não é apenas lugar para guardar arquivo final. Ele participa do pipeline inteiro. A VPS recebe o upload, salva um arquivo de entrada, cria temporários, grava a saída e muitas vezes gera thumbnails, sprites, prévias curtas e logs. Se o disco fica cheio no meio do job, o FFmpeg pode falhar com mensagens pouco amigáveis. Por isso, a regra prática é manter espaço livre maior que o dobro do maior arquivo esperado, e aumentar essa margem quando há múltiplas saídas.

O papel do diretório temporário

Imagine um vídeo original de 2 GB que gera três versões: 1080p com 1,2 GB, 720p com 700 MB e 480p com 350 MB. Durante o processamento, você pode precisar de mais de 4 GB livres para um único upload, sem contar logs e arquivos incompletos. Com dois workers simultâneos, essa conta dobra. Um disco de 40 GB parece suficiente no papel, mas pode ficar apertado quando há retenção de originais por alguns dias. Para produção, 80 GB a 160 GB costuma ser uma faixa mais confortável em projetos pequenos e médios.

NVMe ajuda quando o pipeline faz muitas operações simultâneas. Leitura do original, escrita da saída, geração de imagens e movimentação de arquivos competem pelo mesmo I/O. Em cargas leves, SSD comum pode bastar. Em cargas com vários workers, NVMe reduz espera de disco e melhora estabilidade. A recomendação técnica é monitorar iowait, throughput de leitura e escrita, uso de inode e espaço livre. Se a CPU está baixa, mas os jobs continuam lentos, o disco pode estar segurando o pipeline.

Quando enviar o arquivo para object storage

Nem todo arquivo precisa ficar na VPS. O ideal é separar processamento de armazenamento durável. A VPS trabalha como nó de conversão, enquanto os originais e resultados finais ficam em object storage compatível com S3, serviço do provedor ou storage externo. Isso simplifica escala horizontal: se a fila cresce, você sobe outro worker que baixa o arquivo, processa e envia o resultado. Também reduz risco de perder arquivos finais em uma reinstalação ou falha do disco local.

Rede entra nessa equação. Datacenter no Brasil pode reduzir latência para uploads de usuários brasileiros e melhorar a experiência em painéis administrativos, embora o processamento em si dependa mais de CPU e disco. Provedores como DigitalOcean, Vultr, Linode, AWS Lightsail, Hetzner, Contabo e LetsCloud oferecem perfis diferentes de região, disco, cobrança e painel. Preços, bandwidth, localidades e tipos de armazenamento mudam com frequência, então qualquer decisão comercial precisa ser conferida nas páginas oficiais antes da publicação final.

Tabela de perfis para FFmpeg em VPS

A tabela abaixo não substitui teste de carga, mas ajuda a sair do zero com números realistas. Use os perfis como referência inicial e ajuste depois de medir tempo por job, fila acumulada, uso de CPU, memória, I/O e falhas. Em vídeo, a diferença entre um MVP saudável e um sistema instável pode ser simplesmente limitar a concorrência para um worker enquanto o produto ainda valida demanda.

Perfil de uso	Configuração inicial	Concorrência sugerida	Exemplo de workload	Pontos de atenção
Thumbnails e clipes curtos	2 vCPUs, 4 GB RAM, 80 GB SSD	1 job FFmpeg	Gerar thumbnail, comprimir vídeos de até 90 segundos, criar preview em 480p	Limpar temporários, evitar swap, medir tempo médio por upload
SaaS com uploads frequentes	4 vCPUs, 8 GB RAM, 120 GB SSD ou NVMe	2 jobs FFmpeg	Converter vídeos de 200 MB a 1 GB para 720p e 1080p	Separar API e worker, usar fila, enviar finais para object storage
Plataforma de aulas ou mídia	8 vCPUs, 16 GB RAM, 200 GB NVMe	3 a 4 jobs, conforme testes	Vídeos longos, múltiplas resoluções, thumbnails e prévias	Monitorar I/O, bandwidth, retries, custo de storage e tempo de fila
Pipeline pesado ou multi-tenant	16 vCPUs ou mais, 32 GB RAM, NVMe com storage externo	Escala horizontal	Vários clientes, vídeos longos, processamento contínuo	Orquestração, autoscaling, isolamento por cliente, observabilidade avançada

O melhor perfil depende do SLA que você prometeu. Se o usuário aceita esperar 20 minutos por uma aula processada, você pode economizar CPU e rodar jobs sequenciais. Se ele espera prévia em menos de 60 segundos, a conta muda. Também existe diferença entre converter tudo na hora e adotar processamento sob demanda. Alguns produtos só geram 1080p no upload e deixam versões menores para quando houver acesso real. Essa abordagem reduz custo inicial, mas deixa a arquitetura mais complexa.

Em comparação de provedores, evite olhar só para vCPU e preço mensal. Verifique política de uso justo de CPU, tipo de virtualização, limites de bandwidth, snapshots, backup, regiões disponíveis, painel, API e facilidade de upgrade. Uma VPS tradicional pode ser suficiente para projetos previsíveis. Um Cloud Server ou cloud instance tende a facilitar expansão, clonagem e automação. A diferença prática aparece quando você precisa subir mais workers em dias de pico ou trocar rapidamente para um plano maior sem reinstalar tudo.

Operação, segurança e observabilidade

Processamento de vídeo exige operação cuidadosa porque jobs são longos, pesados e sujeitos a falhas externas. Arquivo corrompido, codec incomum, upload interrompido, disco cheio, falta de permissão, timeout de rede e container finalizado no deploy são problemas normais. A diferença entre um sistema amador e um pipeline confiável está na forma como esses casos são tratados. Um job precisa ter log, status, tentativas controladas e limpeza segura.

Controle de recursos e limites por processo

Comece limitando concorrência na fila. Depois, limite recursos do processo. Em Linux, nice e ionice ajudam a reduzir prioridade de CPU e disco para jobs que não devem atrapalhar a API. Em Docker, use --cpus, --memory e volumes separados. Em systemd, dá para usar CPUQuota e MemoryMax. Um worker que processa vídeo não deve ter acesso irrestrito a diretórios sensíveis do servidor. Monte apenas as pastas necessárias, com permissões mínimas.

Também valide entrada. Não confie no nome do arquivo enviado pelo usuário. Gere nomes internos, remova caracteres problemáticos e use diretórios por job. Antes de chamar FFmpeg, rode ffprobe e confira duração, streams, codec, resolução e tamanho. Defina limites de produto, como duração máxima de 30 minutos, tamanho máximo de 2 GB ou resolução máxima de 4K. Sem limites, um único upload pode consumir recursos que deveriam atender todos os clientes.

Backups, retenção e arquivos descartáveis

Backup em vídeo merece uma política clara. Banco de dados, metadados, presets, código e arquivos finais precisam de proteção. Temporários, arquivos incompletos e caches podem ser descartáveis. Se tudo entra no backup automático sem filtro, o custo sobe e a restauração fica lenta. Uma política comum é reter originais por 7 a 30 dias, manter finais enquanto o cliente estiver ativo e limpar temporários após algumas horas. Isso depende do produto, contrato e exigências legais.

Observabilidade fecha o ciclo. Monitore CPU, load average, memória, swap, disco livre, I/O, tempo médio por job, tamanho da fila, taxa de erro e tempo por etapa. Logs do FFmpeg devem ser guardados com cuidado, porque podem crescer rápido. Em produção, prefira registrar um resumo estruturado: comando executado, versão do FFmpeg, duração do vídeo, resolução de origem, formato final, tempo de processamento e erro, se houver. Esses dados permitem ajustar presets, aumentar ou reduzir workers e justificar upgrade de plano com base em evidência.

Recomendações por perfil

Dev solo e MVP

Para um dev solo validando produto, comece simples: 2 vCPUs, 4 GB de RAM, 80 GB de SSD e um único worker FFmpeg. Essa configuração cobre thumbnails, compressão leve e vídeos curtos sem criar uma conta alta logo no início. Use fila desde o primeiro dia, mesmo que seja Redis local, porque isso evita refatoração dolorosa depois. Guarde arquivos finais fora da pasta da aplicação e implemente limpeza automática de temporários. Se o projeto roda em Docker, limite CPU e memória do container. O objetivo do MVP não é processar tudo instantaneamente, é não derrubar a aplicação quando dois usuários fizerem upload ao mesmo tempo.

Time pequeno com API em produção

Para um time pequeno com clientes reais, separe a API do worker sempre que possível. A API precisa responder rápido, enquanto FFmpeg pode ocupar CPU por minutos. Um desenho comum usa 2 vCPUs e 4 GB para a API, mais um Cloud Server de 4 vCPUs, 8 GB de RAM e 120 GB de SSD ou NVMe para processamento. Essa separação facilita deploy, escala e troubleshooting. Se o backlog da fila crescer em horários de pico, suba outro worker temporário ou aumente a máquina de processamento. Registre métricas por job e crie alertas para disco abaixo de 20 por cento, swap acima de zero e fila parada por mais de alguns minutos.

Produção com alto volume

Em produção com alto volume, pense em pool de workers, storage externo e automação. Um único servidor grande pode funcionar por um tempo, mas escala horizontal costuma ser mais previsível: vários workers pegam jobs da mesma fila, processam arquivos de um bucket e enviam resultados para armazenamento durável. Comece em nós de 8 vCPUs e 16 GB de RAM, ajuste concorrência com testes e evite colocar banco, API e transcode pesado no mesmo host. Para alguns pipelines, GPU pode fazer sentido, mas isso exige outra análise de codecs, qualidade, disponibilidade e custo. Antes de contratar planos anuais ou comparar provedores por preço, faça um teste com seus próprios vídeos, presets e metas de tempo. Dados de preço, localidade, bandwidth e storage devem ser revisados manualmente nas fontes oficiais, já que mudam sem aviso editorial.