Software essencial para VPS: o que instalar para cada caso de uso

Um VPS novo é a mesma caixa vazia, seja ele comprado para hospedar um site ou para rodar um bot de trading. O mesmo ponto de partida limpo, o mesmo disco quase vazio, quase nada além do sistema operacional. O que entra nele diverge na primeira instalação e continua divergindo: uma stack web e uma stack de trading quase não compartilham software, e uma delas nem sequer roda o mesmo sistema operacional.

Então não existe uma lista única de software essencial para VPS. Existe uma camada base curta de que todo servidor precisa, seja qual for o motivo da compra, e depois disso o caso de uso decide tudo. Duas das decisões anteriores a esta também mudam o formato dessa camada base. Hospedagem compartilhada ou VPS define se você tem acesso root ou não. Gerenciado ou não gerenciado define por quantos dos cinco itens abaixo você mesmo é responsável.

LER

KVM vs. OpenVZ vs. LXC: o que o tipo de virtualização do seu VPS realmente permite fazer

TL;DR

• Não existe resposta universal. Além de uma camada base curta, o caso de uso escolhe os programas e, às vezes, o sistema operacional.
• Todo VPS precisa primeiro das mesmas cinco categorias: acesso administrativo seguro, um firewall que esteja ligado, uma política de atualizações, backups que você já restaurou pelo menos uma vez e algo que avise que a máquina está viva. No Linux, acesso administrativo seguro geralmente significa SSH com chaves; no Windows, significa proteger o RDP ou outro caminho administrativo.
• Três coisas que um VPS Linux de 1 ou 2 GB não deveria adicionar por padrão: um painel de controle, um antivírus e a filtragem de spam e vírus incluída em uma stack de e-mail. Os requisitos de memória documentados delas podem consumir a maior parte ou a totalidade de uma máquina pequena antes de a sua carga de trabalho real começar.
• A seguir vêm dez casos de uso de VPS, cada um com os programas que fazem o trabalho e a restrição que decide se ele cabe na máquina que você comprou.
• Cada seção aqui é o mapa. Os guias com link trazem a profundidade.

O que todo VPS precisa, seja qual for o motivo da compra

A primeira coisa a instalar em um VPS novo não tem nada a ver com o motivo da compra. Cinco itens vêm primeiro, os mesmos cinco, quer a máquina acabe rodando uma loja virtual ou um servidor de jogos.

No Linux, comece pelo SSH com chaves. Gere um par de chaves, coloque a chave pública no servidor, confirme em uma segunda sessão que o login por chave funciona e depois desative a autenticação por senha, porque uma porta com autenticação por senha em um IP público é um ímã de tentativas de login.

Depois o firewall, e confirme que ele está rodando em vez de presumir. O Ubuntu traz o UFW como ferramenta de firewall padrão, e a documentação da comunidade Ubuntu afirma que o UFW vem desativado por padrão. Pré-instalado não é o mesmo que ligado. Se você estiver conectado por SSH, libere primeiro a sua porta SSH real, depois ative o UFW e abra apenas as portas adicionais de que a carga de trabalho precisa. Na configuração padrão, essa primeira regra é sudo ufw allow 22.

Se um firewall de aplicações web também entrar na história, comece pelas categorias. As opções de firewall gratuitas para um VPS Linux se dividem em quatro categorias fáceis de confundir.

A política de atualizações vem em terceiro, e o padrão depende da distribuição. O guia de atualizações automáticas do Ubuntu Server diz que o pacote vem instalado por padrão e aplica automaticamente as atualizações de segurança. Esse pacote é o unattended-upgrades.

O Debian não faz essa promessa. A wiki do Debian alerta que um sistema “pode não ter instalado o pacote, ou pode tê-lo instalado mas desativado por completo”. Para verificar se ele está ativado e configurá-lo, execute sudo dpkg-reconfigure unattended-upgrades.

Os backups vêm em quarto, e a regra é uma restauração. Um backup que ninguém nunca restaurou é uma hipótese. Restaure um em um servidor descartável, veja-o subir, e aí sim ele é um backup.

Em quinto vem um caminho de monitoramento, algo que avise que o servidor caiu antes que um usuário avise. Um verificador leve de uptime resolve. Não existe fórmula confiável que converta o número de monitores em memória, então comece com 1 vCPU e 1 GB e observe.

Além desses cinco, o hardening é um projeto à parte, não uma etapa. Dois guias já cobrem o assunto:

• Uma checklist de 20 itens para proteger um VPS Linux
• A checklist de hardening para VPS Windows

Agora a metade mais difícil: o que não adicionar por padrão em um VPS Linux de 1 ou 2 GB. O CloudPanel exige pelo menos 2 GB de RAM antes de os seus sites usarem qualquer coisa. A própria documentação do ClamAV recomenda 3 GiB ou mais. E a orientação do Virtualmin para pouca memória recomenda desativar totalmente o SpamAssassin e o ClamAV quando a memória está apertada.

São requisitos e recomendações dos fornecedores, não preferências. Eles tornam os três más escolhas padrão em uma máquina pequena, a menos que esse software faça parte da carga de trabalho para a qual você realmente comprou o VPS.

O que cada caso de uso roda

O que varia entre essas dez situações não é tanto o tamanho da máquina, e sim quais dois ou três programas precisam existir antes que qualquer outra coisa importe, e qual restrição costuma decidir o tamanho dessa máquina.

A terceira coluna é a que merece ser lida duas vezes. Mais CPU é o upgrade automático, e em várias dessas linhas não é a restrição que importa.

Hospedar um site ou uma aplicação web

A escolha que define este servidor não é qual servidor web é mais rápido. É quem cuida dos certificados TLS. O Caddy os emite e renova sozinho, sem ferramentas extras. O NGINX espera um cliente ACME separado, como o Certbot, e mais configuração manual, e em troca ocupa menos memória em repouso. A comparação Caddy vs. NGINX coloca os dois arquivos de configuração lado a lado, caso essa troca precise ser conferida antes de você escolher um.

O resto segue a aplicação, e não o contrário. Muitas aplicações dinâmicas precisam de um banco de dados, e se será MariaDB ou PostgreSQL costuma ser decidido pelo que a aplicação suporta, e não por preferência. O Redis ganha seu espaço quando a aplicação realmente precisa de cache, sessões, filas ou outro recurso baseado em Redis. E se mais de um site ou serviço for dividir o servidor, um proxy reverso, ou seja, o processo que fica na frente e encaminha cada requisição para a aplicação certa pelo nome do host, acaba com o malabarismo de portas antes que ele comece. O Nginx Proxy Manager coloca uma interface gráfica nessa tarefa e roda com folga em 2 GB. O guia de instalação do Nginx Proxy Manager mostra o processo passo a passo.

Uma ressalva, e ela aponta para longe do VPS. Se o trabalho é um único site pequeno sem requisitos especiais, a hospedagem gerenciada é uma resposta defensável, e um servidor administrado por você é trabalho extra sem retorno. O VPS se paga no momento em que o site precisa de algo que um plano gerenciado não vai instalar para você.

Substituir ferramentas SaaS pagas por alternativas auto-hospedadas

Aqui o Docker é a decisão que define a ordem, e ela vem antes de qualquer uma das aplicações que você veio buscar. Um runtime de contêineres mantém cada serviço e suas dependências isolados em sua própria caixa, de modo que a versão do PHP do Nextcloud e as bibliotecas de machine learning do Immich nunca brigam entre si. Portainer ou Dockge dão a esse runtime uma interface web e um lugar para ver o que está rodando. O Coolify vai além e transforma o servidor em algo mais próximo de uma plataforma de deploy, com builds por git push e TLS automático. Escolha a camada de gerenciamento depois do runtime, não no lugar dele.

Dica profissional: Instale o Docker a partir do repositório do próprio Docker, e não do repositório da distribuição. A documentação de instalação do Docker chama de não oficial o pacote fornecido pela distribuição e orienta a removê-lo antes de instalar o Docker Engine. Esse pacote é o docker.io.

As aplicações em si são a parte fácil, e é justamente aí que está o problema. Um tópico do r/selfhosted sobre quais serviços auto-hospedados as pessoas mantêm a longo prazo mostra isso com clareza. O autor lista uma série de substitutos que configurou e depois abandonou, e nenhum deles falhou na etapa de deploy. Os motivos citados foram falta de acabamento na experiência de uso e o medo de perder o acesso. Um VPS resolve em cheio a segunda metade, já que não depende da energia de casa nem de uma conexão residencial continuar no ar. Ele não faz absolutamente nada pela primeira metade.

Trading: forex, algorítmico e cripto

Esta é a única seção em que o sistema operacional pode mudar. MetaTrader 4 e MetaTrader 5 são aplicações Windows, então um servidor de trading ainda costuma ser um Windows Server acessado por RDP. A MetaQuotes também oferece suporte para rodar o MetaTrader no Linux via Wine, então o Windows é o caminho nativo mais simples, e não uma exigência. O QuantRocket é a ponta de pesquisa algorítmica e quantitativa da mesma lista, e o BTCPay Server cuida de pagamentos em cripto. Ambos são cargas de trabalho Docker no Linux.

As especificações importam menos que o mapa. Um trader do r/VPSforTradings que planejava um bot de MT5 em cinco corretoras perguntou qual VPS oferece a menor latência até o data center específico de cada corretora, e essa é a pergunta que decide. Os endpoints das principais corretoras se concentram em torno de alguns polos de data centers, e o que você precisa medir é o caminho de rede entre o seu VPS e o endpoint da corretora. Dois servidores com processadores idênticos em redes diferentes ou em cidades diferentes podem se comportar de forma muito diferente nesse trabalho.

O que torna errado o upgrade óbvio. Comprar mais núcleos não encurta o caminho. Escolher a localização de um VPS para forex antes do plano é onde essa decisão acontece.

Mantenha o seu trading online 24 horas por dia com um VPS Forex de baixa latência.

Obter VPS de Trading

Rodar uma VPN privada ou uma rede mesh

Existem dois formatos aqui, e eles não são intercambiáveis. Um servidor WireGuard no VPS dá aos seus dispositivos um caminho criptografado até esse servidor e até tudo o que você roteia por ele. O WireGuard Easy envolve essa configuração em uma interface web, então adicionar um peer deixa de significar editar um arquivo de configuração à mão. Uma rede mesh como o Tailscale é outra coisa: os dispositivos tentam se conectar diretamente entre si, mas o tráfego pode usar um relay entre peers ou um relay DERP quando não há caminho direto possível. A camada de coordenação distribui as informações de que os dispositivos precisam para se descobrir e se conectar. OpenVPN AS, Pritunl, ZTNET e WGDashboard preenchem o espaço entre esses dois polos.

Um tópico do r/selfhosted sobre essa escolha trouxe à tona a preocupação real de depender do Tailscale. Uma das respostas dizia estar “só preocupado com o Tailscale piorar enquanto tenta se tornar lucrativo”. É uma preocupação com o fornecedor, não com o preço. Rodar o túnel você mesmo tira essa empresa da cadeia.

Isso também dá trabalho. Um servidor de coordenação gerenciado realmente exige menos operação, e para um notebook que acessa um único servidor, montar a sua própria mesh é mais maquinaria do que o problema pede. O WireGuard puro basta nesse caso.

Hospedar um servidor de jogos

O jogo é a instalação fácil e o painel é a decisão. Só o Minecraft tem vários tipos de servidor, e qual você roda depende do que você quer dele: Paper para desempenho em um servidor survival comum, Forge ou Quilt quando um modpack é o objetivo. Rodar direto no servidor funciona bem. Rodar sob o Pterodactyl Panel com o daemon Wings, ou sob o PufferPanel, traz limites de recursos por servidor, um console web e uma forma de dar a um amigo permissão para reiniciar sem entregar o SSH. O Nakama é um produto totalmente diferente, para quem está criando um jogo, e não hospedando um.

Um guia do r/admincraft percorre todo o caminho, de um VPS vazio até um servidor com mods automatizado rodando no Pterodactyl, o que dá uma boa ideia do que o caminho do painel oferece.

O custo é um segundo sistema para manter atualizado, e ele nunca deixa de ser um. Para um único servidor vanilla com seis amigos, o painel é mais infraestrutura do que o jogo precisa. O número de mods é a outra variável a acompanhar. Colocar mods em um servidor de ARK mostra o que isso envolve na prática. Tudo o que é público também precisa ser protegido antes que alguém encontre, e o guia de segurança para servidores de Minecraft cobre essa etapa.

Rodar modelos de IA e inferência local

O Ollama roda o modelo e o Open WebUI é a interface acoplada a ele. O LiteLLM só ganha espaço na frente quando as chamadas precisam ser roteadas entre provedores, e o Qdrant só quando a recuperação faz parte do plano.

Sem GPU, o teto chega rápido. Alguém que tentava rodar o Ollama em um VPS de 8 GB só com CPU deu de cara com um erro de falta de memória: o modelo queria 7,2 GiB e havia 3,8 GiB livres, porque o sistema operacional e o Coolify já tinham ocupado a diferença. Modelos quantizados pequenos, ou seja, com pesos armazenados em precisão menor para caber em menos memória, podem rodar em CPU se o modelo e o runtime couberem na RAM do sistema. Se couberem, a troca habitual é uma inferência mais lenta; se não couberem, o processo pode falhar com um erro de falta de memória.

A qualidade é o segundo limite. Um tópico do r/selfhosted sobre se vale a pena auto-hospedar o Ollama mostra o outro lado. Um comentarista descreveu os modelos abertos que havia testado como de “qualidade pior” e disse: “você não vai vencer esses gigantes de bilhões de dólares”. É a experiência de um usuário, não uma regra para todo modelo aberto. Auto-hospedar dá a você controle sobre dados e infraestrutura; se isso supera uma API hospedada em qualidade ou custo depende do modelo, da carga de trabalho e da utilização.

A conta de custos contra uma API hospedada mostra onde a economia muda. Modelos maiores, mais concorrência ou metas de latência mais apertadas transformam isso em uma questão de hardware. Os planos de GPU VPS da Cloudzy foram feitos para esse caso.

Uma área de trabalho remota ou estação de trabalho na nuvem

Três mecanismos diferentes se escondem por trás da expressão “área de trabalho remota”, e escolher pelo nome do produto em vez do mecanismo é como as pessoas acabam com o errado. Uma sessão RDP é uma área de trabalho real rodando no servidor, na qual você faz login. A imagem de um clique IceWM over XRDP da Cloudzy é o pacote leve aqui: traz IceWM, Terminator, Falkon e um listener xRDP com TLS, enquanto o Linux Mint oferece uma área de trabalho completa em vez de uma mínima.

O Kasm Workspaces pode entregar aplicações e áreas de trabalho em contêineres sob demanda no navegador, mas também pode expor servidores RDP, VNC, SSH e KasmVNC já existentes por meio de Server workspaces. O Neko é diferente de novo: transmite um único navegador virtual compartilhado via WebRTC para várias pessoas em uma sala, o que não é uma área de trabalho em que alguém faça login.

Se o que você quer é a própria área de trabalho do servidor, use um Kasm Server workspace baseado em RDP ou VNC em vez de um workspace de contêiner. A documentação do Kasm sobre infraestrutura fixa cobre essa configuração. As sessões nativas em contêiner do Kasm são ambientes separados, não a área de trabalho do host.

Se a máquina que você quer já existe e só precisa ser acessada, o RustDesk chega até ela sem montar área de trabalho nenhuma, e o Sshwifty dá um shell no navegador quando um shell era tudo o que você precisava. Defina o protocolo antes do nome do produto. Conectar por RDP e transmitir uma sessão de navegador não são a mesma coisa com rótulos diferentes.

Uma máquina de desenvolvimento, build e CI

O Code Server coloca o VS Code em uma aba do navegador apontada para o sistema de arquivos do servidor, e é isso que faz valer a pena manter o resto da máquina junto: Gitea ou Forgejo com os repositórios que o editor abre, Jenkins rodando os pipelines que esses commits disparam e Docker por baixo de ambos. A peça mais nova são os agentes de programação com IA que agora ficam na mesma máquina: Claude Code, Aider, OpenCode e Goose CLI.

Essa configuração óbvia não é a única. Um tópico do r/selfhosted sobre ambientes de desenvolvimento remotos teve uma resposta defendendo o contrário: manter o editor instalado localmente e apontá-lo para o VPS por meio de uma extensão de desenvolvimento remoto, para que a interface fique local e só os arquivos e a execução sejam remotos. A reclamação do autor do tópico era o host capturar os atalhos de teclado em vez do navegador, um custo real da versão no navegador.

As duas são legítimas. Rodar o Code Server com um agente de IA percorre o caminho do navegador de ponta a ponta. A stack de desenvolvimento auto-hospedada reúne tudo o que fica em volta do editor.

Automação, bots e tarefas agendadas

O n8n é o ponto de partida habitual, e é uma escolha padrão justa: um construtor visual de workflows em que os nós são serviços e as conexões são dados circulando entre eles. O Activepieces faz um trabalho parecido sob uma licença mais permissiva. O Node-RED ataca o mesmo problema pela outra ponta, baseado em fluxos e voltado à ligação de dispositivos e eventos, e não à cola entre SaaS. O Dagu é um agendador para grafos de dependências, adequado quando o que você tem é, na verdade, um conjunto de tarefas cron que precisam de ordem.

Esses serviços continuam rodando entre as tarefas. O uso de recursos cresce com a atividade dos workflows, enquanto o histórico de execução retido faz crescer principalmente o banco de dados e o armazenamento. Isso os torna o tipo de carga de trabalho que pode ultrapassar silenciosamente o menor servidor alguns meses depois de parecer suficiente. A comparação de alternativas auto-hospedadas ao Zapier traz os detalhes de licenciamento e dimensionamento.

Servir mídia

O armazenamento costuma ser a primeira restrição aqui, mas a transcodificação pode tornar a capacidade de CPU ou GPU o fator decisivo. Jellyfin para vídeo, Navidrome para música e Audiobookshelf para audiolivros e podcasts reúnem cada um um scanner de biblioteca, um buscador de metadados e um servidor de streaming em uma única aplicação que se instala como qualquer outro serviço web, e AzuraCast (uma rádio web) e Immich (fotos) seguem o mesmo padrão.

Isso faz do VPS o formato errado com mais frequência do que o contrário. Transcodificar em tempo real custa tempo de processador que um servidor pequeno não tem sobrando, e uma máquina em casa com discos grandes costuma ser o melhor host para a biblioteca em si, com o VPS justificando seu lugar pelo acesso remoto e por ficar sempre no ar. A comparação de alternativas ao Plex mostra qual servidor combina com qual cliente.

O que fica com você depois que tudo está instalado

Cada programa citado acima chega com uma tarefa junto. Alguém aplica os patches, vigia a memória, renova o certificado e descobre se o backup restaura. Em um VPS autogerenciado esse alguém é você, e a carga se acumula a cada uma dessas situações que acaba na mesma máquina.

A metade da instalação é a que vale a pena encurtar. Se o software que você escolher estiver disponível como app de um clique, isso encurta a etapa de instalação em vez de deixar você com um servidor em branco e uma aba de documentação aberta. Um VPS Linux da Cloudzy dá a você esse ponto de partida, para que a primeira hora vá para aquilo que motivou a compra do servidor. A metade da operação continua sendo sua de qualquer forma. Essa parte não se terceiriza.

Construa num VPS Linux com acesso root, NVMe e o poder do AMD EPYC.

Ver planos Linux

Perguntas frequentes