Votre propre serveur Blossom

Dernière mise à jour : 27 octobre 2026

Herkos Drive découpe chaque fichier en blocs chiffrés et les conserve sur plusieurs serveurs Blossom : trois copies, sur au moins deux types de serveur, et une sur un serveur à vous. Les serveurs publics gardent les blocs gratuitement, mais ils ne promettent rien : ils peuvent les purger, se remplir ou fermer.

Un serveur Blossom à vous garde votre copie aussi longtemps que vous le décidez et n'accepte de blocs que de votre Drive. Cette page explique comment en mettre un en place en trois étapes, plus une sauvegarde chaque nuit. Il va bien avec votre propre relais boîte aux lettres, et il faut compter environ un quart d'heure si vous avez déjà un serveur.

Quel serveur utiliser

blossom-server de hzrd149, version 6.4.1 (6 octobre 2026, licence MIT). Nous l'avons fait tourner le 27 octobre 2026 avec la configuration ci-dessous et le code d'envoi de Drive lui-même, et vérifié ce dont Drive a besoin, pas ce que le serveur annonce :

Ce qu'il vous faut

• Une machine toujours allumée et joignable depuis Internet : un petit VPS ou un ordinateur chez vous. Il lui faut autant de disque que ce que contient votre Drive, plus un peu de marge pour grandir.
• Un domaine ou sous-domaine qui pointe vers elle, par exemple blossom.example.com.
• Docker et un proxy inverse qui fournit le HTTPS. Les exemples utilisent Caddy, qui obtient le certificat tout seul.
• La clé de volume de votre Drive. Herkos Drive l'affiche dans Paramètres → Serveurs → Ton propre serveur, sous forme de 64 lettres et chiffres. Ce n'est pas la clé de votre profil : Drive ne téléverse jamais avec la clé de votre profil, donc un serveur qui n'accepte que votre npub refuserait Drive.

Étape 1 : lancer le serveur

Créez un dossier pour lui, par exemple /root/blossom, et enregistrez-y ces deux fichiers. Le premier est 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: {}

Le second est config.yml. Mettez votre domaine dans publicDomain et votre clé de volume à la place de 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

Ce que cela dit : seule votre clé de volume peut téléverser ou demander des copies (requirePubkeyInRule), et un bloc est gardé jusqu'à ce que Drive le supprime. Le serveur exige une expiration dans chaque règle ; 100 years sans être lu, c'est jamais en pratique, et de toute façon Drive relit ses blocs régulièrement. Le port n'écoute que sur la machine elle-même (127.0.0.1) : tout passe par le proxy. Démarrez-le :

cd /root/blossom
docker compose up -d

Étape 2 : mettre le HTTPS devant

Avec Caddy, toute la configuration (/etc/caddy/Caddyfile) tient en :

blossom.example.com {
    reverse_proxy 127.0.0.1:3000
}

Si le même Caddy sert déjà votre relais, ajoutez ce bloc sous celui du relais. Rechargez Caddy (sudo systemctl reload caddy). En ouvrant https://blossom.example.com dans un navigateur, vous devriez maintenant obtenir une réponse, avec un 404 : il n'y a pas de page d'accueil, c'est voulu.

Étape 3 : l'indiquer à Herkos Drive

1. Dans Herkos Drive, ouvrez Paramètres → Serveurs, ajoutez https://blossom.example.com et marquez-le comme le vôtre.
2. Drive l'interroge avant chaque envoi. À partir de là, chaque nouveau fichier y reçoit une copie, et les fichiers que vous aviez déjà reçoivent la leur la prochaine fois que Drive vérifie les copies.
3. Gardez les autres serveurs dans la liste. Le vôtre est l'une des trois copies, jamais la seule : s'il tombe en panne, vos fichiers sont toujours sur les autres, et Drive vous prévient après une semaine de silence.

Étape 4 : le sauvegarder chaque nuit

Si votre serveur meurt, Drive s'en aperçoit et donne aux fichiers concernés des copies sur les autres serveurs de votre liste. Mais la copie sur votre serveur est la seule qui ne dépend de personne d'autre, et une sauvegarde nocturne vous permet de la reconstruire sans tout recopier par Internet.

Le serveur garde tout dans le volume Docker blossom_data (le nom commence par le dossier dans lequel se trouvent les fichiers ; vérifiez-le avec docker volume ls) : les blocs, un fichier chacun, et une petite base de données SQLite qui indique qui a téléversé chacun d'eux. Les blocs ne changent jamais, mais la base de données ne doit pas être copiée pendant qu'on y écrit. Le script copie donc tout avec le serveur en marche, l'arrête pendant les quelques secondes que prend la copie de ce qui a changé entre-temps, le redémarre, et seulement ensuite téléverse la copie. Pendant l'arrêt, Drive réessaie simplement un peu plus tard.

La copie quitte le serveur avec restic, qui la chiffre avant qu'elle ne parte. Utilisez un emplacement chez un autre fournisseur que celui du serveur : un compte SFTP (une storage box, un ordinateur chez vous) ou un bucket compatible S3. Si vous sauvegardez déjà votre relais de cette façon, utilisez le même emplacement avec un autre dossier.

1. Installez les outils et créez le dépôt. Gardez aussi le mot de passe dans votre gestionnaire de mots de passe : sans lui, les copies sont illisibles, et s'il ne vit que sur le serveur, il meurt avec le serveur. Pour SFTP, root a aussi besoin d'une clé SSH acceptée par la machine de sauvegarde (sudo ssh-keygen -t ed25519, puis ajoutez-y /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. Enregistrez ceci sous /usr/local/bin/backup-blossom et rendez-le exécutable (sudo chmod 700 /usr/local/bin/backup-blossom). Modifiez BLOSSOM_DIR si vos fichiers ne sont pas dans /root/blossom. Il conserve les 14 derniers jours, 8 semaines et 12 mois. Les blocs ne changent jamais, donc chaque nuit n'ajoute que ce qui est nouveau.

   #!/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. Lancez-le une fois à la main (sudo /usr/local/bin/backup-blossom), puis planifiez-le avec sudo crontab -e. La deuxième ligne relit chaque mois un dixième des données stockées, un dixième différent à chaque fois, pour prouver que les copies peuvent toujours être ouvertes. Jetez un œil de temps en temps à /var/log/backup-blossom.log : une ligne contenant Fatal signifie que la copie de cette nuit-là a échoué. Si le relais est sauvegardé sur la même machine, ces horaires ne chevauchent pas les siens.

   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
   

Pour restaurer (un nouveau serveur, ou après une panne de disque) : remettez le serveur en place (étapes 1 et 2) et refaites les points 1 et 2 de cette étape avec le même dépôt, mais écrivez le mot de passe que vous avez conservé dans /root/.restic-blossom-password au lieu d'en créer un nouveau, et sautez restic init. Copiez ensuite la dernière sauvegarde dans le volume du serveur :

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

La prochaine fois qu'il vérifie les copies, Drive retrouve les blocs et recopie depuis les autres serveurs tout ce qui est arrivé après la dernière sauvegarde. Nous avons essayé toute cette chaîne le 27 octobre 2026 : sauvegarde, serveur supprimé, restauration, chaque bloc relu avec son propre hash, puis supprimé avec la clé de Drive.

Une fois par an, faites cette restauration sur une machine de rechange et vérifiez que le serveur répond avec vos blocs : c'est le seul test qui prouve toute la chaîne, mot de passe compris.

Bon à savoir

• Seul votre Drive peut téléverser. Quiconque connaît l'adresse d'un bloc peut le télécharger, comme sur tout serveur Blossom, mais il est chiffré : sans les clés de votre Drive, ce n'est que du bruit.
• Si votre clé de volume change (Drive vous prévient quand un volume est renouvelé), ajoutez la nouvelle sur une ligne de plus sous pubkeys, redémarrez (docker compose up -d), et laissez l'ancienne en place.
• Mises à jour. Lisez le journal des modifications, changez la version dans image:, puis lancez docker compose pull et docker compose up -d.
• Votre adresse IP. Le serveur voit l'adresse de chaque application qui s'y connecte, comme tout serveur. Sur votre propre serveur, la seule personne qui les voit, c'est vous.