Montar tu propio servidor de retransmisión

Móntalo

docker run -p 8000:8000 ghcr.io/akshaynikhare/realtimeclipboard-relay

O desde un clon, sin contenedor ninguno:

pip install -r backend/requirements.txt
python -m uvicorn main:app --app-dir backend --port 8000

Eso es el servidor de retransmisión entero. Sin base de datos, sin volumen, sin paso de migración y sin nada de lo que hacer copia de seguridad — cada sesión vive en memoria y desaparece cuando el proceso termina, que es el diseño y no una limitación.

Comprueba que funcionó

curl http://localhost:8000/health

Responde con el identificador de la instancia. Ese campo no es decoración: es como un cliente puede saber que lo han balanceado a otra réplica a mitad de sesión, que es el fallo con el que este diseño tiene que andarse con cuidado — mira la sección de réplicas más abajo.

Apunta la aplicación a él

1. Abre la aplicación y ve a Ajustes → Servidor de retransmisión.
2. Escribe la URL de tu servidor — ws://localhost:8000 para una prueba local, wss://clip.example.com para uno de verdad.
3. La barra de estado pone Conectado en cuanto responde. Haz lo mismo en un segundo dispositivo y sincroniza un contenido entre ambos; nada ha tocado el servidor público.

El cliente de línea de comandos acepta --relay o REALTIMECLIPBOARD_RELAY para lo mismo.

TLS y un nombre de dominio de verdad

cd deploy
REALTIMECLIPBOARD_DOMAIN=clip.example.com docker compose up -d

El directorio deploy tiene un archivo compose que pone Caddy delante del servidor de retransmisión y obtiene el certificado automáticamente, y al lado un chart de Helm para Kubernetes.

En la práctica, TLS no es opcional. Los navegadores solo exponen crypto.subtle en un contexto seguro, así que una página servida por HTTP plano en una dirección de red local no puede ni derivar una clave — la aplicación no puede funcionar ahí, haga lo que haga el servidor de retransmisión.

Antes de escalarlo

Fija las réplicas en una, o dale un Redis. Una sala vive en la memoria del proceso que la atiende, así que dos réplicas detrás de un balanceador round-robin dejan las dos mitades de una sesión en máquinas distintas y ninguna ve a la otra. Se manifiesta como contenido que sencillamente no llega, lo que parece un fallo del cliente y no lo es. El chart de Helm rechaza replicaCount > 1 sin Redis precisamente por esto. Las notas de autoalojamiento cubren las variables de entorno y la vía de alta disponibilidad al completo.

Cuando no funciona

Conectado, pero el contenido nunca llega

Casi siempre más de una réplica sin estado compartido — mira arriba. Compara el identificador de /health desde cada dispositivo: si difieren, ahí está toda la respuesta.

La aplicación no lo alcanza en absoluto

Dos candidatos. La Content-Security-Policy de la propia página enumera los orígenes de retransmisión a los que puede conectarse, así que una copia autoalojada del sitio estático necesita connect-src actualizado en index.html, en app.html y en cada página bajo src/pages/. Y si estás usando el sitio alojado con tu propio servidor, la política de allí no lo va a permitir — autoaloja las dos mitades.

Conecta y se cae, una y otra vez

Un proxy inverso que no reenvía las actualizaciones de WebSocket. El cliente cae entonces a server-sent events más POST y sigue funcionando, más despacio, que es por lo que esto aparece como lentitud y no como fallo. Reenvía Upgrade y Connection.

Una sesión inactiva desaparece

Las salas se recogen cuando quedan vacías. Es deliberado — un servidor de retransmisión que no guarda nada no tiene nada que filtrar.

Apagarlo

docker compose down            # or: docker rm -f <container>

No hay datos que borrar. Todo lo que el servidor de retransmisión guardó estaba en memoria, y era texto cifrado.

Las notas operativas completas, con la tabla de variables de entorno y la vía de alta disponibilidad: docs/SELF-HOSTING.md. Todas las plataformas: la guía de instalación. ¿Algo mal o desactualizado aquí? Abre una incidencia.