Moon Flower Society > Como funciona e como montar uma pequena provedora de VPS para amigos
Uma arquitetura prática para transformar servidores físicos em pequenas VPS KVM, com provisionamento rápido, rede, armazenamento, painéis, backups e um caminho seguro para começar.
Posted July 25, 2026. Markdown. Tags: pesquisa, vps, virtualizacao, kvm, proxmox, infraestrutura, cloud-init.
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.
A resposta curta é:
cloud-init termina a personalização dentro do sistema convidado durante a primeira inicialização;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.
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:
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.
Uma VPS tradicional é uma máquina virtual executada dentro de um servidor físico maior.
Suponha um servidor com:
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.
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.
Há uma confusão frequente:
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 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
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.
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.
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.
O Proxmox VE reúne em uma distribuição baseada em Debian:
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.
| 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 |
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ó:
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.
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.
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"]
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.
A provedora mantém uma imagem cloud de cada sistema:
Essa imagem já contém:
cloud-init;É uma instalação genérica, ainda sem o usuário, hostname e endereço de uma VPS específica.
Quando existem vários hosts, o scheduler procura um que tenha:
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.
Em vez de copiar ou instalar todo o sistema de maneira convencional, a plataforma cria um clone da imagem.
Existem duas modalidades principais:
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.
O cloud-init é o componente que transforma uma imagem genérica na VPS daquele cliente. Durante a primeira inicialização ele pode receber:
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.
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:
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:
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.
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.
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:
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:
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.
Proxmox VE em bare metal.
Razões:
cloud-init;O host deve executar apenas funções de virtualização. Não é recomendável instalar no próprio Proxmox:
Quanto menos funções houver no host, menor será o risco de uma atualização ou aplicação afetar todas as VPS.
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.
Para um único nó:
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.
O datacenter ou fornecedor do servidor dedicado deve permitir:
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:
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.
O destino de backup deve ser independente do nó de produção:
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:
Há duas fases possíveis.
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.
| 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.
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
Se o sistema receber o mesmo evento de pagamento duas vezes, não pode criar duas VPS. Cada pedido precisa ter:
{
"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.
Imagens são parte da segurança da provedora. Uma imagem mal preparada replica o mesmo problema em todas as VPS.
cloud-init;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 requer:
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.
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.
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.
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.
Várias VPS fazem pequenas leituras e gravações ao mesmo tempo. Esse padrão exige:
Um SSD doméstico pode parecer rápido em benchmark curto e degradar quando o cache termina ou quando muitas VMs escrevem simultaneamente.
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:
Um servidor de 128 GB não possui 128 GB vendáveis. É necessário reservar memória para:
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:
Overselling é vender mais recursos virtuais do que os recursos físicos existentes, esperando que os clientes não usem tudo ao mesmo tempo.
É 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.
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.
Thin provisioning economiza espaço, mas pode derrubar todo o pool se o uso real alcançar o limite. É obrigatório:
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.
O processador cria a VM; a rede faz com que ela seja utilizável e impede que um cliente se passe por outro.
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 --+
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.
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.
Para cinco VPS, uma tabela controlada pode bastar. Quando houver mais endereços, use um IPAM ou o módulo do painel para registrar:
Nunca reutilize imediatamente um IP liberado sem limpar rDNS, regras e associações antigas.
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.
Mesmo entre amigos, uma VPS comprometida pode:
Defina antes do primeiro cliente:
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.
Com um único nó, todas as VPS param quando:
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.
O painel mostrar “VM ligada” não significa que o serviço está saudável.
Um monitor externo deve verificar:
Se o monitor estiver dentro do mesmo host que caiu, ele também desaparece e não envia o alerta.
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.
Um backup deve:
Defina se:
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.
Melhor ponto de partida técnico. Ele oferece API e ferramentas, mas não é uma loja de VPS completa. Você terá de:
É 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”.
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.
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.
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.
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.
É a arquitetura mais completa desta lista:
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.
Ao comprar uma VPS na Contabo, o fluxo percebido é:
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.
Servidor dedicado
Proxmox VE
Destino de backup
Monitoramento externo
| 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.
Menos imagens significam menos trabalho para atualização e testes.
Critério de saída: ser capaz de perder uma VM e restaurá-la sem improvisação.
Critério de saída: o nó deve passar pelo menos uma reinicialização completa e uma restauração testada.
Um segundo nó permite manutenção e migração, mas não cria HA sozinho. Antes de expandir:
machine-id e senhas repetidas transformam um erro em dezenas.Sem entrar em um plano comercial completo, a infraestrutura tem:
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.
Para sua ideia específica, eu faria assim:
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.
Depois de aproximadamente 30 criações, reinstalações e restaurações bem-sucedidas:
Quando o primeiro nó tiver clientes suficientes para justificar:
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.
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.
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.
View the original Markdown file
Ideas | What changed | RSS | About | Text version
Pablo Murad <pablomurad@pm.me>