ASP.NET Core no Brasil: como escolher VPS

Resposta direta

Para rodar ASP.NET Core em produção no Brasil, a escolha mais equilibrada costuma ser uma VPS Linux com 2 vCPUs, 4 GB de RAM, 60 GB de SSD ou NVMe e datacenter próximo do público. Essa base atende APIs, painéis administrativos e aplicações web de tráfego moderado com Kestrel atrás de Nginx ou Caddy. Uma VPS Windows faz sentido quando o projeto depende de IIS, Windows Authentication, componentes legados do .NET Framework, COM, bibliotecas exclusivas de Windows ou administração feita por uma equipe já padronizada no ecossistema Microsoft. Para aplicações modernas em .NET 8 ou .NET 9, Linux geralmente reduz consumo operacional, simplifica automação e facilita deploy com Docker.

Resumo rápido

• ASP.NET Core é multiplataforma, então Linux atende a maioria das aplicações modernas em .NET.
• Uma configuração inicial segura para produção leve é 2 vCPUs, 4 GB de RAM e 60 GB de SSD.
• APIs com muitas conexões, filas ou relatórios pesados devem começar em 4 vCPUs e 8 GB de RAM.
• VPS Windows é indicada quando há dependência real de IIS, .NET Framework, Windows Authentication ou SQL Server local.
• Para público brasileiro, datacenter no Brasil costuma reduzir latência percebida em APIs, login, checkout e dashboards.
• Banco de dados no mesmo servidor simplifica o início, mas exige mais RAM, backup disciplinado e monitoramento de disco.
• Docker funciona bem com ASP.NET Core, mas precisa de limites de memória, logs controlados e volumes persistentes.
• A decisão não deve olhar só preço. Compatibilidade, operação, backup, suporte e previsibilidade pesam muito no ambiente final.

O que muda ao rodar ASP.NET Core em VPS no Brasil

ASP.NET Core mudou bastante a forma como aplicações .NET são publicadas. Durante muitos anos, a resposta automática para qualquer sistema Microsoft era usar Windows Server e IIS. Hoje, uma API em ASP.NET Core pode rodar muito bem em Linux usando o runtime oficial da Microsoft, Kestrel como servidor de aplicação e Nginx ou Caddy como reverse proxy. Isso abre espaço para usar VPS Linux no Brasil com um modelo operacional parecido com Node.js, Go, Java ou PHP moderno.

Na prática, a primeira pergunta não é se .NET roda em Linux. Roda. A pergunta certa é o que a sua aplicação exige além do runtime. Uma API REST em .NET 8, com Entity Framework Core, PostgreSQL, Redis e deploy via GitHub Actions, tende a funcionar melhor em Linux pela simplicidade de automação. Já um sistema que ainda usa partes do .NET Framework, componentes COM, integrações antigas via DLL nativa ou autenticação integrada do Windows pode exigir Windows Server. Antes de escolher, vale mapear dependências reais, não preferências históricas.

O Brasil entra na análise por causa de latência, suporte e cobrança. Se o usuário final está em São Paulo, Rio de Janeiro, Belo Horizonte, Curitiba, Fortaleza ou Recife, hospedar em uma região brasileira pode reduzir dezenas ou centenas de milissegundos em cada ida e volta quando comparado a servidores nos Estados Unidos ou Europa. Em uma API com cinco chamadas no carregamento inicial, essa diferença aparece no tempo de tela pronta. Em um painel administrativo, aparece na sensação de resposta a cada filtro, busca ou gravação.

Também existe a diferença entre VPS tradicional, Cloud Server e cloud instance. Uma VPS tradicional costuma ser uma máquina virtual em um servidor físico, com recursos definidos por plano. Um Cloud Server geralmente oferece provisionamento mais flexível, rede em nuvem, imagens prontas e upgrades mais simples. Cloud instances de provedores globais seguem a mesma lógica, mas com mais serviços gerenciados ao redor. Se você ainda está comparando sistemas operacionais, o artigo sobre VPS Linux ou VPS Windows ajuda a separar compatibilidade técnica de hábito operacional.

Linux é o caminho padrão para a maioria dos projetos

Em projetos novos, Linux costuma ser o ponto de partida. Ubuntu LTS, Debian e AlmaLinux recebem runtime .NET, certificados TLS, agentes de monitoramento e pipelines de deploy sem dificuldade. O consumo de memória do sistema operacional tende a ser menor que em Windows Server, o que deixa mais RAM disponível para a aplicação, banco, cache e processos auxiliares.

Windows entra quando há dependência real do ecossistema Microsoft

VPS Windows não é erro. Ela só deve ser escolhida por motivo claro. IIS, Active Directory, Windows Authentication, SQL Server com administração local e compatibilidade com aplicações legadas são bons motivos. O problema é usar Windows apenas porque o projeto é .NET, mesmo quando o código já é ASP.NET Core moderno e portátil.

CPU, RAM, disco e rede para ASP.NET Core

Dimensionar ASP.NET Core exige olhar o comportamento da aplicação, não apenas a linguagem. Uma API simples, com endpoints CRUD, autenticação JWT e banco PostgreSQL remoto, consome muito menos que um sistema que gera PDF, processa imagens, roda jobs em background e mantém SignalR com milhares de conexões. Para produção pequena, 2 vCPUs e 4 GB de RAM formam uma base confortável. Dá para rodar a aplicação, Nginx, logs, agente de monitoramento e até um PostgreSQL leve no mesmo servidor, desde que o tráfego seja controlado e os backups estejam configurados.

Em homologação ou MVP com baixo tráfego, 1 vCPU e 2 GB de RAM podem funcionar, mas não são uma boa margem para produção. O problema aparece em picos: deploy com compilação no servidor, coleta de logs excessiva, consultas mal indexadas ou GC pressionado por objetos grandes. Em ASP.NET Core, o runtime é eficiente, mas não faz milagre se a aplicação carrega listas enormes em memória ou serializa respostas JSON de vários megabytes. Uma API que retorna 20 mil registros por requisição vai sofrer em qualquer servidor pequeno.

CPU importa em três situações comuns. A primeira é concorrência, quando muitas requisições chegam ao mesmo tempo. A segunda é processamento, como geração de relatórios, compressão, criptografia, exportação CSV e manipulação de imagens. A terceira é banco de dados local, porque PostgreSQL, MySQL ou SQL Server também competem por CPU. Para uma API B2B com 50 a 150 usuários simultâneos, 4 vCPUs e 8 GB de RAM são um ponto de partida mais realista, especialmente se houver background services no mesmo host.

O disco também merece atenção. SSD já é aceitável, mas NVMe ajuda em cenários com muitos logs, banco local, filas persistentes, uploads e leitura frequente de arquivos pequenos. O ganho não aparece da mesma forma em toda aplicação. Se o gargalo está em consulta sem índice, o disco rápido só mascara o problema por algum tempo. Para aprofundar essa etapa, use a lógica de dimensionamento explicada em como escolher CPU, RAM e NVMe, porque ASP.NET Core sofre com os mesmos gargalos de qualquer API em produção.

Configuração mínima realista

Uma base prática é 2 vCPUs, 4 GB de RAM, 60 GB de SSD e sistema operacional Linux LTS. Reserve pelo menos 20 GB para sistema, pacotes e logs, 10 GB para releases e artefatos, e o restante para banco, uploads ou margem de crescimento. Se o banco estiver fora da VPS, 40 GB podem bastar no começo.

Quando subir para 4 vCPUs ou mais

Suba para 4 vCPUs quando houver jobs em background, relatórios pesados, filas com consumidores paralelos, SignalR ou banco de dados no mesmo servidor. Se a aplicação atende clientes pagantes, a folga de CPU também reduz risco em deploys, migrações e picos de uso após campanhas.

Disco e latência de I/O

Logs sem rotação são uma causa comum de servidor cheio. Configure retenção e compressão. Em Linux com systemd, ajuste journald. Em Docker, limite tamanho de logs por container. Para banco local, monitore IOPS, latência de escrita e crescimento de tabelas, não apenas espaço livre.

Linux ou Windows: a decisão que afeta custo e operação

A escolha entre Linux e Windows muda o modo de administrar a VPS. Em Linux, o fluxo mais comum para ASP.NET Core é publicar a aplicação como serviço systemd, rodar Kestrel em uma porta interna, colocar Nginx ou Caddy na frente e automatizar deploy por SSH, rsync, GitHub Actions ou container. O resultado é previsível e leve. Um servidor Ubuntu LTS com firewall, usuário sem root direto, fail2ban, certificados automáticos e logs organizados cobre a maioria dos cenários de API e aplicação web.

Em Windows Server, o caminho clássico é IIS com Application Pool, Web Deploy, certificados no painel do IIS e administração por RDP ou PowerShell. Essa abordagem é familiar para equipes vindas de ambientes corporativos Microsoft. Também facilita cenários com Windows Authentication, integração com Active Directory e aplicações que ainda carregam dependências de Windows. O custo operacional pode ser maior por licenciamento, consumo de memória e manutenção, mas a compatibilidade pode compensar quando o sistema precisa desses recursos.

Um erro frequente é misturar argumento técnico com conforto da equipe. Se o time só conhece IIS, talvez Windows reduza atrito no curto prazo. Mas se o produto precisa escalar, usar containers, padronizar CI/CD e reduzir dependências de ambiente, Linux tende a ser mais simples no médio prazo. A decisão não precisa ser ideológica. Faça um teste de deploy em staging nos dois ambientes. Meça tempo de publicação, consumo em repouso, consumo em carga, facilidade de rollback e capacidade da equipe de diagnosticar erro em madrugada.

Também olhe para o banco. Se você usa SQL Server por exigência do produto, ainda pode rodar a aplicação ASP.NET Core em Linux e usar SQL Server gerenciado, SQL Server em outra VM ou Azure SQL. Não é obrigatório colocar tudo em Windows. Se o banco está no mesmo host e precisa de ferramentas gráficas ou rotinas antigas, Windows pode ficar mais atraente. Em qualquer caso, documente a razão. Se daqui a seis meses alguém perguntar por que a VPS é Windows, a resposta precisa ser mais concreta que “sempre fizemos assim”.

Quando escolher VPS Linux

Escolha Linux para APIs em .NET 8 ou .NET 9, microsserviços, aplicações containerizadas, serviços com PostgreSQL ou MySQL, automação por pipeline e ambientes que valorizam baixo consumo base. Ubuntu LTS é uma escolha comum pela documentação ampla e compatibilidade com pacotes da Microsoft.

Quando escolher VPS Windows

Escolha Windows quando houver IIS obrigatório, .NET Framework legado, dependências nativas de Windows, autenticação integrada, RDP como requisito operacional ou padrões corporativos que exigem Windows Server. Nesses casos, dimensione RAM com mais folga, muitas vezes começando em 4 GB para ambientes leves e 8 GB para produção.

Cuidados com licenciamento e painel

Preço, licenças, regiões, backups e recursos de painel variam por provedor e plano. Esses dados precisam ser confirmados no site oficial antes da compra. Não assuma que snapshot, backup automático, IP adicional ou licença Windows estão inclusos.

Banco de dados, cache e arquivos em produção

O banco de dados é onde muitas decisões de VPS para ASP.NET Core deixam de ser simples. Rodar aplicação e banco no mesmo servidor reduz custo e latência interna, mas concentra risco. Se a VPS cair, aplicação e dados ficam indisponíveis juntos. Se uma consulta pesada consome CPU, a API também sofre. Para MVP, sistema interno ou produto em validação, essa arquitetura pode ser aceitável com 4 GB a 8 GB de RAM, backup externo e monitoramento. Para produção com clientes pagantes, separar banco e aplicação costuma trazer mais previsibilidade.

PostgreSQL combina bem com ASP.NET Core e Entity Framework Core. MySQL ou MariaDB também são comuns, principalmente quando a equipe já usa esse ecossistema. SQL Server entra quando há dependência de recursos específicos, legado corporativo ou exigência de BI e relatórios já montados nessa plataforma. Se SQL Server estiver na mesma VPS Windows, considere 8 GB de RAM como ponto mais seguro para produção pequena, porque sistema operacional, IIS, aplicação e banco competem pela mesma memória. Em Linux com PostgreSQL local, 4 GB podem servir para começar, mas 8 GB dão margem para cache de banco e picos.

Cache é outro ponto. Redis pode guardar sessões distribuídas, tokens, respostas temporárias, locks e filas leves. Ele é rápido, mas usa RAM. Se a VPS tem 4 GB e você coloca aplicação, banco e Redis no mesmo host, precisa impor limites. Um Redis sem política de memória pode crescer até pressionar o sistema e provocar swap. Em ASP.NET Core, configure expiração de chaves e monitore uso. Para filas mais robustas, RabbitMQ ou serviços gerenciados podem ser melhores que improvisar tudo no mesmo servidor.

Arquivos exigem estratégia. Uploads de imagens, PDFs e anexos não devem ficar esquecidos em uma pasta local sem backup. Se a aplicação salva arquivos em /var/www/app/uploads, o deploy não pode apagar esse diretório. Em Docker, use volumes persistentes. Para crescimento maior, considere object storage compatível com S3. Logs também entram nessa conta. Uma API com log em nível Information para cada requisição pode gerar gigabytes por semana. Configure rotação, retenção de 7 a 30 dias conforme necessidade e envio para uma ferramenta externa quando o sistema ficar crítico.

SQL Server, PostgreSQL e MySQL

SQL Server pede atenção especial a licença, memória e edição usada. PostgreSQL costuma oferecer excelente equilíbrio para aplicações web modernas. MySQL é uma escolha válida quando a equipe já domina índices, backups e replicação. O melhor banco é o que o time sabe operar sob pressão.

Redis e filas em workloads .NET

BackgroundService, Hangfire, Quartz.NET e MassTransit aparecem muito em projetos ASP.NET Core. Se os workers rodam no mesmo servidor da API, reserve CPU e memória. Uma fila que processa imagens ou integrações externas pode derrubar o tempo de resposta se não houver isolamento.

Uploads, logs e retenção

Defina onde arquivos persistentes vivem antes do primeiro deploy. Separe diretório de release de diretório de dados. Use backup externo e teste restauração. Backup que nunca foi restaurado é só uma hipótese otimista.

Deploy, observabilidade e segurança do ambiente

O deploy de ASP.NET Core em VPS pode ser simples sem ser frágil. Em Linux, um fluxo comum é compilar no CI, enviar o artefato publicado para o servidor, trocar um symlink de release e reiniciar o serviço systemd. O arquivo .service define usuário, diretório de trabalho, variáveis de ambiente e reinício automático. Um exemplo de produção leve usa dotnet MinhaApi.dll escutando em http://127.0.0.1:5000, com Nginx recebendo HTTPS na porta 443 e repassando para Kestrel. Esse desenho reduz exposição direta da aplicação e facilita certificados.

Docker é uma alternativa forte quando o time quer padronizar ambiente. Uma imagem multi-stage com SDK no build e runtime no estágio final reduz tamanho e superfície de ataque. Ainda assim, Docker não elimina operação. Você precisa configurar limites de memória, política de restart, healthcheck, volumes para dados persistentes e rotação de logs. Em uma VPS de 2 vCPUs e 4 GB, subir API, banco, Redis e worker em containers sem limites pode funcionar no primeiro mês e virar problema quando o tráfego cresce.

Em Windows, IIS continua sendo uma opção sólida. Use Application Pool dedicado, configure variáveis de ambiente fora do código, habilite logs com retenção e monitore reciclagens inesperadas. PowerShell ajuda a automatizar deploy e rollback. RDP deve ser protegido com senha forte, firewall restritivo e, quando possível, VPN ou acesso por IP permitido. Em Linux, SSH deve usar chave, bloquear login root direto e manter firewall permitindo apenas portas necessárias, normalmente 22, 80 e 443, com a porta 22 restrita quando a operação permitir.

Observabilidade precisa começar antes do incidente. Monitore CPU, memória, disco, latência HTTP, taxa de erro 5xx, tempo de resposta por endpoint e status do banco. Logs estruturados com Serilog ou OpenTelemetry ajudam a entender falhas sem acessar o servidor às cegas. Para aplicações em APIs e microsserviços, o guia sobre VPS para APIs e microsserviços no Brasil complementa bem a parte de rede, escalabilidade e separação de serviços.

Deploy com systemd, Docker ou IIS

Systemd é simples e eficiente para uma ou poucas aplicações. Docker ajuda a padronizar e replicar ambiente. IIS é adequado para equipes Windows e integrações Microsoft. A escolha deve considerar rollback, logs, variáveis sensíveis, treinamento do time e tempo de recuperação.

Reverse proxy e HTTPS

Nginx, Caddy e IIS podem terminar TLS. Caddy simplifica certificados automáticos. Nginx oferece controle fino e ampla documentação. Em todos os casos, redirecione HTTP para HTTPS, revise headers e limite tamanho de upload conforme a aplicação.

Backups, snapshots e restauração

Snapshot não substitui backup de banco. Backup de banco não substitui backup de arquivos. Guarde cópias fora da VPS, criptografe quando houver dados sensíveis e faça teste de restauração em ambiente separado. Preço e disponibilidade de snapshots variam por provedor e exigem revisão humana.

Tabela prática de dimensionamento

A tabela abaixo usa perfis técnicos, não preços. Ela serve como ponto de partida para conversar com o provedor e com o time de desenvolvimento. Recursos de planos, regiões, tipo de disco, franquia de tráfego, backup e snapshots mudam com frequência, então qualquer dado comercial precisa ser verificado nas páginas oficiais antes da contratação. A lógica principal é simples: quanto mais responsabilidades você coloca na mesma VPS, mais CPU, RAM, disco e rotina operacional ela precisa ter.

Perfil de uso	Sistema indicado	Recursos iniciais	Banco de dados	Deploy comum	Observações
MVP ou sistema interno	Linux LTS	2 vCPUs, 4 GB RAM, 40 a 60 GB SSD	PostgreSQL ou MySQL local leve	systemd ou Docker Compose	Bom para validar produto, exige backup externo desde o primeiro dia
API pública com tráfego moderado	Linux LTS	4 vCPUs, 8 GB RAM, 80 GB SSD ou NVMe	Banco separado ou local bem monitorado	CI/CD, Nginx, Kestrel	Indicado para 50 a 150 usuários simultâneos, depende do peso dos endpoints
SaaS com jobs e filas	Linux LTS	4 a 8 vCPUs, 8 a 16 GB RAM, 100 GB NVMe	Banco separado recomendado	Docker, workers isolados	Separe API, workers e banco quando o volume crescer
Legado corporativo Microsoft	Windows Server	4 vCPUs, 8 GB RAM, 80 GB SSD	SQL Server local ou remoto	IIS e Web Deploy	Faz sentido com IIS, .NET Framework, Windows Authentication ou dependências nativas
Ambiente crítico	Linux ou Windows conforme dependência	8 vCPUs, 16 GB RAM ou mais	Banco gerenciado ou servidor dedicado	Pipeline com rollback	Exige monitoramento, backup testado e plano de recuperação documentado

Um exemplo ajuda. Uma API ASP.NET Core para um aplicativo interno de vendas, com 30 usuários simultâneos e PostgreSQL local, pode começar em 2 vCPUs e 4 GB se as consultas forem simples. Se esse mesmo sistema gerar relatórios em PDF, importar planilhas e enviar e-mails em lote, 4 vCPUs e 8 GB viram uma escolha mais segura. Já um SaaS que processa pagamentos, webhooks e filas de integração não deveria depender de uma única VPS pequena para tudo. Nesse caso, separar banco, worker e aplicação reduz falhas em cadeia.

LetsCloud, DigitalOcean, Vultr, Linode/Akamai, AWS Lightsail, Hostinger, Locaweb e outros provedores podem atender partes desses cenários, mas a comparação precisa confirmar região disponível, sistema operacional, storage, tráfego, backup, snapshots, suporte e regras de cobrança. No caso da LetsCloud, localidades como Brasil ou Miami, tipo de storage e recursos adicionais devem ser confirmados por plano no site oficial antes de afirmar disponibilidade específica. Não trate NVMe, backup automático ou snapshots como universais sem validação atual.

Recomendações por perfil

Dev solo ou projeto pequeno

Para um desenvolvedor solo publicando um MVP, painel administrativo ou API de baixa concorrência, a rota mais prática é Linux LTS com 2 vCPUs, 4 GB de RAM e 40 a 60 GB de SSD. Use ASP.NET Core publicado em modo Release, Kestrel atrás de Nginx ou Caddy, banco PostgreSQL local se o orçamento for curto e backup diário enviado para fora da VPS. Evite compilar no servidor em produção. Gere o artefato no CI e envie apenas o publicado. Esse cuidado economiza CPU, reduz dependências instaladas e torna rollback mais simples.

Time de produto com API em produção

Para um time que mantém API usada por clientes, comece com 4 vCPUs, 8 GB de RAM e disco SSD ou NVMe. Separe banco quando houver orçamento, principalmente se o produto já tem receita. Configure pipeline com testes, migrações controladas, healthcheck, logs estruturados e monitoramento de erro. Se houver workers, rode processos separados da API, mesmo que estejam na mesma VPS no início. Isso facilita limitar consumo e diagnosticar gargalos. O time também deve documentar como restaurar backup, renovar certificado, trocar variável de ambiente e reverter deploy ruim.

Ambiente crítico com Windows ou SQL Server

Quando a aplicação depende de Windows Server, IIS, SQL Server local, autenticação integrada ou componentes legados, planeje a VPS Windows com folga. Para produção pequena, 4 vCPUs e 8 GB de RAM são um ponto de partida mais realista que planos mínimos. SQL Server e IIS consomem memória, e o sistema operacional também precisa de margem para atualizações e tarefas administrativas. Restrinja RDP, use firewall, mantenha patches em dia e teste restauração do banco. Se o banco crescer rápido, considere separar SQL Server em outra instância ou usar serviço gerenciado compatível com a política da empresa.

Agência ou consultoria com vários clientes

Agências costumam querer colocar vários projetos ASP.NET Core na mesma VPS para reduzir custo. Funciona quando os sistemas são pequenos, mas exige isolamento. Use usuários separados, diretórios separados, Application Pools distintos no Windows ou serviços systemd separados no Linux. Em Docker, limite CPU e memória por container. O maior risco é um cliente com bug ou pico de tráfego afetar todos os outros. Para cinco aplicações pequenas, uma VPS com 4 vCPUs e 8 GB pode servir. Para clientes pagantes com SLA contratual, prefira separar ambientes.

SaaS em crescimento

Um SaaS que já tem usuários ativos precisa pensar além da primeira VPS. A recomendação é manter aplicação stateless sempre que possível, mover uploads para storage externo, separar banco de dados, isolar workers e monitorar filas. A VPS continua útil para hospedar API, painel, jobs leves e serviços auxiliares, mas não deve virar um bloco indivisível. Se cada deploy exige medo de derrubar banco, worker e front-end juntos, a arquitetura chegou no limite. Nesse estágio, a pergunta deixa de ser apenas tamanho da VPS e passa a ser desenho de operação.