Alojamiento propio

El servicio que hay detrás de Eidos online también se ejecuta en tu propio servidor, para un equipo que guarda la definición de su producto en sus propias manos. Un proyecto en él funciona como en Eidos online: la sincronización, los miembros, los niveles y las invitaciones, y el historial. Sus archivos, su historial y sus cuentas viven solo en tu servidor, y sus miembros inician sesión con las cuentas del propio servidor, nunca con Eidos online.

En fase temprana: lee esto primero

El servidor está listo para probarlo con un equipo pequeño, y todavía le falta parte de lo que necesita un servicio en producción:

• Sin paquete. Todavía no hay paquete npm, imagen de Docker ni unidad de servicio del sistema. El servidor se compila desde el código fuente de Eidos MD, como se explica abajo.
• Sin correo. El servidor todavía no puede enviar correos. Imprime cada código de inicio de sesión (--print-codes), y cada invitación por correo, en su propia salida, y quien lo ejecuta los pasa.

Qué necesitas

• Un equipo al que llegue tu equipo de trabajo, con macOS o Linux, con Node.js 22.5 o posterior y pnpm 11.
• git, y acceso al código fuente de Eidos MD.
• Para cualquier cosa más allá de una prueba en una sola red, un nombre de dominio y un proxy inverso que sirva HTTPS (abajo).
• Disco para tus proyectos. No hay más límite de almacenamiento que el tuyo.

Cada persona sigue usando la app de escritorio; el servidor es solo donde se encuentran sus proyectos.

Compilarlo y ejecutarlo

Descarga el código fuente, instala las dependencias del servicio y compílalo:

git clone https://gitlab.com/the-virtual-panda/eidosmd.git
cd eidosmd
pnpm install --frozen-lockfile --filter @eidosmd/service...
pnpm --filter @eidosmd/service build

Arráncalo con una carpeta para sus datos y el correo de su propietario:

node service/dist/src/serve.js --data ./eidos-data --owner [email protected] --print-codes

El propietario es la persona que ejecuta el servidor y tiene su licencia. El servidor necesita --owner en su primer arranque, y lo recuerda; arráncalo de nuevo con otro correo y el propietario cambia. El propietario inicia sesión en el servidor como cualquier otra persona, con ese correo.

Responde con dónde guarda sus datos y dónde escucha:

eidos service: /home/eidos/eidos-data
  http://127.0.0.1:6280  (sign-in at http://127.0.0.1:6280/api/auth)

En Node 22 también imprime un ExperimentalWarning sobre SQLite, donde se guardan las cuentas. Es inofensivo.

Cuando alguien inicia sesión, su código aparece en la misma salida:

sign-in code for [email protected]: 196907

Pásaselo, y lo escribe en el diálogo de inicio de sesión de la app como escribiría un código llegado por correo. Ctrl+C, o un SIGTERM de lo que lo esté ejecutando, detiene el servidor y cierra la conexión de cada app; cada app conserva sus cambios y los envía cuando el servidor vuelve.

Mantenlo en marcha

Todavía no se incluye ninguna unidad de systemd ni imagen de contenedor. Ejecuta el comando de arriba con el gestor de servicios que ya uses, con su directorio de trabajo en el checkout, y reinícialo si falla.

Configuración

Opción	Qué hace
--data <folder>	Obligatoria. La carpeta en la que el servidor lo guarda todo. Se crea si no existe.
--owner <email>	El correo de la cuenta que ejecuta el servidor y tiene su licencia. Obligatoria en el primer arranque; dada después, cambia el propietario.
--port <n>, -p <n>	El puerto en el que escucha. 6280 por defecto. El servidor escucha en todas las interfaces de red, así que mantén el puerto tras un cortafuegos cuando lo sirve un proxy.
--url <address>	La dirección a la que la gente llega al servidor, como https://eidos.example.com. Por defecto http://127.0.0.1:<port>. Tras un proxy tiene que ser la dirección del proxy: el inicio de sesión comprueba que las peticiones vienen de ella, y si no las rechaza.
--print-codes	Imprime cada código de inicio de sesión en la salida del servidor. Obligatoria por ahora, ya que el servidor todavía no tiene correo.
--web-origin <origin>	Confía en otro origen desde el que un navegador inicia sesión, como un sitio de cuentas que alojes tú. Repítela para varios. La mayoría de los servidores no la necesitan.
--licence-file <file>	Un archivo con la clave de licencia del servidor. La clave también puede venir de la variable de entorno EIDOS_LICENCE, o guardarse en Este servidor en la app. Consulta la licencia.
--database <address>	Guarda las cuentas, los proyectos y el historial en PostgreSQL, postgres://usuario:contraseña@host/base, en lugar de en la carpeta de datos. O EIDOS_DATABASE_URL. Consulta Almacenamiento.
--assets <where>	Guarda los archivos de recursos en una carpeta que elijas, un bucket compatible con S3 (s3://bucket) o un contenedor de Azure Blob Storage (azure://cuenta/contenedor), en lugar de en la carpeta de datos. O EIDOS_ASSETS_URL. Consulta Almacenamiento.

El secreto. Las sesiones se firman con un secreto. Ponlo en la variable de entorno EIDOS_SERVICE_SECRET, o déjala sin poner y el servidor crea uno en su primer arranque y lo guarda en secret en la carpeta de datos, legible solo por el usuario con el que se ejecuta. Consérvalo: un servidor arrancado con otro secreto cierra la sesión de todos los dispositivos, y cada uno dice Sincronización en pausa hasta que su persona vuelve a iniciar sesión.

Apple y Google. El inicio de sesión ofrece Continuar con Apple y Continuar con Google en cuanto sus claves están en el entorno del servidor, y solo códigos por correo hasta entonces. Para Google, pon EIDOS_GOOGLE_CLIENT_ID y EIDOS_GOOGLE_CLIENT_SECRET de un cliente web de Google Cloud cuyo URI de redirección sea <url>/api/auth/callback/google. Para Apple, pon EIDOS_APPLE_CLIENT_ID (un Services ID), EIDOS_APPLE_TEAM_ID, EIDOS_APPLE_KEY_ID y EIDOS_APPLE_PRIVATE_KEY (el texto del archivo .p8 de la clave de Sign in with Apple), con <url>/api/auth/callback/apple como URL de retorno del Services ID; Apple solo acepta una dirección HTTPS. El servidor firma él mismo el secreto de cliente de Apple con la clave, así que nunca hay que renovarlo. Una dirección usada con Apple o Google y por correo es una sola cuenta.

La carpeta de datos contiene:

accounts.sqlite	Las cuentas y sus sesiones.
projects/	Una carpeta por proyecto: los documentos en vivo de sus archivos, su historial, sus miembros y sus invitaciones.
secret	El secreto de las sesiones, cuando no está puesto en el entorno.
server.json	El propietario del servidor, el id que se creó en su primer arranque, su clave de licencia y la última respuesta a la comprobación de su licencia. Legible solo por el usuario con el que se ejecuta.

Almacenamiento

Por defecto, el servidor guarda todo en su carpeta de datos: las cuentas en un archivo SQLite, los proyectos y su historial como archivos, y los archivos de recursos en blobs/. Es todo lo que necesita un servidor en una sola máquina. Para el servidor de una empresa, puede guardarlos en tu propia infraestructura, cada parte elegida por separado:

Qué	Dónde	Cómo
Cuentas, proyectos, historial, planes y el estado de la licencia	La carpeta de datos (SQLite y archivos)	por defecto
	PostgreSQL	--database postgres://usuario:contraseña@host/base
Archivos de recursos (imágenes, PDF)	La carpeta de datos	por defecto
	Cualquier carpeta, como un recurso de red montado o Azure Files	--assets /srv/eidos-assets
	Un bucket compatible con S3: Amazon S3, Cloudflare R2, MinIO	--assets s3://bucket[/prefijo]
	Un contenedor de Azure Blob Storage	--assets azure://cuenta/contenedor[/prefijo]

PostgreSQL con los archivos de recursos en el disco del propio servidor:

EIDOS_SERVICE_SECRET=… node service/dist/src/serve.js --data ./eidos-data --owner [email protected] --url https://eidos.ejemplo.com --print-codes \
  --database postgres://eidos:…@db.ejemplo.com/eidos --assets /srv/eidos-assets

El servidor crea sus propias tablas en la base de datos, junto a las de las cuentas, la primera vez que arranca. Dale una base de datos propia.

Un bucket S3 toma AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY y AWS_REGION (us-east-1 si no se indica) del entorno, y EIDOS_S3_ENDPOINT para un servicio que no sea el de Amazon, como https://<cuenta>.r2.cloudflarestorage.com. Las claves tienen que poder leer, escribir y eliminar objetos en el bucket.

Un contenedor de Azure toma EIDOS_AZURE_SAS, una firma de acceso compartido para el contenedor (o la cuenta) con lectura, escritura y eliminación. Créala en el portal de Azure, en Firma de acceso compartido de la cuenta de almacenamiento, o con az storage container generate-sas, y dale una caducidad larga: el día que caduque, el servidor deja de poder leer y escribir sus recursos.

Al arrancar, el servidor comprueba cada almacenamiento escribiendo un archivo pequeño y quitándolo de nuevo. Una base de datos a la que no llega, o unas claves que no pueden escribir, lo detienen ahí, con un mensaje que nombra el almacenamiento y el motivo. Nunca imprime una contraseña ni una clave, y Este servidor en la app dice dónde se guarda cada parte.

Con los registros en PostgreSQL y los recursos en un bucket o un contenedor, el servidor no guarda en su propio disco nada que una copia de seguridad necesite. Indica el secreto con EIDOS_SERVICE_SECRET y puedes omitir --data: una máquina nueva arrancada con la misma base de datos, los mismos recursos y el mismo secreto es el mismo servidor, con sus cuentas, proyectos y licencia. Un servidor sigue siendo un solo proceso: ejecuta uno a la vez contra una base de datos.

HTTPS y un proxy inverso

El servidor habla HTTP plano. Ponlo tras un proxy inverso que sirva HTTPS, deje pasar las conexiones WebSocket y reenvíe al puerto del servidor, y arranca el servidor con --url puesto en la dirección que usa la gente.

node service/dist/src/serve.js --data ./eidos-data --owner [email protected] --url https://eidos.example.com --print-codes

Con Caddy, que obtiene y renueva el certificado por su cuenta y deja pasar los WebSockets por defecto, el Caddyfile entero es:

eidos.example.com {
  reverse_proxy 127.0.0.1:6280
}

Con nginx, lo que importa son las cabeceras de WebSocket y un tiempo de lectura largo; el certificado lo pones tú:

server {
    listen 443 ssl;
    server_name eidos.example.com;
    ssl_certificate     /etc/ssl/eidos.example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/eidos.example.com/privkey.pem;

    client_max_body_size 100m;

    location / {
        proxy_pass http://127.0.0.1:6280;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 1h;
    }
}

client_max_body_size es el tamaño de un archivo de assets, una imagen o un PDF, que el proxy deja pasar. Sirve el servidor en la raíz de su nombre de host: una dirección con una ruta detrás, como https://example.com/eidos, no está admitida.

Apuntar la app a tu servidor

En la app de escritorio, abre el diálogo de inicio de sesión (Iniciar sesión en el menú de la cuenta al pie de la barra de actividad, o Añadir una cuenta cuando ya has iniciado sesión), luego Usar un servidor propio, y escribe la dirección del servidor.

A un nombre de host solo, eidos.example.com, se llega por HTTPS; a localhost y 127.0.0.1, por HTTP. Para una prueba en tu propia red sin HTTPS, escribe la dirección entera, http://192.168.1.20:6280, y arranca el servidor con el mismo --url. La cuenta es la del propio servidor, distinta de cualquiera en Eidos online, y la app tiene las dos una junto a otra.

A partir de ahí todo funciona como en Eidos online: la primera persona que activa la sincronización de una carpeta es la propietaria del proyecto e invita al resto, cuyos enlaces apuntan a tu servidor.

Copias de seguridad

Todo lo que tiene el servidor está en su carpeta de datos, salvo que lo guarde en PostgreSQL o en un bucket (Almacenamiento): entonces haz la copia de la base de datos y del bucket con sus propias herramientas, y guarda el secreto con ellas. Para la carpeta de datos: Para hacer una copia de seguridad, detén el servidor, copia la carpeta (con secret, o apunta EIDOS_SERVICE_SECRET junto a ella) y vuelve a arrancarlo. Mientras está detenido, la gente sigue trabajando y sus cambios esperan en sus equipos; se envían cuando vuelve.

Para restaurar, detén el servidor, pon la carpeta copiada en lugar de la carpeta de datos y arráncalo con el mismo secreto. Los cambios hechos en los equipos de la gente desde la copia se vuelven a enviar según cada app se reconecta. La carpeta de cada miembro es además una copia completa de lo que se comparte con él.

Actualizaciones

En el checkout, toma el código fuente nuevo, compílalo y reinicia el servidor:

git pull
pnpm install --frozen-lockfile --filter @eidosmd/service...
pnpm --filter @eidosmd/service build

Después reinícialo. La base de datos de cuentas pone al día sus propias tablas cuando arranca el servidor. Mantén el servidor y las apps de escritorio de tu equipo en versiones de la misma época: todavía no está escrito con qué versiones de la app funciona cada servidor.

La licencia

Hasta tres editores, un servidor es gratis, sin licencia y sin cuenta de Eidos. Sus lectores y comentaristas son gratis y sin límite, y también los agentes, que trabajan con el acceso de la persona para la que actúan. Un editor es cualquiera que puede editar al menos uno de los proyectos del servidor, contado una vez por muchos que edite, también el propietario cuando edita.

A partir de un cuarto editor, una licencia cubre a todos los editores, no solo a los que pasan de tres: un equipo de cuatro necesita cuatro puestos, y diez puestos cubren a diez editores.

Más allá de lo que cubre el servidor (un cuarto editor sin licencia, más editores que puestos, o 30 días sin respuesta de Eidos), los editores añadidos más recientemente esperan, como un puesto caducado en Eidos online: siguen editando en sus propios equipos, sus cambios esperan ahí, contados en el widget de sincronización, y leen y comentan como antes. Nada se bloquea ni se quita, y sus cambios se envían cuando el servidor los cubre.

Este servidor, en Settings de la app de escritorio, es la página del propietario para todo ello, visible mientras tiene la sesión iniciada en el servidor: la licencia (Licencia para 10 editores, o Gratis, tres editores), la clave, cuándo comprobó el servidor por última vez, y sus editores, cuántos están cubiertos, y Cambiar para elegir quiénes. Con cuatro editores y sin licencia, lo dice: cuatro editores, tres de ellos gratis, así que el servidor necesita cuatro puestos, y hasta entonces los editores añadidos más recientemente esperan.

Comprar una licencia

Una licencia es un puesto para cada editor de un servidor, al precio de un puesto de Eidos online: 4,99 $ al mes o 49,90 $ al año cada uno, así que cuatro puestos son 19,96 $ al mes o 199,60 $ al año, y diez son 49,90 $ al mes o 499,00 $ al año. Se compra con Licenciar un servidor, en Servidores, dentro de Plan y facturación en el sitio de tu cuenta (Licenciar este servidor en Este servidor lo abre), a partir de cuatro puestos, ya que tres o menos no cubren nada que el servidor no tenga gratis. Cambiar después los puestos de un servidor pasa de cuatro directamente a ninguno, lo que termina la licencia: el servidor vuelve a ser gratis para tres editores, y no se quita nada. La clave de licencia, que empieza por eidos_srv_, se muestra una sola vez cuando se compran los puestos, con Copiar. En Servidores, Cambiar puestos los cambia, Crear una clave nueva sustituye la clave (la anterior sigue durante sus 30 días) y Liberar suelta la clave del servidor que la tiene, para un servidor que se retira.

Dale al servidor su clave en Este servidor (Clave de licencia y luego Guardar, que la comprueba al momento), o con --licence-file <file> o la variable de entorno EIDOS_LICENCE cuando arranca.

Qué le cuenta el servidor a Eidos

El servidor comprueba su licencia cuando arranca, una vez al día, al pulsar Comprobar ahora y cuando su número de editores pasa de lo que cubre. Una comprobación envía la clave, el id propio del servidor, un número de un solo uso y cuántos editores cuenta: nunca un proyecto, un archivo ni un miembro. Un servidor sin clave no envía nada.

Cuando no puede llegar a Eidos, el servidor sigue con su última respuesta durante 30 días, y Este servidor dice hasta cuándo. Tras 30 días sin respuesta vuelve a tres editores gratis, sin quitar nada, hasta que una respuesta vuelva a cubrir a todos. Una clave que ya está en uso en otro servidor ofrece Moverla aquí; una clave que se sustituyó sigue hasta que acaban sus 30 días, y una licencia que terminó devuelve el servidor a tres editores gratis.

Una licencia por acuerdo

Una empresa con un acuerdo con Eidos puede recibir una licencia en lugar de comprar puestos: cubre a todos los editores, no tiene fecha de fin y nunca se cobra. Solo Eidos la emite. Es una clave, como una comprada, que empieza por eidos_srv_, y aparece en Servidores en la cuenta a la que se concede, marcada Por acuerdo. Dásela al servidor igual: pégala en Este servidor y pulsa Guardar, o arranca el servidor con --licence-file <archivo> o EIDOS_LICENCE. Este servidor dice entonces Con licencia por acuerdo · editores ilimitados, con a quién se concedió.

Se comprueba como cualquier licencia, una vez al día, enviando las mismas pocas cosas, así que el servidor tiene que llegar a online.eidosmd.com para tomarla. Después, que Eidos no responda nunca la termina: el servidor sigue con ella por mucho que la comprobación quede sin respuesta. Guarda la clave como cualquier secreto: quien la tenga puede mover la licencia a su propio servidor.

Pruebas contra staging

Para quienes contribuyen a Eidos, nunca para el servidor de un equipo: un servidor puede comprobarse contra el servicio de staging de Eidos, cuyas respuestas firma una clave de prueba en la que ninguna versión confía. Arráncalo con --licence-service https://online-staging.eidosmd.com --trust-key eidos-staging-1=bxl5sumIh6dS9EkTok18mLz_hIvyzE1ppdRsDQUiM2k (o EIDOS_TRUST_KEYS), y al arrancar dice que confía en una clave de licencia de prueba. Sin esas opciones, un servidor confía solo en la clave de Eidos.