Apache Airflow no Brasil: VPS para pipelines

Resposta direta

Para rodar Apache Airflow no Brasil em uma VPS, comece pensando na arquitetura, não apenas no tamanho do plano. Um ambiente de produção básico costuma pedir 2 a 4 vCPUs, 4 GB a 8 GB de RAM, 60 GB a 100 GB de SSD ou NVMe, PostgreSQL como banco de metadados e uma estratégia clara para filas, logs, backups e restauração. Se os pipelines chamam APIs brasileiras, bancos hospedados no Brasil ou serviços internos da empresa, uma VPS ou Cloud Server com datacenter nacional pode reduzir latência e simplificar compliance operacional. Para ambientes com CeleryExecutor, separe webserver, scheduler, banco e workers quando o volume crescer. Em projetos pequenos, tudo pode começar na mesma máquina, desde que haja monitoramento, swap controlado, firewall, snapshots e backup externo testado.

Resumo rápido

• Apache Airflow precisa de CPU estável para scheduler, parsing de DAGs e execução de tarefas Python.
• Para produção pequena, use como base 2 vCPUs, 4 GB de RAM e 60 GB de SSD, com PostgreSQL separado ou bem isolado.
• CeleryExecutor exige broker de filas, normalmente Redis ou RabbitMQ, além de workers dedicados.
• Datacenter no Brasil ajuda quando as fontes de dados, APIs e usuários também estão no país.
• Logs, metadados e artefatos crescem rápido, então disco e retenção precisam ser planejados desde o início.
• Backup bom é aquele que foi restaurado em teste, não apenas um job marcado como ativo no painel.
• LetsCloud, DigitalOcean, Vultr, AWS Lightsail e outros provedores podem atender, mas preço, região, disco e backup devem ser verificados nas páginas oficiais antes da publicação.

O que muda ao rodar Apache Airflow em uma VPS no Brasil

Apache Airflow não é apenas um painel bonito para agendar tarefas. Ele é um orquestrador de workflows que mantém estado, agenda DAGs, executa tarefas, registra logs, conversa com bancos, chama APIs e coordena workers. Em uma VPS para Apache Airflow no Brasil, a escolha do servidor afeta desde o tempo de resposta do painel até a estabilidade de pipelines que rodam de madrugada, quando ninguém está olhando.

A primeira decisão é entender se você precisa de uma VPS tradicional, um Cloud Server ou uma instância cloud elástica. Na prática editorial, usamos VPS para o servidor virtual com acesso root, recursos definidos e autonomia de configuração. Cloud Server costuma indicar uma camada mais flexível, com provisionamento rápido, upgrades mais simples e, em alguns provedores, recursos distribuídos em infraestrutura cloud. Já uma cloud instance em hyperscalers como AWS, Google Cloud ou Azure normalmente vem integrada a redes privadas, discos gerenciados, IAM e serviços auxiliares. O Airflow roda nos três modelos, mas a operação muda bastante.

Em um projeto pequeno, por exemplo, uma única VPS com Ubuntu 22.04 ou 24.04, Docker Compose, Airflow webserver, scheduler, PostgreSQL e Redis pode ser suficiente para 10 a 30 DAGs leves. Pense em rotinas como baixar CSVs de um ERP, normalizar dados com Python e gravar no PostgreSQL uma vez por hora. Esse tipo de carga pede previsibilidade, não necessariamente escala gigante.

A localização no Brasil entra quando a latência importa. Se suas DAGs consomem APIs de pagamento nacionais, sistemas fiscais, bancos PostgreSQL no Brasil ou serviços internos via VPN, manter o Airflow perto dessas fontes reduz o tempo de conexão e diminui falhas por timeout. Em pipelines com centenas de chamadas HTTP curtas, sair de 150 ms para algo como 10 ms a 30 ms por requisição pode mudar a janela total do job. Não é mágica, mas soma.

Também existe o fator operacional. Times brasileiros muitas vezes preferem cobrança em reais, suporte no mesmo fuso e rotas de rede mais previsíveis para usuários locais. LetsCloud pode entrar nesse contexto quando houver plano e localidade adequados, mas é necessário confirmar no site oficial disponibilidade de região, tipo de disco, snapshots, backup e condições comerciais. O mesmo cuidado vale para qualquer provedor. Preço e recursos mudam, e comparativo de custo precisa de revisão humana antes de publicação.

Se você já mantém aplicações Python em produção, a lógica é parecida com a de um backend Django: isolar dependências, controlar workers, cuidar de logs e manter banco saudável. O artigo sobre VPS para Python e Django no Brasil aprofunda essa base e ajuda a entender por que Airflow também se beneficia de ambiente previsível, acesso root e deploy controlado.

Arquitetura mínima para Airflow em produção

Uma instalação de Apache Airflow em produção tem pelo menos quatro peças lógicas: webserver, scheduler, banco de metadados e executor de tarefas. Em versões recentes, também pode aparecer o triggerer, usado para operadores assíncronos e sensores mais eficientes. Mesmo quando tudo roda na mesma VPS, pensar nessas peças separadamente evita um erro comum: comprar um servidor olhando só para RAM total e ignorar concorrência entre processos.

O webserver serve a interface administrativa. Ele não costuma ser a parte mais pesada, mas sofre quando o banco de metadados está lento ou quando há muitas DAGs com histórico extenso. O scheduler é mais sensível. Ele lê arquivos de DAG, interpreta código Python, calcula o que deve rodar e envia tarefas ao executor. Se suas DAGs importam bibliotecas pesadas, fazem chamadas externas durante o parse ou têm centenas de tarefas, o scheduler consome CPU e memória antes mesmo de executar o pipeline.

Para produção pequena, uma arquitetura realista é Docker Compose com Airflow webserver, scheduler, triggerer, PostgreSQL e Redis na mesma VPS. Um exemplo de base seria 2 vCPUs, 4 GB de RAM, 60 GB de SSD, swap de 2 GB apenas como rede de segurança e limites de memória nos containers. Essa configuração aguenta bem laboratórios internos, cargas horárias e pipelines leves, desde que as tarefas não processem grandes volumes localmente.

Quando os jobs começam a rodar em paralelo, o executor muda o jogo. O SequentialExecutor serve para testes e desenvolvimento. O LocalExecutor já permite paralelismo na própria máquina, bom para 20 a 50 tarefas leves por dia. O CeleryExecutor distribui execuções entre workers, usando Redis ou RabbitMQ como broker. Nesse modelo, a VPS principal pode manter webserver, scheduler e banco, enquanto uma ou mais VPS menores executam workers.

Um erro frequente é confundir Airflow com motor de processamento. Ele orquestra. Se uma tarefa baixa 20 GB de dados, transforma tudo com Pandas e grava Parquet local, quem sofre é a máquina que executa a task. Se outra DAG apenas dispara um job no dbt, consulta uma API e monitora resultado, a carga fica bem menor. Por isso, antes de escolher o plano, estime quantas tarefas rodam ao mesmo tempo, quanto cada uma usa de RAM e se o processamento acontece dentro do worker ou em serviços externos.

Na prática, defina três números logo no desenho inicial: parallelism, max_active_tasks_per_dag e worker_concurrency, quando usar Celery. Um ambiente pequeno pode começar com parallelism=16, max_active_tasks_per_dag=4 e worker_concurrency=4. Se cada tarefa Python usa 300 MB, quatro tarefas simultâneas podem consumir 1,2 GB só nos workers, fora Airflow, PostgreSQL, Redis, sistema operacional e cache de disco. Essa conta simples evita muita instabilidade.

CPU, RAM, disco e rede: como dimensionar sem chute

Dimensionar VPS para Apache Airflow no Brasil exige olhar para três cargas diferentes. A primeira é a carga de orquestração, que envolve scheduler, webserver e banco de metadados. A segunda é a carga das tarefas, que pode variar de scripts Python leves a processamento pesado em Pandas, chamadas de API, consultas SQL longas ou geração de arquivos. A terceira é a carga operacional, composta por logs, backups, atualizações, monitoramento e retenção de histórico.

Para um ambiente de entrada em produção, 2 vCPUs e 4 GB de RAM funcionam como piso razoável quando há poucas DAGs e baixa concorrência. Use esse perfil para até 20 DAGs simples, execuções horárias ou diárias e tarefas que delegam o trabalho pesado para bancos externos. Se as tasks rodam ETL local, manipulam DataFrames acima de 500 MB ou executam várias rotinas ao mesmo tempo, pule para 4 vCPUs e 8 GB de RAM. Acima de 100 DAGs, workers concorrentes e janelas apertadas de processamento, pense em 8 vCPUs, 16 GB de RAM ou arquitetura distribuída.

Disco merece atenção própria. Airflow grava logs por tentativa de tarefa, estado no banco e, dependendo da implementação, arquivos temporários e artefatos. Um pipeline que roda 200 tarefas por dia, com logs de 500 KB por task, gera cerca de 100 MB diários só em logs. Em 90 dias, isso passa de 9 GB sem contar metadados, pacotes, imagens Docker e backups locais. Por isso, 40 GB pode parecer suficiente no primeiro mês e apertado no trimestre seguinte. Uma base mais confortável é 80 GB a 100 GB para produção pequena.

SSD já resolve boa parte dos cenários, mas NVMe ajuda quando há muito I/O, logs intensos, múltiplos containers, banco local e tarefas que leem e gravam arquivos temporários. Não trate NVMe como solução universal. Se o gargalo é uma API lenta ou uma consulta remota no data warehouse, disco rápido não reduz a espera. Ainda assim, para PostgreSQL local e parsing frequente de DAGs, latência de disco menor traz uma operação mais agradável.

Rede também entra na conta. Pipelines que transferem arquivos de 2 GB diariamente precisam de banda, estabilidade e controle de timeout. Para APIs nacionais, datacenter brasileiro reduz ida e volta da conexão. Para fontes nos Estados Unidos ou Europa, uma VPS no Brasil pode aumentar a latência até essas fontes, então a escolha depende de onde estão dados, usuários e sistemas de destino. Em integrações híbridas, teste com curl, ping, mtr e um job piloto antes de migrar produção.

Um exemplo prático: uma fintech pequena agenda 40 DAGs por dia, cada uma chama APIs internas no Brasil, valida JSONs e grava resultados em PostgreSQL. Um Cloud Server com 4 vCPUs, 8 GB de RAM e 100 GB de SSD, com PostgreSQL bem configurado, tende a ser mais equilibrado que uma VPS mínima. Já uma consultoria que roda Airflow apenas para acionar jobs em BigQuery ou Snowflake pode usar 2 vCPUs e 4 GB, porque o processamento pesado fica fora do servidor.

Banco de metadados, filas e workers sem ponto único frágil

O banco de metadados é o coração operacional do Airflow. Ele guarda DAG runs, task instances, conexões, variáveis, pools, usuários e histórico de execução. SQLite aparece em tutoriais, mas não deve ser usado em produção. Para VPS, PostgreSQL é a escolha mais comum porque entrega consistência, bom suporte, ferramentas maduras de backup e facilidade de monitoramento. MySQL também é suportado, mas PostgreSQL costuma ser uma decisão segura para times que já usam SQL no dia a dia.

Se o PostgreSQL roda na mesma VPS do Airflow, separe limites de recursos e ajuste parâmetros básicos. Em uma máquina com 8 GB de RAM, reservar algo entre 1 GB e 2 GB para PostgreSQL pode ser suficiente para metadados de um ambiente pequeno. Configurações como shared_buffers=1GB, effective_cache_size=3GB e retenção controlada de logs podem ajudar, mas devem ser ajustadas com teste. O conteúdo sobre VPS para banco PostgreSQL aprofunda dimensionamento de CPU, RAM, disco e backup para esse banco, útil quando o metastore sai do básico.

O segundo ponto é a fila. Com CeleryExecutor, o Airflow precisa de um broker. Redis é simples, rápido e comum em setups com Docker Compose. RabbitMQ é mais robusto para filas complexas, roteamento e operação com maior controle. A escolha depende do time. Redis tende a ser mais fácil para começar. RabbitMQ oferece recursos maduros de mensagens, mas pede mais atenção em memória, discos, políticas de filas e monitoramento. Se você já usa mensageria na empresa, faz sentido padronizar. O guia de VPS para RabbitMQ e filas de mensagens explica essa camada com foco em durabilidade, consumo e operação.

Workers são onde as tarefas realmente rodam. Em um ambiente pequeno, um worker na mesma VPS pode funcionar. Em produção mais séria, separar workers evita que uma task pesada derrube webserver, scheduler e banco. Imagine uma DAG que carrega um arquivo CSV de 3 GB por engano. Se tudo está na mesma máquina sem limites, a task pode consumir RAM, ativar swap, atrasar o scheduler e deixar o painel instável. Com worker separado e limites por container, o impacto fica contido.

Uma boa prática é começar com isolamento lógico e evoluir para isolamento físico. No Docker Compose, coloque webserver, scheduler, triggerer, PostgreSQL, Redis e worker em serviços separados, com volumes nomeados e limites de recursos. Depois, quando a carga crescer, mova PostgreSQL para uma VPS própria ou serviço gerenciado, e adicione workers em novas instâncias. Esse caminho evita uma migração traumática.

Também cuide da limpeza do metastore. Airflow acumula histórico. Sem rotação, a interface fica lenta e consultas internas pioram. Defina uma política, por exemplo manter 90 dias de task logs locais, exportar logs antigos para storage externo e executar rotina periódica de limpeza de metadados. Em pipelines auditáveis, retenção pode ser maior, mas precisa de disco e backup compatíveis.

Tabela prática de perfis para Apache Airflow

A tabela abaixo não substitui teste de carga, mas ajuda a transformar requisitos soltos em uma configuração inicial. Os valores são referências editoriais para planejamento. Preços, regiões, largura de banda, tipo de armazenamento, backup e recursos inclusos variam por provedor e devem ser confirmados nas páginas oficiais antes de publicar qualquer comparação comercial.

Perfil de uso	Arquitetura sugerida	Recursos iniciais	Banco e fila	Exemplo real de carga	Pontos de atenção
Laboratório ou dev solo	Tudo em uma VPS com Docker Compose	2 vCPUs, 4 GB RAM, 60 GB SSD	PostgreSQL e Redis locais	10 a 20 DAGs, tarefas diárias, scripts Python leves	Backup externo, limites de containers e limpeza de logs
Time pequeno de dados	VPS principal mais worker separado, ou Cloud Server maior	4 vCPUs, 8 GB RAM, 100 GB SSD ou NVMe	PostgreSQL local bem ajustado ou separado, Redis ou RabbitMQ	30 a 80 DAGs, execuções horárias, APIs e cargas SQL	Monitoramento do scheduler, retenção de metadados e filas
Produção crítica	Componentes separados em múltiplas instâncias	8 vCPUs, 16 GB RAM na camada principal, workers dedicados	PostgreSQL separado, broker dedicado, backup testado	100 ou mais DAGs, várias tarefas simultâneas, SLA interno	Alta disponibilidade, restore ensaiado e observabilidade completa
Integração com sistemas brasileiros	VPS ou Cloud Server em datacenter nacional	4 vCPUs, 8 GB RAM, 80 GB a 100 GB SSD	PostgreSQL próximo das aplicações, broker local	APIs fiscais, ERPs, gateways de pagamento e bancos nacionais	Latência nacional, rotas de rede, VPN e regras de firewall

Na prática, o perfil de laboratório é útil para validar DAGs, operadores, conexões e convenções de deploy. Ele não deve virar produção sem revisão. É comum o ambiente começar pequeno, ganhar 40 DAGs em poucos meses e virar dependência do time financeiro, comercial ou de BI. Quando isso acontece sem planejamento, qualquer atualização do Docker, falta de disco ou pico de memória vira incidente.

O perfil de time pequeno é o mais comum em empresas que estão saindo do cron tradicional. A equipe troca scripts espalhados em servidores por DAGs versionadas no Git, com retries, logs, painel e alertas. Aqui, 4 vCPUs e 8 GB de RAM dão margem para scheduler, webserver, banco e algumas tarefas concorrentes. Se houver transformação local com Pandas, aumente RAM ou mova processamento para workers dedicados.

Produção crítica pede desenho mais conservador. O Airflow pode ser responsável por cargas de faturamento, conciliação, atualização de dashboards executivos ou sincronização entre sistemas. Nesse cenário, evite ponto único de falha quando possível. Separe PostgreSQL, broker e workers. Mantenha infraestrutura como código, monitore fila e scheduler, configure alertas por e-mail, Slack ou webhook e documente como restaurar o serviço em outra VPS.

Sobre provedores, DigitalOcean, Vultr, Linode/Akamai, AWS Lightsail, Google Cloud, Azure, Hostinger, Locaweb, HostGator e LetsCloud aparecem com frequência em pesquisas de VPS e cloud. Alguns têm presença, parceiros ou opções no Brasil, outros focam regiões internacionais. Como disponibilidade muda por plano e data, este artigo não publica ranking de preço. A decisão editorial aqui é técnica: escolha a infraestrutura que melhor encaixa latência, recursos, operação, suporte e previsibilidade para seu pipeline.

Segurança, backup e operação diária

Airflow em produção costuma guardar credenciais sensíveis. Conexões com bancos, tokens de API, chaves de serviços e variáveis de ambiente passam pelo sistema. Por isso, segurança não pode ficar para depois. A primeira camada é a VPS: acesso SSH com chave, login root desativado quando possível, firewall permitindo apenas portas necessárias, atualizações de segurança e fail2ban ou mecanismo equivalente para reduzir força bruta.

A interface web do Airflow não deve ficar aberta para a internet sem controle. Use autenticação forte, HTTPS com certificado válido e, se possível, restrição por VPN, IP fixo ou proxy autenticado. Em ambientes pequenos, um Nginx na frente do webserver resolve TLS e controle básico de acesso. Em empresas, prefira integração com provedor de identidade, grupos de usuários e papéis mínimos. Um operador que só acompanha DAGs não precisa permissão para editar conexões sensíveis.

Segredos merecem cuidado especial. Evite colocar senha dentro do arquivo da DAG. Use variáveis de ambiente, backend de secrets ou, no mínimo, conexões do Airflow com acesso restrito. Em Docker Compose, nunca publique .env em repositório. No Git, deixe um .env.example sem valores reais, apenas com nomes das variáveis. Parece simples, mas muitos vazamentos começam por um arquivo de configuração enviado por engano.

Backup deve cobrir três camadas: banco de metadados, DAGs e configuração. O banco guarda estado e histórico. As DAGs geralmente estão no Git, mas o servidor precisa conseguir recuperar a versão correta. A configuração inclui airflow.cfg, variáveis de ambiente, compose files, scripts de deploy e chaves operacionais. Um snapshot da VPS ajuda, mas não substitui backup lógico do PostgreSQL. Snapshots podem carregar corrupção ou ficar presos ao provedor. Backup externo dá mais liberdade.

Uma rotina prática para produção pequena pode ser: pg_dump diário do metastore, retenção de 7 cópias diárias e 4 semanais, envio para storage externo, snapshot antes de atualizações maiores e teste mensal de restauração em uma VPS temporária. Para logs, defina rotação local e exportação para armazenamento apropriado quando houver obrigação de auditoria. Se os logs contêm dados pessoais, cuide também de mascaramento e retenção.

Monitoramento fecha o ciclo. Acompanhe uso de CPU, RAM, disco, I/O, fila, tempo de parsing das DAGs, tarefas em retry e falhas por timeout. Alertas simples já ajudam: disco acima de 80%, scheduler sem heartbeat, PostgreSQL indisponível, worker offline e fila crescendo por mais de 15 minutos. Sem isso, o time descobre problemas pelo dashboard atrasado ou pelo usuário final, o pior tipo de observabilidade.

Recomendações por perfil

Dev solo ou laboratório de dados

Para dev solo, consultor ou analista técnico testando Apache Airflow, uma VPS com 2 vCPUs, 4 GB de RAM e 60 GB de SSD é um ponto de partida honesto. Rode tudo com Docker Compose, mantenha DAGs no Git e use PostgreSQL em vez de SQLite desde cedo para não criar diferenças entre teste e produção. Limite a concorrência com parallelism=8 e max_active_tasks_per_dag=2, principalmente se as tarefas usam Pandas ou bibliotecas pesadas. Esse perfil combina bem com estudos, automações internas, integrações simples e pipelines diários. Mesmo assim, configure backup externo do banco e não exponha o painel do Airflow sem HTTPS e autenticação.

Time pequeno com pipelines recorrentes

Para um time pequeno de dados, engenharia ou BI, pense em 4 vCPUs, 8 GB de RAM e 100 GB de SSD ou NVMe, com scheduler e webserver protegidos do impacto das tarefas. Se ainda estiver tudo na mesma VPS, use limites de recursos por container e acompanhe memória dos workers. Se as DAGs rodam a cada 15 minutos, chamam APIs brasileiras, carregam planilhas grandes e atualizam dashboards, considere um worker separado. PostgreSQL pode continuar local por um tempo, mas precisa de backup, vacuum, retenção de metadados e monitoramento. Aqui, datacenter no Brasil costuma ajudar quando fontes e consumidores também estão no país, especialmente em integrações com sistemas internos via VPN.

Produção crítica com múltiplos workers

Para produção crítica, trate Airflow como plataforma, não como script agendado. Separe PostgreSQL, broker e workers em instâncias próprias ou serviços gerenciados quando o orçamento permitir. Uma camada principal com 8 vCPUs e 16 GB de RAM pode hospedar webserver, scheduler e triggerer, enquanto workers dedicados escalam conforme o volume de tarefas. Use CeleryExecutor, RabbitMQ ou Redis bem monitorado, backup testado, logs centralizados e deploy com rollback. Defina limites por DAG, pools para recursos disputados e alertas para falha de scheduler, fila acumulada e disco cheio. Nesse nível, a escolha da VPS depende menos do menor preço e mais de operação previsível, rede estável, restauração rápida e clareza contratual sobre recursos.

Empresa com dependência de sistemas no Brasil

Quando as DAGs conversam com ERPs, bancos, APIs fiscais, gateways de pagamento, CRMs nacionais ou bancos de dados em datacenter brasileiro, priorize latência e rota de rede. Uma VPS para Apache Airflow no Brasil pode reduzir timeouts e facilitar VPNs site-to-site, listas de IP permitidos e comunicação com fornecedores locais. Comece com 4 vCPUs, 8 GB de RAM e 100 GB de disco, mas teste o caminho real dos dados antes de decidir. Rode uma DAG piloto por alguns dias, medindo tempo de conexão, falhas HTTP, throughput de download e variação em horários de pico. Se o processamento final está em nuvem internacional, talvez faça sentido dividir workers por região.

Migração de cron para Airflow

Quem sai de cron jobs espalhados em uma ou mais VPS precisa organizar antes de migrar. Liste scripts, horários, dependências, tempo médio, consumo de memória, entradas, saídas e dono do processo. Depois agrupe em DAGs com retries, SLAs internos e alertas. Para esse perfil, a VPS deve ter folga, porque a primeira migração costuma revelar scripts ineficientes que antes passavam despercebidos. Uma base com 4 vCPUs, 8 GB de RAM e 100 GB de disco evita começar no limite. Mantenha os crons antigos desligados, mas documentados, por alguns dias, até confirmar que Airflow executa tudo com histórico, logs e recuperação aceitáveis.