O seu próprio servidor Blossom

Última atualização: 27 de outubro de 2026

O Herkos Drive corta cada ficheiro em blocos cifrados e guarda-os em vários servidores Blossom: três cópias, em pelo menos dois tipos de servidor, e uma num servidor seu. Os servidores públicos guardam blocos de graça, mas não prometem nada: podem purgá-los, encher ou fechar.

Um servidor Blossom próprio guarda a sua cópia durante o tempo que decidir e só aceita blocos do seu Drive. Esta página explica como montar um em três passos, mais uma cópia de segurança noturna. Combina bem com o seu próprio relay de correio, e demora cerca de quinze minutos se já tiver um servidor.

Que servidor usar

blossom-server de hzrd149, versão 6.4.1 (6 de outubro de 2026, licença MIT). Pusemo-lo a funcionar a 27 de outubro de 2026 com a configuração abaixo e o próprio código de envio do Drive, e verificámos aquilo de que o Drive precisa, não o que o servidor anuncia:

O que precisa

• Uma máquina sempre ligada e acessível a partir da internet: um VPS pequeno ou um computador em casa. Precisa de tanto disco quanto o que o seu Drive ocupa, e de alguma margem para crescer.
• Um domínio ou subdomínio que aponte para ela, por exemplo blossom.example.com.
• Docker e um proxy inverso que forneça HTTPS. Os exemplos usam o Caddy, que obtém o certificado sozinho.
• A chave do volume do seu Drive. O Herkos Drive mostra-a em Definições → Servidores → O teu servidor pessoal, como 64 letras e algarismos. Não é a chave do seu perfil: o Drive nunca envia com a chave do perfil, por isso um servidor que só aceite o seu npub recusaria o Drive.

Passo 1: pôr o servidor a funcionar

Crie uma pasta para ele, por exemplo /root/blossom, e guarde nela estes dois ficheiros. O primeiro é o docker-compose.yml:

services:
  blossom:
    image: ghcr.io/hzrd149/blossom-server:6.4.1
    environment:
      BLOSSOM_REQUIRE_CONFIG: "1"
    ports:
      - "127.0.0.1:3000:3000"
    volumes:
      - data:/app/data
      - ./config.yml:/app/config.yml:ro
    restart: unless-stopped
volumes:
  data: {}

O segundo é o config.yml. Ponha o seu domínio em publicDomain e a sua chave do volume onde diz YOUR-VOLUME-KEY:

port: 3000
host: 0.0.0.0
publicDomain: blossom.example.com
storage:
  backend: local
  local:
    dir: ./data/blobs
  rules:
    - type: "*"
      expiration: 100 years
      pubkeys:
        - "YOUR-VOLUME-KEY"
upload:
  requireAuth: true
  maxSize: 104857600
  requirePubkeyInRule: true
mirror:
  enabled: true
  requireAuth: true
delete:
  requireAuth: true
list:
  enabled: false
media:
  enabled: false
report:
  enabled: false
landing:
  enabled: false

O que diz: só a sua chave do volume pode enviar ou pedir cópias (requirePubkeyInRule), e um bloco fica guardado até o Drive o apagar. O servidor exige uma expiração em cada regra; 100 years sem ser lido é, na prática, nunca, e de qualquer forma o Drive lê os seus blocos com regularidade. A porta só escuta na própria máquina (127.0.0.1): tudo passa pelo proxy. Inicie-o:

cd /root/blossom
docker compose up -d

Passo 2: colocar HTTPS à frente

Com o Caddy, a configuração completa (/etc/caddy/Caddyfile) é:

blossom.example.com {
    reverse_proxy 127.0.0.1:3000
}

Se o mesmo Caddy já serve o seu relay, acrescente este bloco por baixo desse. Recarregue o Caddy (sudo systemctl reload caddy). Ao abrir https://blossom.example.com num navegador, deverá agora obter resposta, com um 404: não há página inicial, de propósito.

Passo 3: informar o Herkos Drive

1. No Herkos Drive, abra Definições → Servidores, adicione https://blossom.example.com e marque-o como teu.
2. O Drive pergunta-lhe antes de cada envio. A partir daí, cada ficheiro novo recebe lá uma cópia, e os ficheiros que já tinha recebem a sua da próxima vez que o Drive verificar as cópias.
3. Mantenha os outros servidores na lista. O seu é uma das três cópias, nunca a única: se for abaixo, os seus ficheiros continuam nos outros, e o Drive avisa-o ao fim de uma semana de silêncio.

Passo 4: fazer uma cópia de segurança todas as noites

Se o seu servidor morrer, o Drive dá por isso e dá aos ficheiros afetados cópias nos outros servidores da sua lista. Mas a cópia no seu servidor é a única que não depende de mais ninguém, e uma cópia noturna permite-lhe reconstruí-la sem voltar a copiar tudo pela internet.

O servidor guarda tudo dentro do volume Docker blossom_data (o nome começa pela pasta onde estão os ficheiros; confirme-o com docker volume ls): os blocos, um ficheiro cada, e uma pequena base de dados SQLite que diz quem enviou cada um. Os blocos nunca mudam, mas a base de dados não deve ser copiada enquanto está a ser escrita. Por isso o script copia tudo com o servidor a funcionar, para-o durante os poucos segundos que demora a copiar o que mudou entretanto, volta a iniciá-lo e só depois envia a cópia. Enquanto está parado, o Drive simplesmente tenta de novo um pouco mais tarde.

A cópia sai do servidor com o restic, que a cifra antes de sair. Use um sítio num fornecedor diferente do servidor: uma conta SFTP (uma storage box, um computador em casa) ou um bucket compatível com S3. Se já faz assim a cópia do seu relay, use o mesmo sítio com outra pasta.

1. Instale as ferramentas e crie o repositório. Guarde também a palavra-passe no seu gestor de palavras-passe: sem ela as cópias não podem ser lidas, e se só existir no servidor, morre com o servidor. Para SFTP, o root também precisa de uma chave SSH que a máquina de cópias aceite (sudo ssh-keygen -t ed25519, e depois adicione lá /root/.ssh/id_ed25519.pub).

   sudo apt install restic rsync
   sudo sh -c 'openssl rand -base64 32 > /root/.restic-blossom-password'
   sudo sh -c 'cat > /root/.restic-blossom-env' <<'END'
   export RESTIC_REPOSITORY=sftp:backup@backup.example.com:/blossom
   export RESTIC_PASSWORD_FILE=/root/.restic-blossom-password
   END
   sudo chmod 600 /root/.restic-blossom-password /root/.restic-blossom-env
   sudo sh -c '. /root/.restic-blossom-env && restic init'
   

2. Guarde isto como /usr/local/bin/backup-blossom e torne-o executável (sudo chmod 700 /usr/local/bin/backup-blossom). Altere BLOSSOM_DIR se os seus ficheiros não estiverem em /root/blossom. Mantém os últimos 14 dias, 8 semanas e 12 meses. Os blocos nunca mudam, por isso cada noite só acrescenta o que é novo.

   #!/bin/sh
   set -eu
   . /root/.restic-blossom-env
   BLOSSOM_DIR=/root/blossom
   COPY=/var/backups/blossom-data
   VOLUME=$(docker volume inspect --format '{{ .Mountpoint }}' blossom_data)
   mkdir -p "$COPY"
   rsync -a --delete "$VOLUME/" "$COPY/"
   cd "$BLOSSOM_DIR"
   docker compose stop blossom
   trap 'docker compose start blossom' EXIT
   rsync -a --delete "$VOLUME/" "$COPY/"
   docker compose start blossom
   trap - EXIT
   restic backup "$COPY" --tag blossom
   restic forget --tag blossom --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --prune
   

3. Execute-o uma vez à mão (sudo /usr/local/bin/backup-blossom) e depois agende-o com sudo crontab -e. A segunda linha volta a ler um décimo dos dados guardados todos os meses, um décimo diferente de cada vez, para provar que as cópias ainda podem ser abertas. Veja de vez em quando o /var/log/backup-blossom.log: uma linha com Fatal significa que a cópia dessa noite falhou. Se a cópia do relay for feita na mesma máquina, estas horas não coincidem com as dele.

   35 4 * * * /usr/local/bin/backup-blossom >> /var/log/backup-blossom.log 2>&1
   55 5 2 * * . /root/.restic-blossom-env && restic check --read-data-subset=10% >> /var/log/backup-blossom.log 2>&1
   

Para restaurar (um servidor novo, ou depois de uma avaria do disco): monte de novo o servidor (passos 1 e 2) e repita os pontos 1 e 2 deste passo com o mesmo repositório, mas escreva a palavra-passe que guardou em /root/.restic-blossom-password em vez de criar uma nova, e salte o restic init. Depois copie a cópia mais recente para o volume do servidor:

sudo sh -c '. /root/.restic-blossom-env && restic restore latest --tag blossom --target /'
cd /root/blossom && sudo docker compose stop blossom
sudo rsync -a --delete /var/backups/blossom-data/ "$(sudo docker volume inspect --format '{{ .Mountpoint }}' blossom_data)/"
sudo docker compose start blossom

Da próxima vez que verificar as cópias, o Drive volta a encontrar os blocos e copia dos outros servidores o que tiver chegado depois da última cópia. Testámos toda esta cadeia a 27 de outubro de 2026: cópia de segurança, servidor apagado, restauro, cada bloco relido com o seu próprio hash, e apagado no fim com a chave do Drive.

Uma vez por ano, faça este restauro numa máquina de reserva e verifique que o servidor responde com os seus blocos: é o único teste que prova a cadeia completa, palavra-passe incluída.

Bom saber

• Só o seu Drive pode enviar. Qualquer pessoa que saiba o endereço de um bloco pode descarregá-lo, como em qualquer servidor Blossom, mas está cifrado: sem as chaves do seu Drive é ruído.
• Se a sua chave do volume mudar (o Drive avisa-o quando um volume é renovado), acrescente a nova como outra linha em pubkeys, reinicie (docker compose up -d) e deixe lá a antiga.
• Atualizações. Leia o registo de alterações, mude a versão em image: e execute docker compose pull e docker compose up -d.
• O seu endereço IP. O servidor vê o endereço de cada aplicação que se liga a ele, como qualquer servidor. No seu próprio servidor, o único que os vê é você.