Stack de self-hosting para VPS pequeno: o que cabe em 2 GB e 4 GB de RAM

Resposta curta: um VPS de 2 GB roda com folga um núcleo self-hosted com Caddy (reverse proxy HTTPS), Vaultwarden (senhas), Uptime Kuma (monitoramento) e Forgejo (git) sob Docker Compose, usando cerca de 0,6 a 1 GB de RAM. Acrescente o Nextcloud e você vai querer 4 GB; escolha ferramentas mais leves, como Syncthing ou File Browser, e 2 GB continuam bastando.

Este guia traz um arquivo Compose funcional, um orçamento de RAM por serviço e as duas coisas que a maioria dos setups self-hosted deixa para depois, até ser tarde demais: backups fora do servidor e uma superfície de rede fechada. Os comandos pressupõem Debian 12/13 ou Ubuntu 24.04 com Docker Engine e o plugin Compose instalados a partir do repositório oficial do Docker.

Orçamento de RAM por serviço

Os números são a memória residente típica, de ocioso a uso leve, para um a cinco usuários com SQLite quando suportado. Picos durante atualizações, clones git de repositórios grandes ou geração de previews no Nextcloud podem ser maiores, então deixe pelo menos 20% de folga e adicione um arquivo de swap de 1 a 2 GB.

Escolhendo o tamanho do VPS

A stack principal (Caddy, Vaultwarden, Uptime Kuma, Forgejo) mais o sistema base fica em torno de 0,6 a 1 GB, o que cabe num servidor de 2 vCPU / 2 GB com espaço para Syncthing e Radicale. O Nextcloud com MariaDB e Redis leva o total para cerca de 1,5 a 2,2 GB, então 4 GB é o mínimo realista se você quer a suíte completa e todo o resto. O disco também importa: os repositórios do Forgejo e os arquivos sincronizados crescem, enquanto os serviços em si precisam de apenas alguns GB.

Na NoctisNode, o plano Pulse (2 vCPU, 2 GB de RAM, 40 GB NVMe, $10 por 28 dias) comporta a stack principal, e o Umbra (4 vCPU, 4 GB, 60 GB NVMe, $15 por 28 dias) comporta a stack principal mais o Nextcloud. Ambos são KVM com root completo e IPv4 dedicado, e podem ser pagos em Monero ou outras criptomoedas. Nada neste guia depende do provedor.

Arquivo do Docker Compose

Só o Caddy publica portas web; os apps são acessíveis apenas pela rede interna do Compose. O Forgejo também publica a porta 2222 para git via SSH, para que o OpenSSH do host continue na porta dele. Defina `FORGEJO_TAG` num arquivo `.env` com a versão principal atual do Forgejo e substitua os domínios de exemplo pelos seus próprios registros DNS.

# /srv/stack/compose.yaml
services:
  caddy:
    image: caddy:2
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - ./caddy/data:/data
      - ./caddy/config:/config

  vaultwarden:
    image: vaultwarden/server:latest
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "true"   # set to "false" after creating your account
    volumes:
      - ./vaultwarden:/data

  uptime-kuma:
    image: louislam/uptime-kuma:2
    restart: unless-stopped
    volumes:
      - ./uptime-kuma:/app/data

  forgejo:
    image: codeberg.org/forgejo/forgejo:${FORGEJO_TAG}
    restart: unless-stopped
    environment:
      USER_UID: "1000"
      USER_GID: "1000"
      FORGEJO__service__DISABLE_REGISTRATION: "true"
    volumes:
      - ./forgejo:/data
    ports:
      - "2222:22"

# /srv/stack/Caddyfile
# vault.example.com {
#     reverse_proxy vaultwarden:80
# }
# status.example.com {
#     reverse_proxy uptime-kuma:3001
# }
# git.example.com {
#     reverse_proxy forgejo:3000
# }

Colocando no ar

1. 01.Aponte registros A (e AAAA) de `vault`, `status` e `git` para o IP do servidor, para que o Caddy consiga obter os certificados na primeira inicialização.
2. 02.Crie `/srv/stack`, coloque ali `compose.yaml`, `Caddyfile` e `.env` e rode `docker compose up -d`.
3. 03.Abra a URL do Forgejo e conclua o instalador; a primeira conta criada por ele vira a de administrador, já que o cadastro público está desativado.
4. 04.Crie sua conta no Vaultwarden, depois defina `SIGNUPS_ALLOWED` como `"false"` e rode `docker compose up -d` de novo. Deixe o painel de administração desativado, a menos que você defina um `ADMIN_TOKEN` com hash Argon2.
5. 05.Crie o usuário administrador do Uptime Kuma logo após a inicialização, porque a página de configuração fica aberta para qualquer um até você fazer isso.
6. 06.Adicione monitores para cada serviço e para o vencimento dos certificados, de preferência a partir de um segundo local, já que um monitor no mesmo servidor não consegue informar a própria queda.

Note · O Caddy cuida do HTTPS automaticamente. Para headers, rate limits e roteamento mais complexo, veja o guia de reverse proxy com Caddy.

Backups que realmente restauram

Tudo o que vale a pena guardar fica em `/srv/stack`: bancos SQLite, repositórios do Forgejo, certificados do Caddy e sua configuração. Não conte com os snapshots do provedor; mantenha sua própria cópia criptografada e fora do servidor com restic, como descrito no guia de backups com restic.

Arquivos SQLite copiados enquanto um serviço está escrevendo podem ficar inconsistentes. A abordagem segura mais simples num servidor pequeno é parar a stack durante o minuto que o backup leva. Se você adicionar o Nextcloud com MariaDB, faça o dump do banco com `mariadb-dump` antes de rodar o restic. Teste uma restauração para um diretório temporário pelo menos uma vez; um backup que você nunca restaurou é um palpite.

#!/bin/sh
# /usr/local/sbin/stack-backup (run nightly from cron or a systemd timer)
# needs RESTIC_REPOSITORY and RESTIC_PASSWORD_FILE in the environment
cd /srv/stack || exit 1
docker compose stop
rc=0
restic backup /srv/stack --tag stack || rc=$?
docker compose start
[ "$rc" -eq 0 ] || exit "$rc"
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Segurança básica

• ▹SSH: só chaves, sem login de root por senha e, opcionalmente, uma porta fora do padrão; veja o [guia de hardening de SSH](/guides/ssh-hardening).
• ▹Ressalva do firewall: portas publicadas pelo Docker ignoram as regras do `ufw`, porque o Docker escreve as próprias chains de iptables/nftables. Publique só o que precisa ser público (80, 443, 2222) e nunca publique portas de banco de dados ou de administração.
• ▹Atualizações: ative o `unattended-upgrades` no host e rode `docker compose pull && docker compose up -d` numa rotina que você realmente cumpra.
• ▹Cadastro: mantenha os cadastros públicos desativados no Vaultwarden e no Forgejo; convide os usuários em vez disso.
• ▹Criptografia de disco: coloque o `/srv` num [root criptografado](/guides/luks-encrypted-root) para que uma imagem copiada do disco não revele nada; num servidor remoto, use o [desbloqueio remoto do LUKS via SSH](/guides/luks-remote-unlock-ssh) e prefira o formato LUKS2 explicado em [LUKS2 vs LUKS1](/guides/luks2-vs-luks1).
• ▹Segredos: o `.env` e o diretório de dados do Vaultwarden devem ser legíveis apenas pelo root (`chmod 600`/`700`).

Perguntas frequentes