InfraIniciante6 min de leitura6 seçõesanos 2000, Data aproximada

VPS — o servidor na sua mão

Uma fatia virtual de um servidor físico, com root, IP público e nenhuma opinião: você instala, configura, protege e opera tudo. É o chão que explica os andares de cima — container, orquestrador e PaaS são abstrações disto aqui.

Em 10 segundos

Um pedaço virtual de servidor com root e IP público: liberdade total, responsabilidade total. Deploy, TLS, firewall, backup e plantão são seus. É o modelo mais barato e mais educativo de rodar software — e a base conceitual de todos os outros.

Antes de ter nome

Fatiar uma máquina em várias 'máquinas' isoladas é dos mainframes IBM dos anos 1970 (CP/CMS), muito antes de a nuvem revender fatias por hora.

  • #servidor
  • #deploy
  • #linux
  • #ssh
  • #hospedagem
Analogia

Casa alugada, não quarto de hotel

PaaS é quarto de hotel: arrumadeira, recepção, manutenção — tudo incluso na diária, tudo nas regras do hotel. VPS é casa alugada vazia: você escolhe cada móvel e ninguém reclama da furadeira às 23h — mas fechadura, vazamento e conta de luz são problema seu. O aluguel é mais barato; o seu tempo é a diferença.

01Conceito

Por que ainda começar por aqui

Tudo que roda 'na nuvem' roda num servidor de verdade em algum lugar — um processo, atrás de um proxy, num Linux com firewall. PaaS, container e serverless empilham abstrações sobre exatamente isso. Quem nunca montou o de baixo opera os de cima no escuro: não sabe o que a plataforma cobra para esconder, nem consertar quando a abstração vaza.

E há o caso pragmático: para um side project, um bot, um app interno de baixo tráfego, o VPS de R$ 30–50/mês com tudo dentro (app, banco, cache) bate qualquer conta de PaaS — desde que alguém pague o custo real, que é atenção.

A anatomia mínima de produção num VPS: o app como serviço do systemd (reinicia sozinho, loga no journald), Nginx na frente fazendo TLS e proxy reverso para a porta interna, firewall liberando só 22/80/443, SSH por chave com senha desabilitada, atualizações de segurança automáticas e backup — do que dói perder — testado com restauração de verdade.

O passo seguinte natural é rodar containers no VPS: o Docker Compose vira seu 'orquestrador de uma máquina só', e o servidor deixa de acumular instalações artesanais. É meio caminho honesto entre o metal e o Kubernetes — e para uma máquina, costuma ser o ponto final ideal.

Como se encaixa
  1. Usuário
  2. HTTPS :443Nginx (TLS)
  3. proxy_pass 127.0.0.1:3000App (systemd)
  4. socket localPostgres local
O caminho de uma request no VPS clássico: só o Nginx encara a internet; app e banco vivem em portas internas que o firewall nem expõe.
02Anatomia

As três responsabilidades da máquina

Camada 1/3Borda

Camada 1

Borda

Nginx, TLS e firewall — a única porta para a rua

O proxy reverso termina o TLS (certificado gratuito, renovação automática), comprime, e repassa para a porta interna. O firewall nega tudo por padrão e abre só 22, 80 e 443. SSH por chave, senha desabilitada, e de preferência fail2ban vigiando a porta 22 — os bots chegam em minutos, não em dias.

Se violar: app exposto direto na porta pública = sem TLS decente, sem limite de conexão, e cada CVE do seu runtime vira porta de entrada.

03Implementação

Código

// Num VPS, quem mantém seu app vivo é o systemd — e o app precisa cooperar:
// porta por env, log em stdout (o journald coleta) e SIGTERM tratado.
import http from "node:http";

const porta = Number(process.env.PORT ?? 3000);

const servidor = http.createServer((req, res) => {
  console.log(JSON.stringify({ rota: req.url, em: Date.now() })); // -> journalctl
  res.writeHead(200).end("ok");
});

// Só na interface local: quem fala com a internet é o Nginx (proxy reverso),
// que cuida de TLS e esconde a porta interna atrás do firewall.
servidor.listen(porta, "127.0.0.1", () =>
  console.log(`app interno em 127.0.0.1:${porta}`)
);

process.on("SIGTERM", () => servidor.close(() => process.exit(0)));

/* A unidade do systemd que segura tudo (/etc/systemd/system/app.service):
   [Service]
   ExecStart=/usr/bin/node /srv/app/dist/main.js
   Environment=PORT=3000
   Restart=always          # caiu -> volta, inclusive às 3h da manhã
   User=app                # nunca root
   [Install]
   WantedBy=multi-user.target

   E o Nginx na frente:
   server {
     listen 443 ssl;
     location / { proxy_pass http://127.0.0.1:3000; }
   }
*/
04No mundo real

Casos de uso

Side project a custo de pizza

Cenário

Um SaaS de nicho com 200 usuários: API em Node, Postgres, Redis e um cron de relatórios. No PaaS, cada peça é uma linha na fatura; o total passa de R$ 400/mês antes do primeiro cliente pagar.

Como o padrão entra

Um VPS de 4 GB roda tudo via Docker Compose por R$ 60/mês: Nginx com TLS na frente, deploy por git pull + compose up, dump do banco toda madrugada para um bucket. O projeto sobrevive ao vale da validação sem sangrar caixa.

Trade-off: Sem redundância: a máquina é um ponto único de falha, e o 'time de infra' é você no domingo. O upgrade de porte envolve migração planejada, não um slider.

Ferramenta interna atrás de IP fixo

Cenário

Um painel interno precisa consumir a API de um parceiro que só libera acesso por allowlist de IP — e o PaaS da empresa troca de IP de saída sem avisar.

Como o padrão entra

O painel vai para um VPS com IP fixo, que entra na allowlist do parceiro uma única vez. O firewall restringe o acesso de entrada à VPN da empresa, e o systemd + Nginx cuidam do resto — infraestrutura estável, previsível e barata para um problema que era de rede, não de escala.

Trade-off: Nasce mais uma máquina fora do guarda-chuva da plataforma oficial: patches, monitoração e inventário agora incluem esse servidor — o 'servidor esquecido' é um clássico de auditoria de segurança.

05Cuidado

Armadilhas

  1. O servidor floco de neve

    Três anos de ajustes por SSH sem registro e a máquina vira única no universo: ninguém sabe reproduzi-la, e migrar é arqueologia. Anote cada passo num script ou README versionado — ou use containers e deixe o Dockerfile ser a memória.

  2. Segurança adiada para depois do MVP

    Um IP público novo recebe scans em minutos. Senha de SSH habilitada, Postgres escutando em 0.0.0.0, painel sem TLS: cada um é um convite. A higiene mínima — chave SSH, firewall negando por padrão, atualizações automáticas — leva uma hora e não é opcional.

  3. Backup no mesmo disco (ou nunca testado)

    Dump diário gravado na própria máquina protege contra DELETE errado, não contra disco morto, ransomware ou conta suspensa. Backup de verdade mora em outro lugar e é restaurado de tempos em tempos como ensaio — a restauração é o produto; o dump é só o meio.

  4. Esquecer que o plantão é seu

    Sem SLA de plataforma, o uptime é uma função da sua atenção: kernel sem patch, disco enchendo, certificado vencendo em silêncio. Monitoração externa simples (um ping de fora + alerta de disco) transforma surpresas de sábado em tarefas de terça.

06Decisão

Quando usar × quando evitar

Use quando

3
  • Side projects, MVPs e ferramentas internas onde custo fixo baixo importa.
  • Requisitos que PaaS não atende: IP fixo, software exótico, rede peculiar.
  • Como aprendizado — operar uma máquina ensina o que as abstrações escondem.

Evite quando

3
  • Produto com SLA sério e time sem operador — a economia do VPS evapora no primeiro incidente.
  • Cargas elásticas com picos de 10× — escala manual não chega a tempo.
  • Dados sensíveis sob compliance pesado sem maturidade de segurança — o gerenciado herda certificações que você teria que construir.

Testar o que ficou

4 armadilhas de VPS — o servidor na sua mão viram perguntas, com o nome do padrão escondido, misturadas com padrões parecidos.

Onde isto aparece de verdade

Você já usa isto, talvez sem saber o nome.

  • Droplets da DigitalOceanUma máquina virtual que é só sua: você escolhe o tamanho, recebe o IP e entra por SSH para administrar o sistema inteiro.
  • instâncias EC2 da AWSO servidor virtual clássico da nuvem — você controla o SO, instala o que quiser e paga pelo tempo em que a instância fica ligada.
  • servidor acessado por SSHO modelo mais cru: um host remoto onde você mesmo instala runtime, banco e proxy, sem camada de orquestração entre você e o Linux.

O padrão em uma linha

Sem nome de domínio, sem cerimônia. Só a ideia.

// Uma máquina sua; você opera o resto.
// ssh + systemd — sem orquestrador.

O que ele cobra

Nenhum salto a mais entre a chamada e o efeito.

  • Você administra o sistema inteiro: patches, segurança, backup e monitoramento são seus
  • Escalar é manual — subir, dimensionar e balancear máquinas fica por sua conta

Não vale se: a carga é irregular ou você não quer operar servidor — aí uma plataforma gerenciada ou serverless tira esse trabalho de você.

Onde isto aparece

Continue por aqui