Tu propio servidor Blossom

Última actualización: 27 de octubre de 2026

Herkos Drive corta cada archivo en bloques cifrados y los guarda en varios servidores Blossom: tres copias, en al menos dos tipos de servidor, y una en un servidor tuyo. Los servidores públicos guardan bloques gratis, pero no prometen nada: pueden purgarlos, llenarse o cerrar.

Un servidor Blossom tuyo guarda tu copia el tiempo que tú decidas y solo acepta bloques de tu Drive. Esta página explica cómo montarlo en tres pasos, más una copia de seguridad cada noche. Combina bien con tu propio relay de correo, y si ya tienes un servidor, son unos quince minutos.

Qué servidor usar

blossom-server de hzrd149, versión 6.4.1 (6 de octubre de 2026, licencia MIT). El 27 de octubre de 2026 lo pusimos en marcha con la configuración de abajo y el propio código de subida de Drive, y comprobamos lo que necesita Drive, no lo que anuncia el servidor:

Qué necesitas

• Una máquina siempre encendida y accesible desde internet: un VPS pequeño o un ordenador en casa. Necesita tanto disco como ocupe tu Drive, y algo de margen para crecer.
• Un dominio o subdominio que apunte a ella, por ejemplo blossom.example.com.
• Docker y un proxy inverso que ponga HTTPS. Los ejemplos usan Caddy, que consigue el certificado solo.
• La clave del volumen de tu Drive. Herkos Drive la muestra en Ajustes → Servidores → Tu servidor personal, como 64 letras y cifras. No es la clave de tu perfil: Drive nunca sube con la clave de tu perfil, así que un servidor que solo acepte tu npub rechazaría a Drive.

Paso 1: arrancar el servidor

Crea una carpeta para él, por ejemplo /root/blossom, y guarda en ella estos dos archivos. El primero es 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: {}

El segundo es config.yml. Pon tu dominio en publicDomain y tu clave del volumen donde dice 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

Lo que dice: solo tu clave del volumen puede subir o pedir copias (requirePubkeyInRule), y un bloque se guarda hasta que Drive lo borra. El servidor exige una caducidad en cada regla; 100 years sin leerse es, en la práctica, nunca, y de todos modos Drive lee sus bloques con regularidad. El puerto solo escucha en la propia máquina (127.0.0.1): todo pasa por el proxy. Arráncalo:

cd /root/blossom
docker compose up -d

Paso 2: ponerle HTTPS delante

Con Caddy, la configuración entera (/etc/caddy/Caddyfile) es:

blossom.example.com {
    reverse_proxy 127.0.0.1:3000
}

Si el mismo Caddy ya sirve tu relay, añade este bloque debajo del suyo. Recarga Caddy (sudo systemctl reload caddy). Al abrir https://blossom.example.com en el navegador ya debería responder, con un 404: no hay página de inicio, a propósito.

Paso 3: decírselo a Herkos Drive

1. En Herkos Drive, abre Ajustes → Servidores, añade https://blossom.example.com y márcalo como tuyo.
2. Drive le pregunta antes de cada subida. Desde entonces, cada archivo nuevo tiene una copia allí, y los que ya tenías reciben la suya la próxima vez que Drive compruebe las copias.
3. Deja los demás servidores en la lista. El tuyo es una de las tres copias, nunca la única: si se cae, tus archivos siguen en los otros, y Drive te avisa tras una semana de silencio.

Paso 4: copia de seguridad cada noche

Si tu servidor muere, Drive lo nota y da a los archivos afectados copias en los otros servidores de tu lista. Pero la copia de tu servidor es la única que no depende de nadie más, y una copia cada noche te deja rehacerla sin volver a copiarlo todo por internet.

El servidor lo guarda todo dentro del volumen de Docker blossom_data (el nombre empieza por la carpeta donde están los archivos; compruébalo con docker volume ls): los bloques, un fichero cada uno, y una pequeña base de datos SQLite que dice quién subió cada uno. Los bloques no cambian nunca, pero la base de datos no debe copiarse mientras se escribe en ella. Así que el script lo copia todo con el servidor en marcha, lo para los pocos segundos que tarda en copiar lo que cambió entretanto, lo vuelve a arrancar y solo entonces sube la copia. Mientras está parado, Drive simplemente vuelve a intentarlo un poco más tarde.

La copia sale del servidor con restic, que la cifra antes de enviarla. Llévala a un sitio de otro proveedor, no el del servidor: una cuenta SFTP (un storage box, un ordenador en casa) o un bucket compatible con S3. Si ya haces así la copia de tu relay, usa el mismo sitio con otra carpeta.

1. Instala las herramientas y crea el repositorio. Guarda también la contraseña en tu gestor de contraseñas: sin ella las copias no se pueden leer, y si solo vive en el servidor, se pierde con él. Con SFTP, root necesita además una clave SSH que acepte la máquina de copias (sudo ssh-keygen -t ed25519, y añadir allí /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. Guarda esto como /usr/local/bin/backup-blossom y hazlo ejecutable (sudo chmod 700 /usr/local/bin/backup-blossom). Cambia BLOSSOM_DIR si tus archivos no están en /root/blossom. Conserva los últimos 14 días, 8 semanas y 12 meses. Los bloques no cambian nunca, así que cada noche solo añade lo nuevo.

   #!/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. Ejecútalo una vez a mano (sudo /usr/local/bin/backup-blossom) y prográmalo con sudo crontab -e. La segunda línea vuelve a leer cada mes una décima parte de lo guardado, cada vez una distinta, para comprobar que las copias se siguen pudiendo abrir. Mira de vez en cuando /var/log/backup-blossom.log: una línea con Fatal quiere decir que la copia de esa noche falló. Si la copia del relay se hace en la misma máquina, estas horas no coinciden con las suyas.

   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 (un servidor nuevo, o tras perder el disco): vuelve a montar el servidor (pasos 1 y 2) y repite los puntos 1 y 2 de este paso con el mismo repositorio, pero escribe en /root/.restic-blossom-password la contraseña que guardaste en vez de crear una nueva, y sáltate restic init. Después copia la última copia en el volumen del 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

La próxima vez que compruebe las copias, Drive vuelve a encontrar los bloques y copia desde los otros servidores lo que llegó después de la última copia. El 27 de octubre de 2026 probamos toda esta cadena: copia, servidor borrado, restauración, cada bloque releído con su propio hash, y borrado después con la clave de Drive.

Una vez al año, haz esta restauración en una máquina de repuesto y comprueba que el servidor responde con tus bloques: es la única prueba que demuestra toda la cadena, contraseña incluida.

Conviene saber

• Solo tu Drive puede subir. Cualquiera que conozca la dirección de un bloque puede descargarlo, como en cualquier servidor Blossom, pero está cifrado: sin las claves de tu Drive es ruido.
• Si cambia tu clave del volumen (Drive te avisa cuando se renueva un volumen), añade la nueva como otra línea bajo pubkeys, reinicia (docker compose up -d) y deja la antigua donde está.
• Actualizaciones. Lee el registro de cambios, cambia la versión en image: y ejecuta docker compose pull y docker compose up -d.
• Tu dirección IP. El servidor ve la dirección de cada app que se conecta, como cualquier servidor. En tu propio servidor, el único que las ve eres tú.