Como escolher VPS para servidor SFTP no Brasil

Resposta direta

Uma VPS para servidor SFTP no Brasil faz sentido quando a empresa precisa trocar arquivos com segurança, controlar usuários por chave SSH, manter logs de acesso e reduzir latência para parceiros nacionais. Para produção básica, uma configuração de 2 vCPUs, 2 GB de RAM, 40 a 80 GB de SSD e tráfego mensal compatível com o volume de arquivos costuma atender rotinas pequenas e médias. Ambientes com muitos arquivos simultâneos, backups diários ou integrações B2B devem considerar 4 vCPUs, 4 a 8 GB de RAM, disco SSD ou NVMe e política de backup externa. O ponto central não é só contratar a VPS. É configurar OpenSSH com SFTP restrito, chroot por usuário, firewall, rotação de logs, monitoramento de disco e restauração testada.

Resumo rápido

• SFTP usa SSH e não deve ser confundido com FTP ou FTPS.
• Para produção básica, comece com 2 vCPUs, 2 GB de RAM e 40 a 80 GB de SSD.
• Para integrações B2B com vários parceiros, 4 vCPUs e 4 a 8 GB de RAM dão mais folga.
• Disco e rede pesam mais do que CPU quando há arquivos grandes ou muitos uploads simultâneos.
• Chaves SSH, chroot, firewall e logs são requisitos mínimos para operação segura.
• Servidor no Brasil tende a reduzir latência para empresas e filiais nacionais.
• Snapshot ajuda em rollback, mas backup externo é indispensável para recuperação real.
• Dados de preço, região e tipo de storage mudam por provedor e devem ser revisados antes da compra.

Quando faz sentido ter um servidor SFTP em VPS

Um servidor SFTP em VPS é útil quando a troca de arquivos precisa sair do improviso. Enviar planilhas por e-mail, compartilhar links temporários ou depender de pastas pessoais em serviços de nuvem pode funcionar no começo, mas cria problemas quando entram parceiros externos, arquivos sensíveis, rotinas automáticas e necessidade de auditoria. O SFTP resolve parte desse cenário porque roda sobre SSH, permite autenticação por chave, registra acessos e pode isolar cada usuário em seu próprio diretório.

SFTP não é FTP com TLS

SFTP significa SSH File Transfer Protocol. Ele não é uma versão segura do FTP tradicional. O FTPS usa FTP com TLS, enquanto o SFTP usa o canal SSH na porta 22 ou em outra porta definida pelo administrador. Na prática, isso simplifica firewall, automação e controle de identidade. Um robô de faturamento pode enviar arquivos .csv por chave SSH, um parceiro logístico pode baixar remessas diárias e um sistema legado pode consumir lotes sem precisar de VPN completa.

A VPS entra como uma camada de controle. Em hospedagem compartilhada, você quase nunca consegue configurar sshd_config, criar usuários presos por chroot, instalar agentes de monitoramento ou ajustar políticas de retenção. Em uma VPS, o time decide versão do sistema, regras de firewall, diretórios, permissões e scripts de manutenção. Se o ambiente já tem exigências de segurança, o tema conversa diretamente com práticas de hardening. Um bom complemento é revisar um checklist de VPS com firewall e hardening de segurança antes de expor o serviço para parceiros.

Cenários comuns no Brasil

No Brasil, SFTP aparece bastante em integrações B2B. Exemplos comuns incluem troca de arquivos CNAB com bancos, envio de XML ou CSV para ERPs, recebimento de relatórios de marketplaces, integração com transportadoras e sincronização de backups de filiais. Imagine uma rede varejista com 30 lojas enviando fechamento diário de caixa às 23h. O pico não dura o dia inteiro, mas concentra dezenas de uploads em poucos minutos. Nesse caso, CPU não é o único gargalo. O servidor precisa aceitar conexões simultâneas, gravar rápido em disco e manter espaço livre para retenção.

Também há casos mais simples. Uma agência pode manter um SFTP para receber arquivos grandes de clientes, como vídeos de 5 GB ou bases de imagens. Um escritório contábil pode separar diretórios por cliente e bloquear qualquer navegação fora da pasta designada. Já uma indústria pode usar SFTP como zona de troca entre sistemas internos e fornecedores, com arquivos processados a cada 10 minutos por um job. Esses exemplos mostram por que a escolha da VPS precisa olhar volume, frequência, segurança e operação diária, não apenas o menor plano disponível.

Como dimensionar CPU, RAM, disco e rede

Dimensionar uma VPS para servidor SFTP começa pelo comportamento dos arquivos. Um ambiente com 200 arquivos pequenos por dia exige recursos diferentes de outro com 20 arquivos de 10 GB. O SFTP em si não costuma consumir muita CPU em cargas leves, mas criptografia SSH, compressão, muitas sessões simultâneas e verificações de integridade podem aumentar o uso. Para um servidor pequeno, 2 vCPUs e 2 GB de RAM já permitem rodar OpenSSH, logs, firewall, monitoramento básico e scripts de limpeza. Em produção com parceiros externos, 4 vCPUs e 4 GB de RAM reduzem risco de lentidão em horários de pico.

Estimativa por volume de arquivos

Use uma conta simples. Se a empresa recebe 50 GB por dia e mantém retenção de 14 dias, só a área de entrada precisa de 700 GB antes de considerar processamento, duplicação, logs e margem de segurança. Se os arquivos são compactados depois do processamento, o consumo pode cair. Se ficam duplicados em pastas incoming, processed e archive, o consumo pode triplicar. Para não operar no limite, trabalhe com pelo menos 25% de espaço livre. Em Linux, disco cheio pode quebrar logs, impedir uploads e travar rotinas automáticas.

Para cenários pequenos, 40 a 80 GB de SSD atendem troca pontual de arquivos, desde que exista limpeza automática. Para cargas médias, 160 a 320 GB dão mais margem. Para backup de filiais, imagens, dumps de banco ou arquivos de mídia, pense em volumes maiores ou armazenamento externo. Não faz sentido usar o disco local da VPS como único cofre de backup. Ele pode ser rápido, mas continua dentro do mesmo ambiente operacional.

Disco e IOPS importam mais do que parece

SFTP parece simples, mas muitos arquivos pequenos geram bastante operação de metadados. Diretórios com 200 mil arquivos ficam lentos para listar, mover e apagar. Uma prática saudável é separar arquivos por data, cliente ou tipo, por exemplo /data/sftp/cliente-a/incoming/2026/08/10. Em uploads grandes, throughput sequencial pesa mais. Em integrações com milhares de arquivos pequenos, IOPS e latência de disco importam.

SSD é o mínimo recomendado para produção. NVMe pode ajudar em cenários de alto I/O, mas não deve ser tratado como solução mágica. Se a rede do parceiro é lenta, se o processo consome arquivos de forma serial ou se o gargalo está em um ERP, o disco rápido não resolve sozinho. Além disso, disponibilidade de NVMe varia por provedor, plano e localidade. Em qualquer compra, confirme tipo de storage, política de tráfego, limites de IOPS, possibilidade de expansão e cobrança por excedente no site oficial do provedor.

Rede também precisa entrar na conta. Um arquivo de 10 GB enviado por um parceiro com link real de 100 Mbps leva cerca de 13 a 15 minutos em condições boas. Com 10 parceiros fazendo upload ao mesmo tempo, o gargalo pode virar banda de entrada, processamento de criptografia ou disco. Para B2B, prefira planos com tráfego mensal claro, boa conectividade nacional e possibilidade de upgrade sem migração traumática.

Arquitetura segura para SFTP em produção

A segurança de um servidor SFTP depende menos de instalar um pacote e mais de configurar limites. O serviço geralmente usa OpenSSH, presente por padrão em distribuições como Debian, Ubuntu, Rocky Linux e AlmaLinux. O erro comum é criar usuários normais do sistema, liberar shell e entregar senha. Isso aumenta a superfície de ataque. O desenho mais seguro é permitir apenas SFTP, negar login interativo, usar chaves SSH, separar diretórios por cliente e registrar operações relevantes.

Acesso por chave SSH

Autenticação por senha facilita ataques de força bruta. Em produção, prefira chave pública por usuário ou por sistema integrado. Cada parceiro deve ter sua própria identidade, nunca uma chave compartilhada por todos. Se um fornecedor troca de equipe ou sofre incidente, você revoga apenas aquela chave. Um padrão prático é criar um usuário por parceiro, como sftp_banco, sftp_erp ou sftp_transportadora, e armazenar a chave pública em authorized_keys com permissões corretas.

Também vale mudar a porta SSH? Pode reduzir ruído de bots, mas não substitui chave, firewall e bloqueio de senha. A regra principal é negar PasswordAuthentication, limitar usuários permitidos com AllowUsers ou grupos dedicados e manter o sistema atualizado. Em ambientes maiores, uma VPN site to site ou allowlist de IPs dos parceiros adiciona uma camada útil. Só tenha cuidado com IP dinâmico, comum em empresas menores, porque isso pode gerar chamados fora do horário comercial.

Usuários isolados com chroot

O chroot prende o usuário em um diretório raiz virtual. Isso impede que um parceiro veja /etc, /home de outros usuários ou pastas de clientes. Uma configuração comum usa um grupo chamado sftpusers e uma regra no sshd_config com ForceCommand internal-sftp, ChrootDirectory e bloqueio de encaminhamento TCP. O diretório raiz do chroot precisa pertencer ao root e não pode ser gravável pelo usuário. A pasta de upload fica abaixo dele, por exemplo /sftp/cliente-a/upload, com dono correto.

Esse detalhe causa muitos erros. Se o usuário recebe mensagem de falha no login logo após autenticar, verifique permissões do caminho. O diretório /sftp/cliente-a deve ser do root, enquanto /sftp/cliente-a/upload pode ser do usuário. Parece burocrático, mas evita que o cliente altere o próprio ambiente de confinamento.

Firewall, logs e auditoria

Firewall deve permitir apenas o necessário. Para um SFTP público, normalmente entram SSH/SFTP e talvez uma porta de monitoramento restrita por IP. Painéis administrativos, banco de dados e serviços internos não devem ficar abertos para a internet. Se a VPS também hospedar aplicações, avalie separar funções. Um servidor de arquivos exposto a parceiros externos não precisa compartilhar o mesmo sistema de produção do site institucional.

Logs precisam ser preservados por tempo compatível com o negócio. Arquivos em /var/log/auth.log ou /var/log/secure registram autenticação, mas auditoria detalhada de upload e download pode exigir configuração adicional, scripts, logs do subsistema SFTP ou ferramentas como auditd. Para operação profissional, defina quem acessou, quando acessou, de qual IP, qual arquivo enviou e quando o arquivo foi processado. Sem isso, investigar uma divergência vira tentativa e erro.

Backup, retenção e recuperação de arquivos

SFTP costuma virar ponto de passagem, mas na prática muitos arquivos ficam ali por dias ou semanas. Isso cria uma pergunta operacional: se alguém apagar uma pasta errada às 2h da manhã, como restaurar? Backup precisa fazer parte do desenho desde o primeiro dia. Um snapshot da VPS é útil para voltar o sistema a um estado anterior, mas ele não resolve todos os casos. Se você restaurar um snapshot antigo, pode perder uploads recebidos depois dele. Se o snapshot fica na mesma infraestrutura e a conta é comprometida, o risco continua.

Snapshots não substituem backup

Snapshot é bom para rollback antes de mudanças, atualização do sistema ou alteração grande no sshd_config. Backup é cópia recuperável, preferencialmente com retenção, versionamento e destino separado. Em servidor SFTP, os dois se complementam. Um snapshot diário da VPS pode recuperar a configuração, enquanto backup incremental dos diretórios de dados preserva arquivos recebidos e processados. Para entender melhor a diferença operacional, o guia de VPS com backup automático ajuda a separar conveniência de proteção real.

Uma estratégia básica pode usar rsync para outro servidor, restic com backend S3 compatível, ou BorgBackup para repositório externo. Em ambiente regulado, criptografe o backup antes de sair da VPS. Não dependa apenas de permissões do storage. A chave de criptografia deve ficar fora do servidor principal, em cofre de senhas ou solução de secrets. Se a VPS for invadida e a chave estiver em texto puro no mesmo host, o invasor pode apagar ou corromper cópias.

Política prática de retenção

Retenção precisa refletir o ciclo do arquivo. Um exemplo comum: manter arquivos em incoming por 7 dias, mover processados para archive por 30 dias e guardar backup externo por 90 dias. Para arquivos fiscais, contratos ou dados regulatórios, esse prazo pode ser maior. Para dados pessoais sensíveis, guardar por tempo demais também vira risco. A política deve equilibrar recuperação, LGPD, contrato com parceiros e custo de armazenamento.

Automatize limpeza, mas com proteção. Um script find /data/sftp -type f -mtime +30 -delete parece eficiente, porém pode apagar arquivos importantes se aplicado no diretório errado. Prefira mover para quarentena antes de deletar, registrar logs e testar com -print antes de ativar remoção. Uma abordagem mais segura é separar incoming, processed, error e archive. Arquivos rejeitados por validação podem ir para error por 15 dias, com notificação para o time responsável.

Teste restauração. Esse ponto parece óbvio, mas é onde muitos ambientes falham. Uma vez por mês, restaure um arquivo aleatório em diretório temporário, valide hash, permissões e tempo necessário. Se recuperar 200 GB demora oito horas e seu contrato exige retomada em duas horas, o desenho está errado. Backup bom é aquele que volta dentro do prazo do negócio.

Brasil ou exterior: latência, compliance e operação

Escolher Brasil ou exterior para hospedar SFTP depende de quem envia e consome os arquivos. Se os parceiros estão no Brasil, uma VPS em datacenter nacional costuma reduzir latência e melhorar previsibilidade. A diferença aparece principalmente em conexões repetidas, listagens de diretório, arquivos pequenos e automações que abrem muitas sessões. Um servidor em São Paulo pode responder em poucos milissegundos para boa parte das redes nacionais. Um servidor nos Estados Unidos pode ficar acima de 120 ms, dependendo da rota. Isso não impede o uso, mas afeta integrações sensíveis a tempo e reconexão.

Latência para integrações B2B

SFTP não é apenas upload de arquivo grande. Muitos robôs fazem connect, list, put, rename, stat e disconnect várias vezes por lote. Cada operação sofre com latência. Se um parceiro envia 5 mil arquivos pequenos por noite, uma diferença de 20 ms para 150 ms por operação vira minutos extras de janela. Em rotinas bancárias, logística ou conciliação, esses minutos podem importar. Para avaliar a escolha entre localização nacional e internacional, a leitura sobre VPS Brasil ou exterior complementa bem a análise de latência, rota e público atendido.

Há também a experiência de suporte interno. Times brasileiros conseguem testar rotas com operadoras locais, simular upload a partir de filiais e acompanhar janelas no fuso horário do negócio. Isso não significa que exterior seja ruim. Provedores globais podem ter recursos maduros, APIs, snapshots, imagens prontas e rede forte. A decisão correta depende do perfil de uso. Se os arquivos vêm de parceiros nos Estados Unidos ou Europa, hospedar fora pode ser aceitável. Se a maior parte dos acessos vem de ERPs, bancos e fornecedores brasileiros, uma região nacional tende a fazer mais sentido.

Dados, auditoria e previsibilidade

Localidade também conversa com governança. Algumas empresas preferem manter dados em território nacional por política interna, contrato ou interpretação de risco. A LGPD não proíbe automaticamente transferência internacional, mas exige base legal, medidas de segurança e clareza sobre tratamento. Para SFTP com dados pessoais, notas fiscais, informações financeiras ou bases de clientes, documente onde os dados ficam, por quanto tempo, quem acessa e como são apagados.

Provedores como DigitalOcean, Vultr, Linode ou Akamai, AWS Lightsail, Google Cloud, Azure, Locaweb, Hostinger, HostGator e LetsCloud podem aparecer na avaliação, mas recursos variam bastante. Região, tipo de disco, tráfego, backup, suporte e preço precisam ser confirmados nas páginas oficiais no momento da contratação. No caso da LetsCloud, faz sentido analisar quando a prioridade é latência nacional e operação no mercado brasileiro, mas não se deve assumir NVMe, snapshots inclusos, backup automático ou suporte específico sem validar o plano e a localidade. Para qualquer provedor, trate preço e disponibilidade como dados voláteis.

Tabela comparativa de perfis de servidor SFTP

A tabela abaixo não compara preços de provedores. Ela organiza perfis técnicos para ajudar no dimensionamento inicial. Use como ponto de partida, depois valide métricas reais com logs, monitoramento de rede e crescimento esperado. Em SFTP, o erro mais comum é comprar pouco disco e esquecer retenção. O segundo erro é não considerar concorrência, ou seja, quantos parceiros podem enviar arquivos ao mesmo tempo.

Perfil de uso	Configuração inicial sugerida	Volume típico	Segurança mínima	Observações operacionais
Projeto interno ou dev solo	1 a 2 vCPUs, 1 a 2 GB RAM, 40 GB SSD	Até 10 GB por dia	Chave SSH, firewall, usuário sem shell	Bom para testes, relatórios internos e baixa concorrência
Integração B2B média	2 a 4 vCPUs, 4 GB RAM, 80 a 160 GB SSD	10 a 100 GB por dia	Chroot por parceiro, logs, allowlist quando possível	Exige limpeza automática, backup externo e alerta de disco
Produção crítica	4 a 8 vCPUs, 8 GB RAM, 320 GB ou mais, SSD ou NVMe conforme plano	Acima de 100 GB por dia	MFA no painel, chaves por parceiro, auditoria, backup criptografado	Considere segregação de ambientes, monitoramento 24x7 e teste de restauração
Backup de filiais	2 a 4 vCPUs, 4 a 8 GB RAM, disco dimensionado por retenção	Depende da janela e número de filiais	VPN ou IP allowlist, criptografia antes do envio	Atenção a deduplicação, compressão e tempo de recuperação

Para arquivos grandes, priorize throughput de rede, espaço livre e backup. Para muitos arquivos pequenos, priorize IOPS, organização de diretórios e processos que evitem listagens gigantes. Um diretório único com 500 mil arquivos pode se tornar lento mesmo em servidor com boa CPU. Separar por data reduz tempo de busca e facilita limpeza. Em um cenário com 20 parceiros, prefira algo como /data/sftp/parceiro/ano/mes/dia em vez de jogar tudo em /upload.

A configuração mínima também depende do que roda junto. Se a VPS hospeda apenas SFTP, o consumo é previsível. Se também roda antivírus, indexação, scripts Python, compactação, API de notificação e agente de backup, 2 GB de RAM podem ficar apertados. Um clamav analisando arquivos grandes pode consumir bastante memória. Compactar lotes com gzip ou zstd durante horários de pico aumenta CPU. O ideal é separar janelas: receber arquivo, validar, mover para processamento e executar tarefas pesadas fora do pico de upload.

Exemplo prático de configuração inicial

Um setup inicial em Debian ou Ubuntu pode ser simples, mas precisa seguir uma ordem segura. Comece atualizando o sistema, criando grupo SFTP, montando diretórios e configurando OpenSSH. Em produção, faça isso em uma sessão SSH separada e teste antes de fechar a conexão atual. Um erro no sshd_config pode bloquear acesso administrativo. Se possível, mantenha console web do provedor disponível durante a mudança.

Pacotes, usuários e diretórios

Um fluxo básico seria: criar o grupo sftpusers, criar diretório base em /data/sftp, criar um usuário sem shell e configurar chave pública. Exemplo conceitual:

sudo apt update && sudo apt upgrade
sudo groupadd sftpusers
sudo mkdir -p /data/sftp/cliente-a/upload
sudo useradd -g sftpusers -d /upload -s /usr/sbin/nologin cliente-a
sudo chown root:root /data/sftp/cliente-a
sudo chmod 755 /data/sftp/cliente-a
sudo chown cliente-a:sftpusers /data/sftp/cliente-a/upload
sudo chmod 750 /data/sftp/cliente-a/upload

No sshd_config, a ideia é aplicar regra por grupo. Use internal-sftp, force o comando SFTP e bloqueie recursos de SSH que não são necessários ao parceiro. Exemplo resumido:

Match Group sftpusers
    ChrootDirectory /data/sftp/%u
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no
    PermitTunnel no

Depois, valide com sshd -t antes de reiniciar o serviço. Esse comando detecta erro de sintaxe. Em seguida, use systemctl reload ssh ou equivalente. Teste login com um usuário de SFTP e confirme que ele cai diretamente no diretório esperado. Se o cliente vê erro de permissão, revise dono e modo dos diretórios, principalmente o diretório raiz do chroot.

Limites e observabilidade

Não deixe o servidor sem limites. Configure fail2ban para reduzir tentativas repetidas, ajuste firewall com ufw ou regras nativas, e acompanhe disco com alertas. Um monitoramento simples pode disparar aviso quando uso de disco passar de 75%, 85% e 95%. O primeiro alerta dá tempo de agir. O último já é quase incidente. Use também rotação de logs, porque logs de autenticação podem crescer em servidores expostos à internet.

Para troubleshooting, alguns comandos ajudam no dia a dia. journalctl -u ssh mostra eventos recentes do serviço. df -h mostra espaço em disco. du -sh /data/sftp/* identifica clientes que mais consomem. ss -tnp ajuda a ver conexões ativas. Para auditoria de arquivos, scripts podem registrar hash SHA-256 ao receber upload e salvar em banco leve ou arquivo append-only. Um padrão prático é exigir que o parceiro envie arquivo temporário com extensão .part e renomeie para .ready ao terminar. Assim, o processo interno só consome arquivos completos.

Também pense em antivírus e validação. Se o SFTP recebe arquivos de muitos parceiros, analisar extensões permitidas, tamanho máximo e padrão de nome reduz risco operacional. Você pode bloquear upload de executáveis por processo posterior, rejeitar arquivos acima de 20 GB quando o contrato prevê 2 GB, e mover nomes fora do padrão para pasta error. Essas regras parecem pequenas, mas evitam que um fornecedor derrube a rotina noturna com um arquivo errado.

Recomendações por perfil

Dev solo ou projeto interno

Para um dev solo, laboratório ou rotina interna de baixa criticidade, uma VPS pequena resolve bem. Comece com 1 a 2 vCPUs, 1 a 2 GB de RAM e 40 GB de SSD. Use Debian ou Ubuntu LTS, autenticação por chave SSH, ufw liberando apenas a porta escolhida e um único usuário SFTP sem shell. Mesmo em projeto pequeno, não use senha compartilhada. Se o volume passar de 5 a 10 GB por dia, configure limpeza automática por data e backup externo semanal. Esse perfil é adequado para relatórios, troca de arquivos com poucos usuários e integrações que podem ser refeitas se algo falhar.

Time de integração B2B

Para um time que atende bancos, ERPs, transportadoras ou parceiros comerciais, o servidor SFTP já é peça de integração. A recomendação inicial sobe para 2 a 4 vCPUs, 4 GB de RAM e 80 a 160 GB de SSD. Cada parceiro deve ter usuário, chave, diretório e política de retenção próprios. Configure chroot, logs, alerta de disco e backup externo diário. Também vale padronizar nomes de arquivos, janelas de envio e pastas incoming, processed, error e archive. Esse perfil precisa de documentação simples, com host, porta, fingerprint da chave do servidor, horário de manutenção e contato para incidente.

Produção crítica com auditoria

Em produção crítica, trate SFTP como serviço de infraestrutura, não como pasta remota. Use 4 a 8 vCPUs, 8 GB de RAM e disco dimensionado por retenção real, muitas vezes 320 GB ou mais. Considere SSD ou NVMe conforme disponibilidade do provedor e perfil de I/O, mas valide região, tráfego e backup antes da contratação. O painel do provedor deve ter MFA, usuários administrativos separados e controle de acesso. Backups precisam ser criptografados, externos e testados. Logs devem responder perguntas de auditoria: quem acessou, de onde, qual arquivo enviou, quando foi processado e quando foi removido. Se a janela de operação é curta, planeje monitoramento 24x7 ou plantão.