Como funciona e como montar uma pequena provedora de VPS para amigos

Uma empresa de VPS não instala um computador físico para cada cliente. Ela mantém servidores grandes em um datacenter, divide seus recursos em máquinas virtuais isoladas e utiliza um sistema de controle para criar, ligar, reinstalar e apagar essas máquinas automaticamente. É essa automação, somada a imagens de sistemas operacionais já preparadas, que permite comprar uma VPS e receber o acesso poucos minutos depois.

Esta pesquisa trata a ideia como uma microprovedora privada, inicialmente destinada a amigos. O foco está na infraestrutura: o que roda nos servidores físicos, como as VPS são criadas, onde entram KVM, QEMU, Proxmox, cloud-init, armazenamento, endereços IP, painéis e backups. Cobrança e formalização aparecem somente quando interferem no funcionamento técnico.

Resumo executivo

A resposta curta é:

não é normalmente Vagrant;
o servidor físico costuma executar Linux com um hipervisor, frequentemente KVM/QEMU;
um painel ou plataforma de nuvem controla os hipervisores por API;
cada sistema oferecido, como Debian ou Ubuntu, existe como uma imagem-base pronta;
quando o pagamento é aprovado, uma automação escolhe um host, cria o disco virtual, reserva CPU e RAM, atribui um IP, injeta a chave SSH e inicia a VM;
o cloud-init termina a personalização dentro do sistema convidado durante a primeira inicialização;
para um projeto pequeno, Proxmox VE + máquinas KVM + imagens cloud-init + backup externo forma a base mais sensata;
se houver venda automática e painel para clientes, VirtFusion, SolusVM ou Virtualizor são mais próximos da operação de uma provedora do que o Vagrant;
OpenStack, Apache CloudStack e OpenNebula resolvem esse problema em escalas maiores, mas adicionam complexidade desnecessária para atender alguns amigos.

A montagem recomendada para começar é:

Internet
   |
Datacenter com proteção DDoS e bloco de IPs
   |
Servidor dedicado
   |
Proxmox VE
   |
KVM/QEMU
   +-- VPS Debian do amigo A
   +-- VPS Ubuntu do amigo B
   +-- VPS AlmaLinux do amigo C
   +-- VM administrativa ou de monitoramento

Servidor ou armazenamento independente
   |
Proxmox Backup Server

O primeiro projeto deve ser deliberadamente pequeno: um servidor dedicado, planos conservadores, provisionamento inicialmente manual pelo painel e backups em outra máquina. A automação de pagamento pode ser acrescentada somente depois que criação, reinstalação, rede, restauração e remoção de uma VPS tiverem sido testadas repetidamente.

Metodologia e critérios

A pesquisa foi construída a partir de documentação oficial de Proxmox, KVM/libvirt, cloud-init, HashiCorp Vagrant, OpenStack, OpenNebula, Apache CloudStack e painéis comerciais voltados a provedores. Foram priorizados:

isolamento adequado entre clientes;
simplicidade para uma operação pequena;
capacidade de crescer sem reconstruir tudo;
automação por API;
recuperação depois de falha;
clareza sobre o que é fato documentado e o que é recomendação de arquitetura;
ferramentas com documentação e manutenção verificáveis.

Não é possível afirmar qual é a arquitetura interna exata da Contabo apenas observando seu painel. A empresa publica recursos como API, CLI, imagens personalizadas e cloud-init, mas detalhes completos de seu plano de controle e de seus hipervisores são infraestrutura proprietária. A explicação a seguir descreve como plataformas de VPS modernas normalmente funcionam, sem atribuir tecnologias não confirmadas a uma empresa específica.

Primeiro: o que é realmente uma VPS?

Uma VPS tradicional é uma máquina virtual executada dentro de um servidor físico maior.

Suponha um servidor com:

32 núcleos físicos;
256 GB de RAM;
8 TB de armazenamento NVMe;
conexão de 10 Gbit/s.

Esse equipamento pode hospedar dezenas de máquinas virtuais menores:

Servidor físico
├── VPS 101: 2 vCPU, 4 GB RAM, 60 GB
├── VPS 102: 4 vCPU, 8 GB RAM, 120 GB
├── VPS 103: 1 vCPU, 2 GB RAM, 30 GB
└── várias outras VPS

Cada VPS enxerga processadores, memória, disco, placa de rede e firmware virtuais. Dentro dela pode existir Debian, Ubuntu, Fedora, AlmaLinux, FreeBSD ou Windows, conforme a compatibilidade e as licenças.

VPS KVM não é um container Docker

Uma VPS KVM tem seu próprio kernel e se comporta como um computador independente. Um container Docker compartilha o kernel do host e normalmente empacota uma aplicação.

Característica	VPS KVM	Container LXC	Container Docker
Kernel próprio	Sim	Não	Não
Sistema operacional completo	Sim	Ambiente Linux completo	Geralmente uma aplicação
Isolamento	Forte, por virtualização	Menor que uma VM	Voltado a aplicações
Pode rodar outro kernel	Sim	Não	Não
Cliente recebe `root`	Sim	Pode receber, com ressalvas	Não é o modelo usual
Melhor uso	Alugar VPS	Hospedagem Linux controlada	Empacotar serviços

Para entregar VPS a pessoas diferentes, KVM é a escolha prudente. LXC pode ser oferecido como produto separado e mais barato, mas compartilha o kernel do host e exige políticas mais rígidas. Docker não substitui uma VPS de uso geral.

Dois significados diferentes de KVM

Há uma confusão frequente:

KVM, Kernel-based Virtual Machine: tecnologia de virtualização integrada ao Linux.
KVM over IP, Keyboard, Video and Mouse: console remoto para administrar um servidor físico como se houvesse monitor e teclado conectados.

O fato de um datacenter oferecer “console KVM” ou “KVM over IP” não prova que suas VPS utilizem o hipervisor KVM. São tecnologias diferentes.

O que roda no servidor físico?

O servidor físico, também chamado de nó de computação, host ou hypervisor node, normalmente roda Linux com componentes de virtualização.

Uma pilha comum é:

Hardware físico
└── Linux
    ├── KVM
    ├── QEMU
    ├── libvirt ou ferramentas do Proxmox
    ├── bridge de rede
    ├── armazenamento ZFS/LVM/Ceph
    └── máquinas virtuais

KVM

O KVM transforma o kernel Linux em um hipervisor. Com Intel VT-x ou AMD-V ativado no firmware, ele permite executar convidados com aceleração de hardware.

QEMU

O QEMU cria e emula o hardware virtual visto pela VPS: processador, controladores, discos, placa de rede, firmware e console. Em conjunto com KVM, a execução do código do convidado é acelerada pelo processador real.

libvirt

O libvirt fornece API, serviço e ferramentas para gerenciar máquinas virtuais, redes e armazenamento. Uma plataforma pode pedir ao libvirt para criar uma VM em vez de controlar diretamente cada processo QEMU. A documentação do projeto confirma suporte a QEMU/KVM, Xen, LXC, bhyve, Hyper-V e outros backends.

Proxmox VE

O Proxmox VE reúne em uma distribuição baseada em Debian:

KVM/QEMU para máquinas virtuais;
LXC para containers de sistema;
interface web;
linha de comando;
API REST;
usuários, permissões e pools;
redes, firewall e SDN;
armazenamento local e compartilhado;
snapshots, migração, replicação e cluster;
integração com Proxmox Backup Server.

Ele não é o hipervisor propriamente dito. É a plataforma administrativa que organiza KVM/QEMU, LXC, rede e armazenamento.

Para uma microprovedora, Proxmox é atraente porque elimina a necessidade de montar manualmente uma interface sobre libvirt. Sua API também permite acrescentar uma camada própria de automação posteriormente.

Outros sistemas usados nesse mercado

Plataforma	Base ou hipervisor	Perfil
Proxmox VE	Debian, KVM/QEMU e LXC	Laboratório, empresa e pequena nuvem privada
Debian/Ubuntu + libvirt	KVM/QEMU	Pilha manual e personalizável
SolusVM	Painel de VPS com KVM/OpenVZ	Provedores de hospedagem
Virtualizor	Painel com KVM e outros backends	Provedores e revendedores
VirtFusion	Gerenciamento de frota KVM	Provedores de VPS
OpenNebula	Nuvem privada com templates e scheduler	Pequena a grande infraestrutura
Apache CloudStack	Orquestrador IaaS com KVM e outros	Nuvem pública ou privada
OpenStack	Conjunto completo de serviços IaaS	Grandes ambientes e equipes especializadas
VMware vSphere	ESXi	Ambientes comerciais e corporativos
XCP-ng	Xen	Virtualização e nuvem privada

Então é Vagrant?

Não, pelo menos não como componente central da provedora.

O Vagrant foi projetado principalmente para criar ambientes de desenvolvimento e laboratórios reproduzíveis sobre providers como VirtualBox, Hyper-V, VMware ou outros. Ele pode automatizar a criação de VMs, mas não oferece por si só:

loja e pagamento;
painel multiusuário para clientes;
inventário global de CPU, RAM e armazenamento;
scheduler para escolher o melhor servidor;
gerenciamento de blocos IPv4 e IPv6;
quotas comerciais;
controle de tráfego;
suspensão por inadimplência;
console web por cliente;
reinstalação autônoma;
registro de abuso;
alta disponibilidade;
integração nativa com uma frota de hipervisores.

Vagrant é útil para testar a arquitetura:

Seu computador
└── Vagrant
    ├── VM de laboratório Proxmox ou libvirt
    ├── VM de painel
    └── VM de monitoramento

Entretanto, em produção, a peça equivalente ao “cérebro” é um painel para provedores ou uma plataforma IaaS. O Vagrant pode aparecer no desenvolvimento e nos testes, não na entrega comercial principal.

Como uma VPS fica pronta em minutos?

O segredo é que a empresa não executa um instalador completo de Debian ou Ubuntu para cada compra. Ela prepara antecipadamente imagens limpas e reutilizáveis.

O fluxo completo

flowchart TD
    A["Cliente escolhe o plano e o sistema"] --> B["Pagamento ou aprovação do pedido"]
    B --> C["Sistema de cobrança chama a API"]
    C --> D["Scheduler escolhe um host com capacidade"]
    D --> E["IPAM reserva IPv4 e IPv6"]
    E --> F["Disco é clonado de uma imagem pronta"]
    F --> G["CPU, RAM, rede e limites são definidos"]
    G --> H["Cloud-init recebe hostname e chave SSH"]
    H --> I["KVM inicia a máquina virtual"]
    I --> J["Verificação de boot e conectividade"]
    J --> K["Painel entrega IP e acesso ao cliente"]

1. Catálogo de planos

O painel mantém planos padronizados:

Plano	vCPU	RAM	Disco	Tráfego
Pequena	1	2 GB	30 GB	Limite definido
Padrão	2	4 GB	60 GB	Limite definido
Média	4	8 GB	120 GB	Limite definido

O cliente não pede uma configuração arbitrária. Ele escolhe uma combinação que o sistema já sabe criar.

2. Imagem-base

A provedora mantém uma imagem cloud de cada sistema:

Debian;
Ubuntu;
AlmaLinux;
Rocky Linux;
Fedora Cloud;
eventualmente Windows com Cloudbase-Init e Sysprep.

Essa imagem já contém:

estrutura de disco;
bootloader;
kernel;
drivers VirtIO;
cloud-init;
agente da máquina virtual, quando apropriado;
configurações mínimas de segurança.

É uma instalação genérica, ainda sem o usuário, hostname e endereço de uma VPS específica.

3. Scheduler

Quando existem vários hosts, o scheduler procura um que tenha:

RAM disponível;
CPU dentro da política de ocupação;
espaço no pool de armazenamento;
IP disponível;
localização solicitada;
recursos especiais do plano;
estado saudável e fora de manutenção.

O OpenStack chama essa função de nova-scheduler; seu serviço Placement acompanha inventário e consumo. OpenNebula e CloudStack possuem conceitos equivalentes. Em uma instalação com apenas um Proxmox, a escolha é trivial porque existe somente um host.

4. Clone do disco

Em vez de copiar ou instalar todo o sistema de maneira convencional, a plataforma cria um clone da imagem.

Existem duas modalidades principais:

clone completo: novo disco independente, com todos os blocos copiados;
clone ligado ou thin clone: inicialmente referencia uma base e grava somente os blocos alterados.

ZFS, LVM-thin, Ceph RBD e o formato QCOW2 oferecem mecanismos eficientes de snapshots, clones ou alocação fina. A documentação de armazenamento do Proxmox explica que o thin provisioning grava apenas os blocos realmente utilizados pelo convidado, embora a VPS enxergue um disco virtual maior.

Essa operação pode levar segundos, especialmente em NVMe e com clones eficientes.

5. Personalização com cloud-init

O cloud-init é o componente que transforma uma imagem genérica na VPS daquele cliente. Durante a primeira inicialização ele pode receber:

identificador único da instância;
hostname;
usuário inicial;
chave pública SSH;
configuração IPv4 e IPv6;
DNS;
expansão do sistema de arquivos;
comandos de inicialização;
pacotes ou configurações simples.

O Proxmox gera uma pequena unidade de dados do cloud-init e a anexa à VM. No primeiro boot, o convidado lê esses dados, configura-se e inicia o SSH.

Para segurança, é preferível entregar acesso por chave SSH. A documentação de hardening do cloud-init recomenda evitar senhas em texto puro dentro de user-data, pois esse material pode ser exposto dependendo da implementação de metadados.

6. Rede e IP

O sistema reserva um endereço no IPAM, associa o IP à interface virtual, aplica rotas, regras contra falsificação de origem e limites de tráfego. Dependendo do datacenter, a VPS recebe:

IP público diretamente em uma bridge;
IP roteado pelo host;
IP privado com NAT;
IPv6 público e IPv4 compartilhado.

7. Inicialização e entrega

O KVM inicia a VM. O painel espera o estado de execução, pode verificar o agente ou uma porta de rede e então entrega:

endereço IP;
usuário inicial;
fingerprint ou console;
botões de ligar, desligar, reiniciar e reinstalar;
métricas básicas.

Tempo ilustrativo

Os números abaixo são estimativas para mostrar o mecanismo, não garantias:

Operação	Ordem de grandeza possível
Registrar pedido e reservar recursos	1 a 10 segundos
Criar VM e disco a partir de template	5 a 90 segundos
Gerar configuração e rede	1 a 10 segundos
Boot e `cloud-init`	15 a 180 segundos
Verificação e comunicação ao cliente	5 a 30 segundos

Com imagem local, NVMe e automação saudável, uma VPS Linux pode ficar acessível em menos de dois minutos. Cópias completas, imagens remotas, atualizações no primeiro boot e armazenamento sobrecarregado aumentam esse tempo.

As camadas de uma empresa de VPS

Uma interface bonita de compra é apenas a camada superior. A infraestrutura real possui várias peças.

Camada	Responsabilidade	Exemplos
Site e cobrança	pedido, pagamento, fatura	WHMCS, Blesta, portal próprio
Painel do cliente	console, reboot, reinstalação	VirtFusion, SolusVM, Virtualizor
Plano de controle	inventário, API, scheduler	painel de VPS, Proxmox, OpenNebula
Computação	executar as VMs	KVM/QEMU
Inicialização	personalizar a imagem	cloud-init, Cloudbase-Init
Rede	IPs, bridge, rotas, firewall	Linux bridge, Open vSwitch, VLAN
Armazenamento	discos e snapshots	ZFS, LVM-thin, Ceph RBD
Backup	cópia recuperável e externa	Proxmox Backup Server
Observabilidade	alertas e capacidade	Prometheus, Grafana, Zabbix
Operação física	energia, refrigeração e link	datacenter ou provedor bare metal

O site não cria diretamente a VPS. Ele envia uma solicitação autenticada ao painel ou orquestrador, que conversa com os nós de computação.

Três arquiteturas possíveis

Arquitetura A: laboratório

Objetivo: aprender sem clientes e sem compromisso de disponibilidade.

Computador ou servidor de laboratório
└── Proxmox VE
    ├── Template Debian
    ├── Template Ubuntu
    ├── VPS de teste 1
    └── VPS de teste 2

Pode ser um equipamento local com IPs privados. O acesso externo pode acontecer por VPN. Vagrant também pode ajudar a criar laboratórios aninhados, desde que o hardware e o hipervisor permitam nested virtualization.

O laboratório deve provar:

criação por template;
injeção de chave SSH;
rede;
reinstalação;
snapshot;
backup;
restauração;
limitação de CPU, RAM e disco;
destruição completa da VM.

Arquitetura B: microprovedora para amigos

Objetivo: oferecer aproximadamente 5 a 20 VPS pequenas, sem prometer alta disponibilidade.

VPS administrativa pequena
├── portal ou painel de clientes
├── monitoramento
└── automação
        |
        | API por rede privada/VPN
        v
Servidor dedicado no datacenter
├── Proxmox VE
├── ZFS mirror ou LVM-thin redundante
├── bridge/routing para IPs públicos
├── templates cloud-init
└── VPS KVM dos clientes

Segundo destino independente
└── backups

Características recomendadas:

um servidor dedicado real, não uma VPS comum;
KVM para os clientes;
painel administrativo protegido por VPN ou lista de IPs;
duas unidades NVMe em espelho;
backup fora do host;
planos conservadores;
proibição inicial de envio de e-mail em massa;
criação manual ou semiautomática;
comunicação honesta de que manutenção do nó derruba todas as VPS.

Arquitetura C: pequena provedora com redundância

Objetivo: continuar operando apesar da manutenção ou falha de um nó.

Plano de controle separado
├── banco de dados
├── painel
├── billing
└── monitoramento

Cluster
├── nó KVM 1
├── nó KVM 2
└── nó KVM 3

Armazenamento
├── Ceph distribuído
└── ou armazenamento local com replicação planejada

Backup independente
└── segunda localização

Três nós são uma base mais saudável para quorum e manutenção do que dois. Isso não torna o ambiente automaticamente altamente disponível: rede, armazenamento, quorum, fencing, capacidade reserva e testes de recuperação precisam estar corretos.

Para poucos amigos, começar diretamente nessa arquitetura aumenta muito o custo e a quantidade de pontos de falha. O crescimento deve ser consequência de uso real.

Arquitetura recomendada para a primeira versão

Hipervisor

Proxmox VE em bare metal.

Razões:

instalação relativamente simples;
KVM e LXC já integrados;
API REST documentada;
templates e suporte a cloud-init;
firewall e redes;
snapshots e clones;
permissões;
integração direta com backup;
caminho de evolução para cluster.

O host deve executar apenas funções de virtualização. Não é recomendável instalar no próprio Proxmox:

sites de clientes;
Cloudron;
banco de dados do negócio;
aplicações pessoais;
downloaders;
serviços experimentais.

Quanto menos funções houver no host, menor será o risco de uma atualização ou aplicação afetar todas as VPS.

Tipo de virtualização

KVM/QEMU para todos os clientes.

Containers LXC podem ser usados internamente, mas não devem ser confundidos com o produto VPS KVM. A separação comercial e técnica evita expectativas erradas.

Armazenamento

Para um único nó:

dois NVMe empresariais em espelho ZFS; ou
dois SSD/NVMe redundantes com uma estratégia equivalente bem compreendida;
compressão adequada;
monitoramento de saúde, temperatura, desgaste e erros;
espaço reservado para snapshots temporários;
backup para outra máquina.

ZFS oferece verificação de integridade, snapshots, compressão e clones. A documentação do Proxmox recomenda RAM ECC de qualidade para ZFS e alerta para não colocar ZFS sobre uma controladora RAID que esconda os discos. Uma HBA em modo apropriado ou conexão direta é preferível.

Espelho não é backup. Ele permite sobreviver à falha de uma unidade, mas não protege contra exclusão, comprometimento do host, erro administrativo, corrupção propagada ou perda física.

Rede

O datacenter ou fornecedor do servidor dedicado deve permitir:

virtualização;
IPs adicionais ou um bloco roteado;
IPv6;
bridge ou roteamento compatível;
tráfego necessário;
rDNS, se for oferecido;
proteção DDoS upstream;
procedimento de abuso;
console fora de banda ou modo de recuperação.

Na Hetzner, por exemplo, IPs individuais podem usar MAC virtual em bridge, enquanto sub-redes adicionais são roteadas para o servidor. Esse detalhe demonstra por que não basta instalar Proxmox: a rede precisa seguir o modelo do datacenter.

Para iniciar, três modelos são possíveis:

IPv4 público por VPS: melhor experiência, maior custo.
IPv6 público + IPv4 público por VPS nos planos maiores: compromisso razoável.
IPv6 público + IPv4 compartilhado por NAT: mais barato, mas prejudica portas, jogos, VPN, hospedagem e autonomia.

A escassez de IPv4 é estrutural. O RIPE NCC esgotou seu pool disponível em 2019 e distribui endereços recuperados por lista de espera. Portanto, o preço e a disponibilidade de IPv4 precisam entrar no projeto desde o começo.

Backup

O destino de backup deve ser independente do nó de produção:

outra máquina;
outro provedor;
outra conta administrativa;
preferencialmente outra localização;
credenciais com permissões mínimas.

O Proxmox Backup Server oferece backups incrementais, deduplicação, verificação por checksum, criptografia no cliente e sincronização remota. Mesmo com automação, restaurações precisam ser testadas.

Um esquema inicial sensato:

backup diário das VPS;
retenção diária, semanal e mensal compatível com o espaço;
verificação automática;
teste mensal de restauração de uma VPS descartável;
cópia do inventário, configurações e chaves necessárias;
documentação para reconstruir o host.

Painel

Há duas fases possíveis.

Fase inicial: Proxmox e operação manual

Você recebe o pagamento ou combina o valor, cria a VM, injeta a chave SSH e entrega o IP. Para poucos amigos, esse fluxo é suficiente e reduz o risco de uma automação destruir ou entregar a VM errada.

Não é necessário dar acesso administrativo completo ao Proxmox. Você pode operar os primeiros clientes manualmente e disponibilizar console somente quando necessário.

Fase de autosserviço: painel voltado a provedores

Opção	Pontos fortes	Limitações
VirtFusion	Painel moderno para frota KVM e portal do cliente	Comercial; precisa avaliar integrações e modelo de implantação
SolusVM	KVM, painel, API e integração com billing	Comercial e adiciona plano de controle próprio
Virtualizor	KVM, templates, API, WHMCS/Blesta e várias ações do cliente	Comercial; instalação e exposição de portas exigem hardening cuidadoso
Proxmox + integração própria	Controle total e reutiliza a API	Você passa a manter software crítico
OpenNebula	Templates, scheduler, redes e autosserviço	Mais complexo que Proxmox para um nó
Apache CloudStack	IaaS completo, API, IPs, storage e templates	Excesso de componentes para poucos clientes
OpenStack	Arquitetura de nuvem extremamente completa	Operação complexa, vários serviços e equipe especializada

O VirtFusion se apresenta especificamente como plataforma de gerenciamento de VMs KVM para provedores. O SolusVM separa um Management Node dos Compute Resources e oferece API e integração de billing. O Virtualizor integra-se ao WHMCS para criar, suspender e apagar VPS automaticamente.

Para uma microprovedora, vale testar VirtFusion e SolusVM antes de escrever um portal próprio. Criar um sistema que controla exclusão de discos, senhas, IPs e pagamentos é muito mais arriscado do que criar um site comum.

Como seria a automação de compra?

Um fluxo seguro possui estados explícitos:

pedido_novo
    ↓
pagamento_confirmado
    ↓
recursos_reservados
    ↓
provisionando
    ↓
inicializando
    ↓
validando
    ↓
ativo

Em caso de erro:

provisionando
    ↓
falha
    ├── liberar IP
    ├── remover disco incompleto
    ├── registrar log
    └── avisar operador

Operações que precisam ser idempotentes

Se o sistema receber o mesmo evento de pagamento duas vezes, não pode criar duas VPS. Cada pedido precisa ter:

identificador único;
trava ou chave de idempotência;
registro da VM correspondente;
confirmação de cada etapa;
mecanismo de rollback;
auditoria.

Exemplo conceitual da chamada

{
  "order_id": "pedido-2026-0012",
  "plan": "vps-padrao",
  "image": "debian-13",
  "hostname": "srv-amigo-01",
  "ssh_public_key": "ssh-ed25519 AAAA...",
  "region": "dc-01"
}

O backend valida o pedido, escolhe um nó, reserva o IP e chama a API do painel. Segredos administrativos nunca devem ficar no navegador do cliente.

Preparação das imagens

Imagens são parte da segurança da provedora. Uma imagem mal preparada replica o mesmo problema em todas as VPS.

Regras essenciais

baixar imagens somente de fontes oficiais;
verificar checksum e assinatura quando disponíveis;
manter versões suportadas;
incluir cloud-init;
utilizar drivers VirtIO;
não manter senha padrão;
não incorporar chave SSH privada;
garantir regeneração de chaves de host;
limpar identificadores que devam ser únicos;
atualizar a imagem regularmente;
testar rede e expansão do disco;
registrar a versão e o hash de cada imagem;
retirar imagens que chegaram ao fim de suporte.

Linux

Debian, Ubuntu, Fedora e distribuições empresariais disponibilizam imagens cloud adequadas. O primeiro acesso deve favorecer chave SSH, não senha enviada por e-mail.

Windows

Windows requer:

licenciamento compatível com hospedagem;
imagem preparada com Sysprep;
Cloudbase-Init ou mecanismo equivalente;
drivers VirtIO;
senha única;
atualização;
regras próprias de ativação.

Não ofereça Windows antes de entender licenciamento e automatizar corretamente a personalização. Copiar a mesma instalação ativada para vários clientes pode criar problemas técnicos e jurídicos.

Hardware: o que comprar ou alugar?

Para começar, alugar um servidor dedicado em um datacenter é mais sensato do que colocar uma máquina em casa. O datacenter oferece energia, refrigeração, conexão, IPs, mitigação DDoS e acesso remoto.

Requisitos mínimos práticos para uma microprovedora

Um perfil equilibrado para aproximadamente 10 a 20 VPS leves:

Componente	Recomendação inicial
CPU	AMD EPYC, Ryzen servidor ou Intel Xeon com AMD-V/VT-x
RAM	128 GB ECC
Armazenamento	2 × 1,92 TB NVMe empresarial em espelho
Rede	1 Gbit/s com franquia adequada
Gerenciamento	IPMI/BMC ou console de recuperação
IPs	Bloco ou IPs adicionais e IPv6
Backup	Destino separado com capacidade suficiente

Isso é uma referência, não um requisito absoluto. Um servidor com 64 GB pode atender poucos amigos. Entretanto, a diferença entre “funcionar” e “ser operável” está nas reservas, redundância e recuperação.

Por que ECC?

Todas as VMs compartilham a memória física. Uma falha silenciosa pode afetar dados do host ou de vários clientes. ECC reduz esse risco. Proxmox recomenda hardware de boa qualidade em produção e RAM ECC especialmente com ZFS.

Por que NVMe empresarial?

Várias VPS fazem pequenas leituras e gravações ao mesmo tempo. Esse padrão exige:

IOPS;
baixa latência;
endurance;
proteção contra perda de energia;
comportamento previsível sob carga sustentada.

Um SSD doméstico pode parecer rápido em benchmark curto e degradar quando o cache termina ou quando muitas VMs escrevem simultaneamente.

RAID ou ZFS mirror?

Para uma primeira instalação Proxmox, um mirror ZFS simples é compreensível e oferece bons recursos. Evite combinações que escondam os discos do ZFS atrás de uma controladora RAID com cache próprio.

Também é possível utilizar LVM-thin sobre uma camada de armazenamento redundante. O importante é compreender:

como uma unidade falha;
como substituir;
como monitorar;
como recuperar;
o que acontece durante uma queda de energia.

Capacidade real

Um servidor de 128 GB não possui 128 GB vendáveis. É necessário reservar memória para:

host;
cache de armazenamento;
processos de virtualização;
picos;
operações de backup;
margem de emergência.

Uma política inicial conservadora poderia vender entre 80 e 100 GB de RAM total, dependendo de ZFS, carga e medições. Não há um número universal.

Exemplo:

128 GB físicos
- 16 GB reservados para host e serviços
- 16 GB de margem operacional
= 96 GB de orçamento inicial para convidados

Isso permitiria, por exemplo:

16 VPS de 4 GB = 64 GB;
8 VPS de 4 GB + 8 VPS de 2 GB = 48 GB;
combinação de planos respeitando 96 GB.

Overselling

Overselling é vender mais recursos virtuais do que os recursos físicos existentes, esperando que os clientes não usem tudo ao mesmo tempo.

CPU

É normal atribuir mais vCPU do que núcleos físicos, pois muitas VMs ficam ociosas. Para começar, uma proporção baixa, acompanhada por métricas, é mais segura. Cargas de compilação, jogos, bancos e transcodificação podem saturar rapidamente o host.

RAM

Não venda RAM contando com swap ou ballooning para sustentar uso constante. Para um operador iniciante, tratar RAM como recurso não supervendido evita uma classe inteira de falhas.

Disco

Thin provisioning economiza espaço, mas pode derrubar todo o pool se o uso real alcançar o limite. É obrigatório:

alertar com antecedência;
reservar espaço para metadados e snapshots;
limitar crescimento;
não vender a soma nominal como se todo espaço fosse livre;
acompanhar escrita e IOPS, não apenas gigabytes.

Rede

Uma porta de 1 Gbit/s pode servir muitas VPS ociosas, mas poucos clientes fazendo backup ou torrent podem ocupá-la. Defina limites por plano e verifique a política de tráfego do datacenter.

Rede: a parte mais subestimada

O processador cria a VM; a rede faz com que ela seja utilizável e impede que um cliente se passe por outro.

Bridge

Uma Linux bridge funciona como um switch virtual. As interfaces tap das VMs conectam-se à bridge e chegam à rede física.

VPS A -- tap101 --+
VPS B -- tap102 --+-- vmbr0 -- placa física -- datacenter
VPS C -- tap103 --+

Roteamento

Em vez de expor todas as MACs das VMs ao switch do datacenter, o fornecedor roteia um bloco para o IP principal do host. O host encaminha cada endereço à VPS correta.

Roteamento costuma ser mais controlável e funciona bem com sub-redes entregues ao servidor.

NAT

As VPS usam endereços privados e compartilham o IPv4 do host. É barato, mas exige encaminhamento de portas e impede a mesma porta pública para várias VPS. Pode servir a laboratórios, não é a experiência clássica de uma VPS.

Controles obrigatórios

impedir spoofing de IP e MAC;
filtrar tráfego com origem que não pertence à VM;
separar rede de gerenciamento;
não deixar a interface do Proxmox aberta ao mundo;
utilizar VPN ou allowlist para administração;
ativar firewall por host e por VM;
limitar portas perigosas quando necessário;
registrar atribuição histórica de IP;
manter rDNS e DNS coerentes;
monitorar tráfego anormal;
possuir procedimento de bloqueio emergencial.

IPAM

Para cinco VPS, uma tabela controlada pode bastar. Quando houver mais endereços, use um IPAM ou o módulo do painel para registrar:

IP;
prefixo;
gateway;
MAC;
VM;
cliente;
data de atribuição;
rDNS;
estado livre, reservado, ativo ou quarentena.

Nunca reutilize imediatamente um IP liberado sem limpar rDNS, regras e associações antigas.

Segurança e isolamento

Ao entregar root, você aceita que o cliente possa executar qualquer software permitido pelas regras. A infraestrutura precisa assumir que uma VPS pode ser comprometida.

Host

interface administrativa somente por VPN ou rede restrita;
autenticação multifator;
contas individuais;
atualizações planejadas;
API tokens com privilégio mínimo;
SSH por chave;
sem aplicações comuns no host;
logs enviados para destino externo;
monitoramento de integridade e capacidade;
backup das configurações;
inventário de firmware e hardware;
console fora de banda protegido.

Separação entre clientes

preferir KVM;
evitar passthrough desnecessário;
não compartilhar diretórios do host;
limitar CPU, RAM, disco e rede;
usar regras anti-spoofing;
manter QEMU, kernel e microcódigo atualizados;
não fornecer acesso ao painel administrativo;
testar permissões do portal do cliente;
assegurar que uma pessoa não veja console, backup ou métricas de outra.

Credenciais

chave SSH pública como padrão;
senha aleatória somente quando inevitável;
nunca reutilizar senha de template;
nunca enviar chave privada;
segredos de API em cofre ou arquivo com acesso mínimo;
rotação de tokens;
webhooks assinados;
logs sem senhas e tokens completos.

Abuso

Mesmo entre amigos, uma VPS comprometida pode:

enviar spam;
participar de DDoS;
escanear outras redes;
hospedar phishing;
minerar criptomoeda;
consumir toda a banda;
gerar reclamação ao datacenter.

Defina antes do primeiro cliente:

usos proibidos;
contato de abuso;
prazo para resposta;
possibilidade de suspensão;
limites de tráfego e CPU;
política para e-mail;
procedimento para preservar evidências técnicas;
forma de reinstalar ou isolar a VM.

Para a primeira versão, bloquear saída SMTP na porta 25 e liberar apenas mediante análise reduz muito o risco de spam. Isso deve ser comunicado claramente.

Disponibilidade: o problema do primeiro servidor

Com um único nó, todas as VPS param quando:

o host reinicia;
o kernel é atualizado;
a placa-mãe falha;
a rede do servidor cai;
o pool de armazenamento apresenta problema;
o datacenter realiza manutenção.

RAID não resolve falha de placa-mãe, erro humano ou perda do datacenter. Backup não oferece failover instantâneo. Cluster não garante HA sem armazenamento, quorum e capacidade correta.

Por isso, a oferta inicial deve dizer algo como:

Serviço experimental e privado, sem alta disponibilidade. Manutenções e falhas do nó podem interromper todas as VPS. Existem backups, mas a restauração não é instantânea.

Essa honestidade é melhor do que fingir uma infraestrutura empresarial.

Monitoramento indispensável

O painel mostrar “VM ligada” não significa que o serviço está saudável.

Host

carga e steal time;
uso e pressão de memória;
swap;
latência e fila de disco;
IOPS e throughput;
espaço e metadados do pool;
saúde e desgaste SMART/NVMe;
erros ZFS;
temperatura;
perda de pacotes;
saturação da interface;
tarefas de backup;
status de atualizações;
certificados.

VPS e plano

consumo de CPU;
memória atribuída;
leitura e escrita;
tráfego;
estado;
reinicializações;
uso anormal;
limites aplicados.

Fora da infraestrutura

Um monitor externo deve verificar:

painel;
API;
conectividade dos IPs;
DNS;
latência;
disponibilidade do datacenter.

Se o monitor estiver dentro do mesmo host que caiu, ele também desaparece e não envia o alerta.

Backups, snapshots e restauração

Snapshot não é backup

Snapshot é um ponto no tempo ligado ao mesmo armazenamento. É útil antes de uma atualização ou para rollback curto. Se o pool for perdido, os snapshots normalmente são perdidos junto.

Backup de verdade

Um backup deve:

existir fora do host;
ter retenção;
ser verificado;
possuir controles de acesso separados;
ser restaurável;
sobreviver à exclusão no ambiente principal.

Responsabilidade

Defina se:

você inclui backup da VPS inteira;
o cliente precisa fazer backup da aplicação;
há custo por restauração;
snapshots são temporários;
dados podem ser apagados após cancelamento;
existe período de retenção.

Mesmo que você ofereça backup da VM, o cliente deve manter cópia dos dados importantes. Um backup de hipervisor pode ser inconsistente para bancos de dados se o convidado não cooperar ou se a aplicação não fizer flush corretamente.

Painéis e plataformas em mais detalhe

Proxmox VE

Melhor ponto de partida técnico. Ele oferece API e ferramentas, mas não é uma loja de VPS completa. Você terá de:

criar manualmente;
integrar um painel;
ou desenvolver uma camada cuidadosa sobre a API.

VirtFusion

É direcionado a provedores KVM e inclui visão da frota e portal para clientes. Merece um teste quando o objetivo passar de “eu crio as VMs para meus amigos” para “meus amigos controlam e reinstalam suas VMs”.

SolusVM

Usa um Management Node e um ou mais Compute Resources. O nó de gestão concentra API e orquestração; os nós de computação executam as VPS. A documentação oficial confirma suporte a KVM e integrações de cobrança. É conceitualmente muito próximo da arquitetura de uma pequena provedora.

Virtualizor

Oferece templates, painel de usuário, API e integração com WHMCS. O módulo oficial pode criar, suspender e remover uma VPS após a aceitação do pedido. Suporta KVM e vários modelos de armazenamento.

Sua documentação de instalação merece revisão crítica de segurança: recomendações como desabilitar SELinux não devem ser copiadas cegamente. Qualquer painel com acesso ao hipervisor é um componente altamente privilegiado.

OpenNebula

Permite registrar templates, redes e datastores, e depois instanciar VMs. Seu scheduler seleciona hosts e recursos. É interessante para aprender como uma nuvem privada funciona e pode crescer além de um painel simples.

Apache CloudStack

Seu Management Server atribui VMs a hosts, IPs e armazenamento e oferece API e interfaces. A documentação mostra que uma instalação mínima pode ter um Management Server e um host KVM, embora uma implantação séria separe funções.

OpenStack

É a arquitetura mais completa desta lista:

Nova cria e gerencia instâncias;
Placement acompanha inventário;
Glance mantém imagens;
Neutron fornece redes;
Keystone faz identidade;
Cinder fornece volumes;
Horizon oferece interface.

Essa separação explica muito bem como uma grande nuvem funciona, mas também mostra por que OpenStack é excessivo para dez amigos. Há vários serviços, banco, fila de mensagens, APIs e procedimentos de atualização.

Contabo: o que pode ser inferido com segurança

Ao comprar uma VPS na Contabo, o fluxo percebido é:

pedido;
pagamento;
escolha de plano, região e imagem;
provisionamento automático;
entrega no painel.

A Contabo publica API e CLI, suporte a imagens personalizadas e cloud-init. Isso demonstra uma camada programável de controle. Entretanto, não é correto concluir a tecnologia exata de seus hosts apenas pelo comportamento do painel.

Também é importante notar que a empresa informa que VPS comuns não oferecem nested virtualization, enquanto determinados VDS e servidores dedicados podem oferecê-la. Portanto, tentar montar sua provedora dentro de uma VPS Contabo comum não é o caminho adequado. Para executar KVM de maneira correta, contrate bare metal ou um produto que exponha explicitamente virtualização aninhada e recursos suficientes.

O MVP recomendado

Escopo

somente amigos conhecidos;
5 a 10 VPS inicialmente;
apenas Linux;
KVM;
um ou dois tamanhos de plano;
sem envio SMTP irrestrito;
sem Windows;
sem alta disponibilidade;
pagamento combinado ou manual;
provisionamento manual pelo Proxmox;
backup diário externo.

Equipamentos e serviços

Servidor dedicado
- 64 ou 128 GB de RAM ECC;
- dois NVMe em espelho;
- CPU com virtualização;
- porta de 1 Gbit/s;
- IPs adicionais;
- proteção DDoS;
- console de recuperação.
Proxmox VE
- administração por Tailscale, WireGuard ou allowlist;
- MFA;
- KVM;
- templates.
Destino de backup
- fora do nó;
- credenciais separadas;
- capacidade para retenção.
Monitoramento externo
- alertas para indisponibilidade;
- métricas do host;
- alertas de disco e pool.

Planos iniciais sugeridos

Plano	vCPU	RAM	Disco	Perfil
Laboratório	1	2 GB	30 GB	VPN, bot, site pequeno
Padrão	2	4 GB	60 GB	Docker, sites e serviços leves
Avançado, limitado	4	8 GB	120 GB	Aplicações mais pesadas

Evite prometer “CPU dedicada” se os núcleos não estiverem realmente dedicados. Use termos precisos como vCPU compartilhada.

Sistemas oferecidos

Debian stable;
Ubuntu LTS;
AlmaLinux ou Rocky Linux;
Fedora Cloud somente para quem compreende o ciclo mais rápido.

Menos imagens significam menos trabalho para atualização e testes.

Roteiro de implantação

Etapa 1: laboratório local

Instalar Proxmox em hardware de teste.
Criar uma bridge privada.
Importar uma imagem cloud oficial.
Transformá-la em template.
Clonar dez vezes.
Injetar chaves SSH diferentes.
Testar destruição e recriação.
Simular disco cheio.
Fazer backup.
Restaurar em outro identificador.

Critério de saída: ser capaz de perder uma VM e restaurá-la sem improvisação.

Etapa 2: servidor dedicado

Confirmar política de virtualização do fornecedor.
Confirmar IPs, MACs, bridge ou roteamento.
Instalar Proxmox VE.
Atualizar e restringir administração.
Configurar armazenamento redundante.
Configurar rede e firewall.
Conectar backup externo.
Criar templates oficiais.
Implantar monitoramento.
Criar VPS descartáveis e executar testes de carga.

Critério de saída: o nó deve passar pelo menos uma reinicialização completa e uma restauração testada.

Etapa 3: primeiros amigos

Começar com uma ou duas pessoas.
Definir limites claros.
Entregar chave SSH e documentação.
Monitorar uma semana.
Ajustar CPU, I/O, backup e alertas.
Somente então adicionar mais clientes.

Etapa 4: painel de cliente

Testar VirtFusion, SolusVM e Virtualizor isoladamente.
Verificar permissões e API.
Testar reboot, reinstall, console e rescue.
Confirmar que um cliente não acessa recursos de outro.
Testar falha do painel sem afetar VMs em execução.
Integrar cobrança somente após os testes.

Etapa 5: segundo nó

Um segundo nó permite manutenção e migração, mas não cria HA sozinho. Antes de expandir:

padronize CPUs;
planeje rede de cluster;
defina armazenamento;
preserve quorum;
deixe capacidade para absorver falha;
teste migração;
mantenha backup independente.

Testes obrigatórios antes de cobrar

Provisionamento

criar uma VPS de cada imagem;
confirmar hostname;
confirmar IP e gateway;
confirmar expansão do disco;
confirmar chave SSH;
confirmar que não há senha padrão;
medir o tempo de entrega;
executar duas criações simultâneas.

Isolamento

tentar acessar console de outra conta;
tentar utilizar IP de outra VPS;
tentar alterar MAC;
saturar CPU dentro do limite;
saturar disco dentro do limite;
verificar que uma VM não enxerga armazenamento alheio.

Falhas

reiniciar o host;
desligar uma VPS de modo abrupto;
simular falha de tarefa de clone;
esgotar um pool de IPs em laboratório;
interromper conexão com backup;
restaurar uma VPS;
revogar um token de API;
verificar comportamento quando o pagamento chega duas vezes.

Operação

aplicar atualização do host;
colocar nó em manutenção;
localizar logs de uma tarefa;
suspender e reativar uma VPS;
reinstalar sem reutilizar credenciais;
apagar a VPS e liberar corretamente o IP;
recuperar inventário depois de falha do painel.

Erros que quebram pequenas provedoras

Usar uma VPS comum como hipervisor. Sem nested virtualization e IPs apropriados, a base já nasce errada.
Expor o Proxmox diretamente à internet. O painel controla todas as máquinas e deve ficar restrito.
Misturar aplicações pessoais no host. Um container experimental pode comprometer manutenção e segurança.
Achar que RAID é backup. Redundância local não recupera exclusão nem comprometimento.
Vender toda a RAM e todo o disco. O host precisa de margem e thin pools podem encher.
Ignorar IPv4. Endereços são caros, escassos e dependem da política do datacenter.
Usar SSD doméstico sem medir endurance. Muitas VPS produzem carga concorrente e sustentada.
Criar um portal próprio cedo demais. Uma falha de autorização pode expor console ou apagar discos.
Oferecer e-mail sem política. Uma conta comprometida pode bloquear a faixa de IP inteira.
Não testar restauração. Um arquivo de backup existente não prova que a recuperação funciona.
Prometer alta disponibilidade com um nó. Não existe redundância quando toda a oferta depende de uma máquina.
Clonar imagens com segredos. Chaves, tokens, machine-id e senhas repetidas transformam um erro em dezenas.
Não reservar capacidade para manutenção. Um cluster incapaz de receber as VMs do nó parado não oferece failover real.
Misturar painel de gestão e tráfego de clientes. A rede administrativa precisa ser separada e restrita.

Custos que existem mesmo entre amigos

Sem entrar em um plano comercial completo, a infraestrutura tem:

aluguel ou compra do servidor;
IPv4 adicional;
tráfego excedente;
backup externo;
licenças do painel;
licença do billing;
domínio e e-mail;
monitoramento;
reposição de hardware, quando próprio;
tempo de suporte;
taxas de pagamento;
impostos e obrigações aplicáveis;
perdas causadas por abuso ou DDoS.

O preço não deve ser calculado dividindo apenas o aluguel do servidor pelo número máximo de VPS. É necessário deixar capacidade ociosa e financiar backup, endereços e falhas.

Recomendação prática

Para sua ideia específica, eu faria assim:

Primeira versão

Servidor dedicado em datacenter
├── Proxmox VE
├── KVM/QEMU
├── ZFS mirror com NVMe empresarial
├── Debian e Ubuntu em templates cloud-init
└── 5 a 10 VPS

Servidor externo de backup
└── Proxmox Backup Server

Administração
├── Tailscale ou WireGuard
├── MFA
└── monitor externo

Provisionamento manual pelo Proxmox durante os primeiros meses. Você recebe o pedido, cria a VPS a partir do template, injeta a chave SSH e entrega o endereço. Isso já leva poucos minutos e permite aprender a operação real sem introduzir billing e automação privilegiada.

Segunda versão

Depois de aproximadamente 30 criações, reinstalações e restaurações bem-sucedidas:

testar VirtFusion ou SolusVM;
permitir ao cliente reboot, console e reinstalação;
manter a API em rede administrativa;
integrar pagamento com idempotência;
automatizar somente planos padronizados.

Terceira versão

Quando o primeiro nó tiver clientes suficientes para justificar:

adicionar segundo e depois terceiro nó;
separar plano de controle;
avaliar armazenamento distribuído ou replicação;
criar capacidade de manutenção;
considerar OpenNebula ou CloudStack se o painel de hosting ficar pequeno;
evitar OpenStack até existir necessidade e equipe para seus vários serviços.

A ideia em uma frase

Você não está construindo “um site que vende servidores”. Está construindo uma pequena nuvem:

hardware + hipervisor + imagens + rede + armazenamento
+ API + painel + backup + monitoramento + operação
= serviço de VPS

O componente que gera a agilidade não é o Vagrant isoladamente. É a combinação de templates, clones, cloud-init e uma API de orquestração. Vagrant ensina o princípio e ajuda no laboratório; Proxmox, KVM e um painel de provedores formam a base operacional.

Conclusão

Uma pequena empresa de VPS para amigos é tecnicamente viável e constitui um excelente projeto para aprender virtualização, redes e operação. O caminho mais simples e sólido é alugar um servidor dedicado em um datacenter, instalar Proxmox VE, oferecer máquinas KVM construídas a partir de imagens cloud oficiais e guardar backups em outro servidor.

A VPS aparece em minutos porque seu sistema operacional já está instalado em uma imagem-base. A plataforma clona essa imagem, atribui recursos e rede, injeta a configuração com cloud-init e inicia a VM. Não há um técnico instalando Debian e normalmente não há um Vagrantfile no centro da operação.

Para poucos amigos, a melhor automação inicial é pouca automação: templates bem testados e criação manual pelo Proxmox. Quando o processo estiver previsível, um painel como VirtFusion, SolusVM ou Virtualizor pode adicionar autosserviço e integração de cobrança. OpenNebula e CloudStack são passos posteriores; OpenStack é aprendizado valioso, mas exagerado para o primeiro nó.

O risco principal não está em criar a VM. Está em administrar IPs, evitar abuso, não supervender recursos, proteger o hipervisor e conseguir restaurar os dados depois de uma falha. Se essas cinco áreas forem tratadas com disciplina, a ideia deixa de ser apenas curiosa e se torna um pequeno serviço que pode crescer.

Fontes consultadas

Nota sobre atualidade

Pesquisa concluída em 25 de julho de 2026. Versões de plataformas, licenças, preços, sistemas suportados e políticas de endereços IP mudam com frequência. Confirme esses pontos na documentação oficial e no fornecedor do datacenter antes de contratar hardware ou oferecer o serviço.