Seu próprio servidor Blossom
Última atualização: 27 de outubro de 2026
O Herkos Drive corta cada arquivo em blocos criptografados e os guarda em vários servidores Blossom: três cópias, em pelo menos dois tipos de servidor, e uma num servidor seu. Servidores públicos guardam blocos de graça, mas não prometem nada: podem expurgá-los, lotar ou fechar.
Um servidor Blossom próprio guarda sua cópia pelo tempo que você decidir e só aceita blocos do seu Drive. Esta página explica como configurar um em três passos, mais um backup noturno. Ele combina bem com seu próprio relay de caixa postal, e leva uns quinze minutos se você já tiver um servidor.
Qual servidor usar
blossom-server de hzrd149, versão 6.4.1 (6 de outubro de 2026, licença MIT). Rodamos o servidor em 27 de outubro de 2026 com a configuração abaixo e o próprio código de upload do Drive, e verificamos o que o Drive precisa, não o que o servidor anuncia:
| O que o Drive faz | Resultado |
|---|---|
Envia blocos criptografados de 8 MiB (application/octet-stream) |
Aceitos |
| Pergunta antes de enviar (BUD-06) | Responde, e recusa qualquer outra chave |
| Pede ao seu servidor que copie um bloco de um servidor público (BUD-04) | Copiado |
| Lê um bloco sem se identificar | Servido, byte a byte |
| Apaga um bloco com a chave que o enviou | Apagado: pedir de novo dá 404 |
| Envios de qualquer outra chave | Recusados (401) |
Do que você precisa
- Uma máquina sempre ligada e acessível pela internet: uma VPS pequena ou um computador em casa. Ela precisa de tanto disco quanto seu Drive ocupa, e de alguma folga para crescer.
- Um domínio ou subdomínio apontando para ela, por exemplo
blossom.example.com. - Docker e um proxy reverso que ofereça HTTPS. Os exemplos usam o Caddy, que obtém o certificado sozinho.
- A chave do volume do seu Drive. O Herkos Drive a mostra em Configurações → Servidores → Seu servidor pessoal, como 64 letras e dígitos. Não é a chave do seu perfil: o Drive nunca envia com a chave do seu perfil, então um servidor que só aceite seu npub recusaria o Drive.
Passo 1: rode o servidor
Crie uma pasta para ele, por exemplo /root/blossom, e salve nela estes dois
arquivos. 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. Coloque seu domínio em publicDomain e sua chave do
volume onde está escrito 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 ele diz: só sua chave do volume pode enviar ou pedir cópias
(requirePubkeyInRule), e um bloco fica guardado até o Drive apagá-lo. 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ê seus blocos regularmente. 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: coloque HTTPS na frente
Com o Caddy, a configuração inteira (/etc/caddy/Caddyfile) é:
blossom.example.com {
reverse_proxy 127.0.0.1:3000
}
Se o mesmo Caddy já serve seu relay, adicione este bloco abaixo daquele.
Recarregue o Caddy (sudo systemctl reload caddy). Abrir
https://blossom.example.com num navegador agora deve dar resposta, com um 404:
não há página inicial, de propósito.
Passo 3: avise o Herkos Drive
- No Herkos Drive, abra Configurações → Servidores, adicione
https://blossom.example.come marque-o como seu. - O Drive pergunta a ele antes de cada envio. A partir daí, todo arquivo novo ganha uma cópia lá, e os arquivos que você já tinha ganham a deles na próxima vez que o Drive verificar as cópias.
- Mantenha os outros servidores na lista. O seu é uma das três cópias, nunca a única: se ele cair, seus arquivos continuam nos outros, e o Drive te avisa depois de uma semana de silêncio.
Passo 4: faça backup toda noite
Se seu servidor morrer, o Drive percebe e dá aos arquivos 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 um backup noturno permite reconstruí-la sem copiar tudo de novo pela internet.
O servidor guarda tudo dentro do volume Docker blossom_data (o nome começa com
a pasta em que estão os arquivos; confira com docker volume ls): os blocos, um
arquivo cada, e um pequeno banco de dados SQLite que diz quem enviou cada um. Os
blocos nunca mudam, mas o banco de dados não deve ser copiado enquanto está sendo
escrito. Então o script copia tudo com o servidor rodando, para-o pelos poucos
segundos que leva para copiar o que mudou nesse meio-tempo, inicia-o de novo e só
então envia a cópia. Enquanto ele está parado, o Drive simplesmente tenta de novo
um pouco depois.
A cópia sai do servidor com o restic, que a criptografa antes que ela saia. Use um lugar num provedor diferente do servidor: uma conta SFTP (um storage box, um computador em casa) ou um bucket compatível com S3. Se você já faz backup do seu relay assim, use o mesmo lugar com outra pasta.
-
Instale as ferramentas e crie o repositório. Guarde a senha também no seu gerenciador de senhas: sem ela as cópias não podem ser lidas, e se ela só existir no servidor, morre com o servidor. Para SFTP, o root também precisa de uma chave SSH que a máquina de backup aceite (
sudo ssh-keygen -t ed25519e depois adicione/root/.ssh/id_ed25519.publá).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' -
Salve isto como
/usr/local/bin/backup-blossome torne-o executável (sudo chmod 700 /usr/local/bin/backup-blossom). MudeBLOSSOM_DIRse seus arquivos não estiverem em/root/blossom. Ele mantém os últimos 14 dias, 8 semanas e 12 meses. Os blocos nunca mudam, então 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 -
Rode-o uma vez à mão (
sudo /usr/local/bin/backup-blossom) e depois agende-o comsudo crontab -e. A segunda linha relê um décimo dos dados guardados a cada mês, um décimo diferente a cada vez, para provar que as cópias ainda podem ser abertas. Olhe o/var/log/backup-blossom.logde vez em quando: uma linha comFatalsignifica que a cópia daquela noite falhou. Se o backup do relay é feito na mesma máquina, estes horários não se sobrepõem aos 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 falha de disco):
configure o servidor de novo (passos 1 e 2) e repita os pontos 1 e 2 deste passo
com o mesmo repositório, mas escreva a senha que você guardou em
/root/.restic-blossom-password em vez de criar uma nova, e pule o restic init.
Depois copie o backup 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
Na próxima vez que verificar as cópias, o Drive encontra os blocos de volta e copia dos outros servidores o que tiver chegado depois do último backup. Testamos essa cadeia inteira em 27 de outubro de 2026: backup, servidor apagado, restauração, cada bloco relido com seu próprio hash, e apagado depois com a chave do Drive.
Uma vez por ano, faça essa restauração numa máquina reserva e confira se o servidor responde com seus blocos: é o único teste que prova a cadeia inteira, senha incluída.
Bom saber
- Só o seu Drive pode enviar. Qualquer um que saiba o endereço de um bloco pode baixá-lo, como em qualquer servidor Blossom, mas ele está criptografado: sem as chaves do seu Drive, é ruído.
- Se sua chave do volume mudar (o Drive avisa quando um volume é renovado),
adicione a nova como outra linha em
pubkeys, reinicie (docker compose up -d) e deixe a antiga lá. - Atualizações. Leia o registro de alterações,
mude a versão em
image:e rodedocker compose pulledocker compose up -d. - Seu endereço IP. O servidor vê o endereço de todo aplicativo que se conecta a ele, como qualquer servidor. No seu próprio servidor, o único que os vê é você.