Ser dueño de su identidad Bluesky
La portabilidad del protocolo AT se basa en una separación estricta entre el DID (Decentralized Identifier), el PDS que almacena sus datos y el relayer de la red. Su DID doc, firmado criptográficamente por su servidor, enumera las claves de firma y el punto de entrada del servicio que aloja su repositorio. Cambiar de PDS actualiza ese documento sin modificar el DID en sí: sus seguidores no ven nada, sus enlaces de perfil siguen siendo válidos y su handle no cambia.
Mientras delegue ese alojamiento en bsky.social, la portabilidad sigue siendo teórica. Migrarla a un VPS que usted administra la hace efectiva: usted controla las claves, usted decide las reglas de registro, y ninguna decisión de política externa puede privarle de su repositorio de publicaciones.
Ventajas de un PDS autoalojado
- Su handle de Bluesky pasa a ser un subdominio de su propio dominio, por ejemplo
usuario.su-dominio.com. - Sus publicaciones, likes y follows se almacenan en un repositorio firmado criptográficamente en su servidor — usted es su único propietario.
- Si bsky.social cambia de política, una migración no cuesta ni un seguidor ni una publicación: el protocolo AT transfiere el repositorio íntegro.
- Usted gestiona la lista de cuentas admitidas mediante un sistema de códigos de invitación: una instancia estrictamente personal sigue siendo posible.
- Watchtower vigila la imagen del PDS y lanza las actualizaciones automáticamente, sin intervención manual.
- Caddy gestiona el TLS y la renovación de los certificados, incluido el wildcard DNS que exigen los handles en subdominio.
- El consumo de memoria en reposo ronda los 512 MB: compatible con la mayoría de los VPS de gama de entrada.
- El código se publica bajo licencia MIT en github.com/bluesky-social/pds; no existe ninguna edición empresarial de pago.
Requisitos con cifras
Un VPS con al menos 512 MB de RAM y 1 vCPU basta para un uso personal (de una a cinco cuentas). Prevea 20 GB de almacenamiento SSD como mínimo para los medios y el historial de publicaciones. Para un uso asociativo con una decena de cuentas, 1 GB de RAM y 40 GB de almacenamiento ofrecen más margen.
En cuanto a la red, los puertos 80 y 443 deben ser alcanzables desde el exterior. El PDS mantiene una conexión WebSocket persistente hacia la red Bluesky: asegúrese de que su firewall no corta las conexiones largas inactivas.
DNS: es indispensable un registro A wildcard *.su-dominio.com que apunte a la IP de su VPS. Permite que cada handle en subdominio se resuelva sin necesidad de una entrada DNS distinta por cuenta. Si su registrador no soporta los wildcards, la configuración manual de un handle mediante un registro TXT _atproto.su-dominio.com sigue siendo posible, pero más incómoda.
Software necesario: Docker y Docker Compose v2. No hace falta ninguna otra dependencia; el Compose oficial incluye Caddy, Watchtower y el PDS en una red interna aislada.
Instalación paso a paso
Clonar el repositorio oficial
Conéctese por SSH a su VPS y clone el repositorio de referencia. La rama
maines la rama estable recomendada por los mantenedores:git clone https://github.com/bluesky-social/pds /opt/pds. Entre después en el directorio concd /opt/pds.Crear el archivo de entorno
Copie el ejemplo incluido en el repositorio:
cp .env.example .env.Informe como mínimo
PDS_HOSTNAME(su dominio raíz, sin el wildcard, p. ej.su-dominio.com),PDS_JWT_SECRETyPDS_ADMIN_PASSWORD. Genere valores aleatorios robustos:openssl rand -hex 32produce una cadena de 64 caracteres suficiente para cada uno de los dos secretos.Configurar el DNS wildcard
En la interfaz de su registrador o de Cloudflare, cree un registro A
*.su-dominio.comque apunte a la dirección IP de su VPS.La propagación tarda en general unos minutos, a veces hasta 24 h. Compruébelo con
dig +short test.su-dominio.com @1.1.1.1antes de pasar al paso siguiente: si la respuesta está vacía, espere.Arrancar los servicios
El Compose oficial arranca el PDS, Caddy y Watchtower con un solo comando:
docker compose up -d.Caddy obtiene automáticamente el certificado TLS para
su-dominio.comy*.su-dominio.com. Siga los logs condocker compose logs -f caddypara confirmar que el challenge ha funcionado antes de crear la primera cuenta.Crear la primera cuenta
La imagen del PDS expone un comando de administración en línea. Cree su cuenta:
docker compose exec pds /pds/bin/create-account --handle usuario.su-dominio.com --email [email protected] --password <contrasena>.Abra la aplicación Bluesky, elija «Servidor personalizado» (dirección:
https://su-dominio.com), introduzca el código de invitación devuelto y finalice la creación de la cuenta.Verificar la instalación
Abra
https://su-dominio.com/xrpc/com.atproto.server.describeServeren un navegador.La respuesta JSON confirma que su PDS es accesible y que el TLS es válido. Busque después
@usuario.su-dominio.comen la aplicación Bluesky para comprobar que el handle se resuelve correctamente.
Configuración posterior a la instalación
Códigos de invitación. Por defecto, los registros están cerrados: solo las cuentas creadas con un código de invitación pueden unirse a su PDS. Genere códigos adicionales con docker compose exec pds /pds/bin/create-invite-code. Para un uso estrictamente personal, esta restricción es la configuración recomendada.
Vigilancia con Watchtower. Watchtower ya está en el Compose oficial y vigila la imagen del PDS. En cuanto se publica una nueva versión en el registro de imágenes, descarga la imagen y reinicia el servicio, sin intervención por su parte. Para recibir una notificación en cada actualización, añada [email protected] en el archivo .env.
Copias de seguridad. El directorio data/ (configurable mediante PDS_DATA_DIRECTORY) contiene la base SQLite y los medios. Programe una copia de seguridad periódica: el directorio es coherente en frío si detiene los servicios con docker compose stop antes de copiarlo.
Endurecimiento recomendado
Añada PDS_REGISTRATION_DISABLED=true en .env para exigir un código de invitación en cualquier registro. Reinicie el PDS con docker compose restart pds tras la modificación.
Pruebe con regularidad la restauración de sus copias de seguridad arrancando un PDS efímero en un segundo directorio: una copia de seguridad no probada no es una copia de seguridad. Una base SQLite corrupta sin una restauración válida significa la pérdida de todas las publicaciones.
Resolución de problemas frecuentes
DNS no propagado. Si Caddy no consigue obtener el certificado, docker compose logs caddy muestra failed to obtain certificate. Compruebe la resolución del wildcard con dig *.su-dominio.com @1.1.1.1: una respuesta vacía indica que la entrada DNS aún no existe o aún no se ha propagado.
Error de certificado (puertos bloqueados). Si el registro DNS existe pero el challenge TLS-ALPN falla, es probable que un firewall esté bloqueando el puerto 80 o el 443. En un VPS con ufw, revise ufw status y autorice ambos puertos: ufw allow 80/tcp && ufw allow 443/tcp.
Migración de DID fallida. Si la aplicación Bluesky devuelve un error durante la migración, confirme que su PDS responde desde el exterior (endpoint describeServer más arriba). La migración contacta con su servidor desde los servidores de bsky.social: un timeout indica un problema de red o un certificado no válido.
Handle no resuelto. Si @usuario.su-dominio.com no se resuelve en la aplicación Bluesky, compruebe que el wildcard DNS está bien propagado y que el endpoint /.well-known/atproto-did de su handle responde con el DID correcto (curl https://usuario.su-dominio.com/.well-known/atproto-did).
Para ir más lejos
Un PDS autoalojado se integra de forma natural en una infraestructura Docker ya existente. La guía sobre el despliegue con Caddy cubre los casos más avanzados de reverse proxy multiservicio en el mismo VPS. Si además desea alojar su forja Git, la guía Forgejo en VPS sigue el mismo modelo Compose. Para asegurar el acceso de administrador a sus servicios autoalojados sin exponerlos directamente a internet, la guía Headscale/Tailscale en VPS propone una alternativa a un bastión SSH.
