VPS para Playwright e Selenium em produção

Resposta direta

Para rodar Playwright e Selenium em produção, escolha uma VPS ou Cloud Server com pelo menos 2 vCPUs, 4 GB de RAM, 40 GB de SSD e Linux atualizado. Esse é um ponto de partida seguro para poucos navegadores Chrome headless simultâneos, testes end-to-end leves e automações agendadas. Se você pretende executar vários workers, capturar screenshots, gravar vídeos ou fazer scraping controlado com páginas pesadas, planeje 4 vCPUs, 8 GB de RAM e disco SSD ou NVMe. O segredo não está só no plano da VPS. A estabilidade vem da combinação entre limites de concorrência, Docker bem configurado, logs, filas, retries, backups e monitoramento de CPU, memória e processos Chrome travados.

Resumo rápido

• Playwright e Selenium consomem mais RAM e CPU que scripts HTTP simples, porque executam um navegador real.
• Para produção básica, comece com 2 vCPUs, 4 GB de RAM e 40 GB de SSD em Linux 22.04 LTS ou 24.04 LTS.
• Para 4 a 8 navegadores simultâneos, 4 vCPUs e 8 GB de RAM costumam ser um desenho mais confortável.
• Docker facilita deploy, isolamento de dependências e reprodução do ambiente entre notebook, CI e servidor.
• Use filas, limites de paralelismo e timeouts para evitar que o Chrome headless derrube a VPS.
• Nunca deixe painel, SSH, Redis, banco ou endpoint de automação expostos sem firewall e autenticação.
• Dados de preço, região, storage e bandwidth dos provedores devem ser confirmados nas páginas oficiais antes da publicação.

O que muda ao rodar Playwright e Selenium em produção

Rodar Playwright ou Selenium no notebook é bem diferente de manter automações de navegador em produção. Em ambiente local, um teste quebrado incomoda por alguns minutos. Em produção, um processo Chrome preso pode consumir RAM por horas, encher o disco com screenshots e bloquear uma fila inteira. Por isso, a decisão de infraestrutura precisa considerar o comportamento real do navegador, não apenas a linguagem usada no projeto.

Automação de navegador não é igual a script comum

Um script que chama uma API com requests, axios ou fetch costuma gastar pouca memória. Já Playwright e Selenium iniciam um navegador completo, mesmo em modo headless. Cada instância do Chromium pode usar de 150 MB a mais de 600 MB de RAM, dependendo do site, extensões, fontes, vídeos, tamanho da página e quantidade de abas. Em páginas com dashboards, mapas, React pesado ou muitos iframes, esse número sobe rápido.

Também existe consumo de CPU em picos. Carregamento de JavaScript, renderização, cálculo de layout, screenshots em alta resolução e PDFs exigem processamento. Um teste end-to-end com login, navegação por painel e validação de formulários pode parecer simples, mas abre conexões, baixa assets, executa scripts do front-end e mantém processos filhos do Chrome. Em uma VPS pequena de 1 vCPU e 1 GB de RAM, dois navegadores simultâneos já podem causar swap, timeouts e falhas intermitentes.

VPS, Cloud Server e cloud instance na prática

Uma VPS tradicional entrega uma fatia virtualizada de um servidor físico. Um Cloud Server ou cloud instance costuma trazer provisionamento mais flexível, upgrades rápidos, APIs e recursos de rede mais previsíveis, embora a nomenclatura varie por provedor. Para automações de navegador, a diferença prática aparece quando você precisa aumentar RAM, criar snapshots, clonar ambientes ou distribuir workers em várias instâncias.

Se o seu projeto usa Docker, filas e serviços auxiliares, vale ler também o guia de VPS para Docker, porque muitos cuidados são os mesmos: limites de memória, volumes persistentes, logs e reinício automático. No caso de Playwright e Selenium, esses pontos ficam mais sensíveis, já que o navegador cria vários processos e pode falhar de forma silenciosa quando falta memória compartilhada ou bibliotecas do sistema.

Recursos recomendados de CPU, RAM, disco e rede

O dimensionamento de VPS para Playwright e Selenium deve começar pela quantidade de navegadores simultâneos. Não pense apenas em visitantes, requisições ou quantidade de testes por dia. O número que pesa é quantas sessões de navegador ficam abertas ao mesmo tempo, por quanto tempo elas rodam e que tipo de página carregam. Um worker que abre uma página estática e tira screenshot consome muito menos que outro que faz login, navega por um SPA, baixa arquivos e gera PDF.

Como estimar consumo por navegador

Como regra inicial, reserve entre 300 MB e 700 MB de RAM por navegador Chromium em automações reais. Em uma VPS com 4 GB de RAM, depois do sistema operacional, Docker, agente de logs e aplicação, talvez sobrem 2,5 GB a 3 GB para navegadores. Isso permite algo como 3 a 5 sessões simultâneas com folga moderada. Se você rodar 8 sessões nessa mesma máquina, pode até funcionar em páginas leves, mas a estabilidade tende a cair quando algum site carregar scripts pesados.

CPU também precisa de margem. Para testes end-to-end, 2 vCPUs atendem um ambiente pequeno com 1 a 3 navegadores em paralelo. Para scraping controlado, captura recorrente de páginas e automações com filas, 4 vCPUs dão mais espaço para picos de renderização. Em workloads mais intensos, como geração de PDF em lote ou execução contínua de 10 workers, faz sentido dividir em duas ou mais VPS menores, em vez de concentrar tudo em uma máquina grande sem isolamento.

Disco influencia de duas formas. A primeira é instalação, cache e imagens Docker. A segunda é retenção de artefatos, como screenshots, vídeos, traces do Playwright, arquivos baixados e logs. Um plano com 40 GB de SSD pode servir para produção básica, mas 80 GB ou 120 GB ficam mais confortáveis quando há retenção de evidências por 7 a 30 dias. SSD ou NVMe ajudam em extração de arquivos, build de imagens e escrita de logs, mas não compensam falta de RAM.

Quando escalar verticalmente ou separar workers

Se o gargalo é memória, subir de 4 GB para 8 GB costuma resolver mais do que trocar apenas o tipo de disco. Se o gargalo é fila acumulada, CPU em 100 por cento e testes demorando demais, talvez seja hora de distribuir workers. Uma arquitetura simples pode usar uma VPS principal com API e Redis, mais duas VPS de workers executando Playwright. Para automações que expõem endpoints HTTP, o guia de Cloud Server para APIs e automações ajuda a pensar em latência, filas e separação de serviços.

Rede entra no cálculo quando o alvo está no Brasil, quando os jobs baixam muitos arquivos ou quando há captura de páginas externas com assets grandes. Datacenter no Brasil pode reduzir latência para sistemas nacionais, mas isso precisa ser confirmado por região e provedor. Bandwidth, franquia de transferência e política de uso aceitável variam bastante, então trate esses dados como pendentes de revisão humana antes de publicar uma recomendação fechada.

Instalação do Chrome headless, Playwright e Selenium

A instalação pode seguir dois caminhos. O primeiro é instalar tudo direto na VPS, usando pacotes do sistema e um gerenciador de processos como systemd ou PM2. O segundo é empacotar a automação em Docker. Para produção, Docker costuma ser mais previsível, mas entender a instalação nativa ajuda no troubleshooting, principalmente quando aparecem erros de biblioteca, fonte, sandbox ou permissão.

Base do sistema e dependências

Uma base comum é Ubuntu Server 22.04 LTS ou 24.04 LTS, com usuário sem privilégios para executar a aplicação. Depois de atualizar o sistema com apt update e apt upgrade, instale Node.js LTS ou Python 3.11 ou 3.12, conforme o projeto. No Playwright com Node.js, o comando npx playwright install --with-deps chromium instala o navegador e as bibliotecas necessárias em distribuições compatíveis. Em Python, python -m playwright install --with-deps chromium cumpre papel parecido.

No Selenium, o desenho mais comum hoje é usar Selenium Manager, que ajuda a localizar ou baixar drivers compatíveis, ou usar imagens oficiais do projeto Selenium quando a execução acontece em contêiner. Para Chrome headless moderno, evite tutoriais antigos que dependem de Xvfb sem necessidade. O Chrome atual roda headless nativamente, embora algumas bibliotecas gráficas ainda sejam necessárias para renderizar fontes, canvas, PDFs e elementos do sistema.

Um exemplo simples em Node.js usa playwright.chromium.launch com headless: true, timeout de 30 a 60 segundos e pasta temporária limpa por job. Em Python, o mesmo conceito aparece com async_playwright, contexto de navegador por tarefa e fechamento explícito no bloco final. O ponto crítico é sempre fechar browser, context e page, mesmo quando uma exceção acontece. Jobs que não fecham recursos viram processos órfãos.

Exemplo prático com Node.js e Python

Em um worker pequeno, limite a concorrência com uma variável como MAX_BROWSERS=3. Cada job pega uma URL da fila, cria um contexto isolado, define viewport de 1365 por 768, aplica timeout e salva screenshot em um diretório com limpeza automática. Para testes end-to-end, guarde apenas traces de falhas, não de todas as execuções. Um trace por teste pode ter alguns megabytes. Em 2.000 execuções por dia, isso vira um problema de disco antes de virar problema de CPU.

Para projetos Python, especialmente quando a automação faz parte de uma aplicação web, a estrutura de deploy se aproxima do que já acontece em Django, Celery e Redis. O artigo de VPS para Python e Django no Brasil traz uma base útil para separar aplicação, workers, banco e serviços auxiliares. A diferença é que, com Playwright ou Selenium, cada worker deve ter orçamento explícito de memória e um limite de tarefas antes de reiniciar, por exemplo reiniciar o processo a cada 100 jobs para reduzir vazamentos acumulados.

Docker, isolamento e execução previsível

Docker é uma das formas mais práticas de colocar Playwright e Selenium em produção porque reduz a distância entre desenvolvimento, CI e VPS. Em vez de instalar manualmente Chrome, fontes e bibliotecas em cada servidor, você versiona a imagem. Isso facilita rollback, auditoria e migração para outro provedor. Ainda assim, contêiner não elimina os limites físicos da VPS. Se a máquina tem 4 GB de RAM, todos os contêineres competem por esse total.

Por que Docker ajuda em automações

Playwright oferece imagens oficiais com browsers e dependências já instalados. Elas são maiores que imagens Node.js ou Python comuns, mas economizam horas de correção de erro em produção. Em um fluxo simples, a imagem contém o código, instala dependências, define usuário não root e executa o worker. O deploy pode ser feito com Docker Compose, usando serviços como worker, redis e, se necessário, api.

Um exemplo de arquitetura pequena usa três contêineres na mesma VPS: Redis para fila, API para receber jobs e worker para executar o navegador. O worker recebe MAX_BROWSERS=2, volume para /app/artifacts e política de reinício unless-stopped. Em produção, defina rotação de logs no Docker para evitar arquivos gigantes. Um limite como 10 MB por arquivo e 5 arquivos por contêiner já evita surpresas em servidores pequenos.

Cuidados com sandbox, memória compartilhada e volumes

Muitos tutoriais recomendam rodar Chrome com --no-sandbox. Isso pode ser necessário em alguns ambientes de contêiner, mas não deve virar padrão sem avaliação. O ideal é usar imagem oficial, usuário apropriado e configuração de segurança compatível. Quando o sandbox precisar ser desativado, compense com isolamento de rede, contêiner sem privilégios, secrets fora da imagem e firewall bem definido.

Outro ponto clássico é /dev/shm, a área de memória compartilhada usada pelo Chromium. O valor padrão em Docker pode ser pequeno, o que causa falhas estranhas, páginas em branco ou navegador encerrando sem mensagem clara. Há duas alternativas comuns: aumentar shm_size no Docker Compose, por exemplo 1 GB, ou usar a flag --disable-dev-shm-usage, que joga parte do trabalho para disco. A primeira opção costuma ser melhor quando há RAM disponível. A segunda pode ajudar em VPS muito restrita, mas pode deixar a execução mais lenta.

Volumes também merecem cuidado. Screenshots, PDFs e downloads devem ir para um diretório persistente apenas se você realmente precisa guardar esses arquivos. Para artefatos temporários, use limpeza por idade, como remover arquivos com mais de 48 horas. Em automação de navegador, disco cheio vira erro genérico rapidamente: Chrome não cria perfil temporário, Playwright falha ao iniciar contexto e Selenium retorna timeout sem explicar a causa real.

Filas, concorrência e operação de workers

A maioria dos problemas em produção não vem da instalação inicial, mas da operação diária. Uma automação funciona bem com 10 jobs e falha com 1.000 porque não existe controle de concorrência, retry inteligente ou observabilidade. Playwright e Selenium precisam ser tratados como workloads de worker, não como scripts soltos no crontab sem limite.

Controle de paralelismo

O desenho mais seguro é colocar jobs em uma fila, como Redis com BullMQ no Node.js, Celery no Python ou Sidekiq no Ruby. Cada worker consome uma quantidade limitada de tarefas ao mesmo tempo. Em uma VPS de 2 vCPUs e 4 GB de RAM, comece com 2 navegadores simultâneos. Monitore por 24 a 72 horas antes de subir para 3 ou 4. Se a RAM ficar acima de 80 por cento por longos períodos, reduza concorrência ou aumente o plano.

Timeouts precisam existir em três camadas. A primeira é timeout de navegação, por exemplo 30 segundos para page.goto. A segunda é timeout do job, como 2 minutos para uma captura simples ou 10 minutos para um fluxo completo de teste end-to-end. A terceira é timeout da fila, para impedir que jobs travados fiquem eternamente em execução. Sem isso, uma página externa lenta pode prender um worker até alguém reiniciar a VPS.

Logs, retries e idempotência

Logs bons economizam madrugada. Registre job_id, URL ou identificador interno, tempo total, status, erro resumido, uso aproximado de memória e caminho dos artefatos. Não grave cookies, tokens, CPF, senha ou conteúdo sensível. Para falhas transitórias, use retries com backoff, por exemplo 3 tentativas com 30 segundos, 2 minutos e 5 minutos. Para falhas de autenticação ou mudança de layout, retry infinito só aumenta custo e ruído.

Idempotência também faz diferença. Se um job baixa uma nota fiscal, atualiza um cadastro ou dispara um alerta, ele precisa tolerar repetição sem duplicar efeitos. Em scraping controlado, guarde hash do conteúdo, data da coleta e status HTTP quando disponível. Para testes end-to-end, separe ambiente de teste e produção real. Executar automação que clica em botões de pagamento ou altera dados reais exige travas adicionais, usuários dedicados e limpeza planejada.

Para manter workers vivos, use systemd, PM2, supervisord ou orquestração via Docker Compose. Configure reinício automático, mas não esconda falhas. Se o contêiner reinicia 50 vezes em uma hora, isso precisa gerar alerta. Uma VPS pequena pode se recuperar sozinha de uma falha pontual, mas uma sequência de reinícios costuma indicar falta de memória, versão incompatível do navegador ou mudança no site automatizado.

Segurança, backups e boas práticas para scraping controlado

Automação de navegador costuma lidar com credenciais, cookies, dados de clientes e páginas privadas. Por isso, uma VPS para Playwright e Selenium não deve ser tratada como máquina descartável sem política de segurança. Mesmo quando o workload parece simples, um endpoint mal protegido pode permitir que terceiros usem seu servidor para abrir URLs arbitrárias, consumir recursos, acessar redes internas ou coletar dados indevidos.

Acesso, firewall e segredos

Comece pelo básico: SSH com chave, senha desativada, usuário sem root para deploy e firewall liberando apenas portas necessárias. Em muitos casos, somente 22, 80 e 443 precisam ficar acessíveis, e a porta 22 pode ser restrita por IP quando a operação permitir. Redis, banco de dados, painel de filas e métricas devem ficar na rede interna ou atrás de VPN, nunca expostos diretamente na internet sem autenticação forte.

Segredos devem ficar em variáveis de ambiente, secret manager ou arquivo protegido fora do repositório. Não coloque tokens, cookies ou senhas dentro da imagem Docker. Também não salve estado de sessão em diretórios compartilhados sem controle. Se a automação usa login persistente, proteja o arquivo de storage state do Playwright com permissões restritas e rotação planejada. Em Selenium, o mesmo cuidado vale para perfis de navegador, cookies exportados e downloads temporários.

Backups, snapshots e recuperação

Backups precisam cobrir o que é persistente: banco, configurações, filas duráveis, scripts, variáveis e artefatos que tenham valor. Screenshots temporários podem ser descartados. Evidências de auditoria talvez precisem retenção por 30, 90 ou 180 dias, conforme o negócio. Defina isso antes, porque guardar tudo em disco local deixa a VPS cara e frágil. Para volumes maiores, armazenamento de objetos costuma ser mais adequado que SSD local.

Snapshots são úteis antes de atualizações de sistema, troca de versão do Chrome ou mudança grande no pipeline. Backup automático, snapshot incluso, região disponível e SLA variam por provedor e plano. Esses dados precisam ser verificados nas páginas oficiais no dia da publicação. LetsCloud, DigitalOcean, Vultr, Linode/Akamai, AWS Lightsail, Google Cloud, Azure, Hetzner e Contabo podem aparecer em avaliações de infraestrutura, mas localidade, tipo de storage, bandwidth e recursos extras mudam com o tempo. Não trate nenhum recurso como universal sem checagem.

No scraping controlado, respeite termos de uso, limites de acesso, robots.txt quando aplicável e legislação de proteção de dados. A parte técnica não substitui avaliação jurídica e ética. Use rate limit, identifique integrações quando houver acordo, não colete dados sensíveis sem base legal e mantenha logs de auditoria. Uma VPS bem dimensionada não deve virar justificativa para tráfego agressivo.

Comparação prática de perfis de VPS

A tabela abaixo não é um comparativo de preço nem uma recomendação fechada de provedor. Ela serve para traduzir carga de trabalho em recursos mínimos e pontos de atenção. Os números são referências editoriais para planejamento inicial, não substituem teste com seu fluxo real. Antes de contratar, confirme CPU, RAM, armazenamento, região, bandwidth, política de uso e backups no site oficial do provedor escolhido.

Tabela de dimensionamento

Perfil de uso	Configuração inicial	Concorrência sugerida	Disco e artefatos	Observações de operação
Testes end-to-end ocasionais	2 vCPUs, 4 GB RAM, 40 GB SSD	1 a 3 navegadores	Guardar traces só em falhas	Bom para QA pequeno, deploy diário e smoke tests
Scraping controlado leve	2 vCPUs, 4 GB RAM, 60 GB SSD	2 a 4 navegadores	Limpeza a cada 48 ou 72 horas	Use rate limit, retries curtos e logs por job
Workers contínuos	4 vCPUs, 8 GB RAM, 80 GB SSD ou NVMe	4 a 8 navegadores	Enviar evidências para storage externo	Recomendado separar Redis, API e workers quando crescer
Execução pesada com PDFs e vídeos	8 vCPUs, 16 GB RAM, 160 GB SSD ou NVMe	8 a 12 navegadores	Retenção definida por política	Melhor validar com benchmark próprio antes de produção

Como interpretar os números

Se você está começando, não contrate a maior máquina só por medo. Comece com uma configuração que permita medir. Instale monitoramento simples com métricas de CPU, RAM, disco, load average, quantidade de processos Chrome e tempo médio por job. Depois rode uma carga parecida com a produção por algumas horas. Um teste de 5 minutos raramente mostra vazamento de memória, crescimento de logs ou acúmulo de arquivos temporários.

Quando a fila cresce, observe a causa. Se os jobs passam muito tempo esperando rede externa, aumentar CPU não resolve. Se o Chrome trava ao abrir páginas com muitos assets, RAM e /dev/shm podem ser o problema. Se screenshots demoram para salvar ou builds Docker ficam lentos, disco entra no radar. Em times maiores, um desenho com múltiplas VPS de workers pequenos pode ser mais resiliente que uma única VPS grande. Você reinicia um worker sem parar a API e consegue distribuir execuções por projeto, cliente ou prioridade.

Recomendações por perfil

Dev solo

Para um desenvolvedor solo que roda capturas, automações internas ou testes de um produto pequeno, uma VPS com 2 vCPUs, 4 GB de RAM e 40 GB de SSD é um ponto de partida equilibrado. Use Docker Compose com um worker, Redis opcional e limite de 2 navegadores simultâneos. Guarde apenas screenshots de erro, aplique limpeza diária e monitore disco. Se a automação roda poucas vezes por dia, cron pode servir, mas uma fila simples dá mais controle quando aparecem retries, timeouts e prioridade de tarefas.

Time de QA ou produto

Um time de QA que executa suítes end-to-end após deploy precisa de previsibilidade. O ideal é separar ambiente de teste, workers e armazenamento de artefatos. Comece com 4 vCPUs, 8 GB de RAM e 80 GB de SSD, limitando a execução a 4 ou 6 navegadores simultâneos. Playwright traces devem ser salvos apenas quando houver falha, porque o volume cresce rápido. Integre alertas ao Slack, e-mail ou ferramenta interna quando a taxa de erro passar de um limite, como 5 por cento em 30 minutos.

Produção com workers contínuos

Para produção contínua, como scraping controlado, monitoramento de páginas, geração de PDFs ou automações de backoffice, pense em arquitetura, não apenas VPS. Uma máquina pode hospedar API e fila, enquanto duas ou mais VPS executam workers. Um início razoável é 4 vCPUs e 8 GB de RAM por worker, com MAX_BROWSERS entre 4 e 6. Quando o volume crescer, escale horizontalmente. Essa abordagem reduz impacto de falhas, facilita manutenção e permite trocar versão do navegador em um grupo pequeno antes de atualizar toda a operação.

Independentemente do perfil, revise mensalmente métricas, custos e incidentes. Automação de navegador muda com frequência porque sites mudam, navegadores atualizam e dependências quebram. Uma VPS que estava folgada em janeiro pode ficar apertada depois que a aplicação passa a capturar vídeo, abrir mais abas ou processar páginas com front-end mais pesado.