Antes de empezar

Cuatro cosas. Tres de ellas solo tú las puedes aportar.

La máquina

Ubuntu 26.04 LTS es para lo que está ajustado el instalador; cualquier cosa desde 22.04 funciona. 2 vCPU, 4 GB de RAM, al menos 20 GB de disco.

3,7 GB de RAM está bien — el instalador aprovisiona un archivo de intercambio de 4 GB. Por debajo de eso, las construcciones de superficies fallan: una construcción que muere con la señal 137 es la máquina quedándose sin memoria. El nodo se instala y se ejecuta igualmente cuando falla la construcción de una superficie; solo se salta ese portal, y volver a ejecutar la instalación lo reintenta.

El perfil de 4 GB ejecuta la base de datos, la autenticación, REST, las funciones de borde, la puerta de enlace, el almacenamiento y el tiempo real. Studio, la analítica, el proxy de imágenes y el agrupador de conexiones están desactivados por defecto.

No necesitas instalar Docker, Node.js ni pnpm tú mismo. El preflight de la instalación lo hace, y configura el cortafuegos para permitir 22, 80 y 443.

El dominio

Un dominio que controlas para el nodo — nodo1.ejemplo.com, por ejemplo — y la capacidad de fijar un registro A que apunte a la IP pública de la máquina.

Cada superficie web que actives necesita también su propio registro A (admin.nodo1.ejemplo.com, my.nodo1.ejemplo.com, y así). El instalador imprime cada registro que necesita.

El proveedor de correo

Obligatorio para salir en producción. Un proveedor SMTP lleva todo el correo del nodo: los enlaces de inicio de sesión, la confirmación de registro y los restablecimientos de contraseña del servicio de autenticación, y las invitaciones, notificaciones y códigos de verificación de las funciones de borde.

El instalador pregunta por servidor, puerto, usuario y contraseña, verifica la configuración contra el proveedor en vivo antes de instalar nada, y se ofrece a enviarte un mensaje de prueba.

Proveedor	Servidor	Puerto	Usuario	Contraseña
Resend	smtp.resend.com	465	resend	tu clave de API
Postmark	smtp.postmarkapp.com	465	token de servidor	token de servidor
El tuyo	según el proveedor	465	según el proveedor	según el proveedor

Usa el puerto 465, que es TLS implícito. Esto no es una preferencia. En el puerto 587 el runtime de funciones del nodo no completa la actualización STARTTLS. El envío se queda colgado, agota el tiempo y falla, así que las invitaciones, notificaciones y códigos de verificación no salen.

Dos comprobaciones pasan de todas formas, y eso es lo que hace difícil darse cuenta. La comprobación de instalación usa un cliente de correo distinto y conecta por el 587 sin problema. Los enlaces de inicio de sesión y los restablecimientos de contraseña siguen llegando, porque el servicio de inicio de sesión es un programa aparte con su propio cliente de correo — así que enviarte a ti mismo un enlace de inicio de sesión, la prueba que pide la lista de comprobación, tiene éxito en un nodo cuyo correo de aplicación está roto.

El puerto 25 de salida está bloqueado en la mayoría de los proveedores de alojamiento.

La dirección de origen tiene que ser un dominio verificado. El nodo envía como noreply@<home_server> por defecto, y los proveedores rechazan cualquier envío desde un dominio que no han verificado para SPF y DKIM. Esto no es tu admin_email — esa es tu propia dirección de acceso y contacto, y su dominio no está verificado. Si tu nodo es un subdominio de una cuenta donde solo el dominio padre está verificado, pon smtp.sender_email al padre verificado. El correo de prueba de la instalación detecta esto antes de que salgas en producción.

Sin correo, el nodo está casi inerte. Los usuarios se unen a través de enlaces de invitación ligados a un correo, así que un nodo que no puede enviar correo no puede dar de alta a nadie. El instalador también fuerza a desactivada cada superficie de federación cuando no hay ningún transporte configurado, y te lo dice. El único nodo que legítimamente funciona sin correo es uno puesto en registration_mode: closed, que no acepta ningún usuario nuevo. Los registros nunca se confirman automáticamente en un nodo.

El software

tc-operator se ejecuta desde un árbol de código fuente completo. Recibes el archivo de distribución del operador de Trusted Codes — un tarball que contiene el árbol completo y compilable, sin historial de control de versiones y sin documentos internos.

Si te dieron un token de inscripción, no tienes que buscar el archivo a mano en absoluto; el instalador de una línea lo hace por ti y verifica la descarga contra el manifiesto de publicación firmado y publicado. Consulta Instalar un nodo.

Lo que no configuras

La raíz de confianza de federación — la URL del registro central y su clave pública raíz — viene integrada en el instalador. Es un único valor para toda la malla, idéntico en cada nodo, y tú ni lo aportas ni lo cambias.

Cada secreto propio del nodo (el secreto JWT, las claves anónima y de servicio, la contraseña de Postgres, la clave de cifrado, la clave de firma de federación) se genera por ti en /etc/trusted-codes/secrets.env, con permisos 0600. Nunca copias un secreto a mano. La única excepción es tu contraseña SMTP, que pones en operator.yaml.

Un ensayo, si quieres uno

En un puesto de trabajo Mac o Linux con Docker, puedes ejecutar todo el flujo de contenedores sin ningún aprovisionamiento de servidor ni TLS:

scripts/tc-operator/tc-operator install --local --config operator.yaml

--local arranca el nodo en un proyecto loopback aislado y se salta apt, el cortafuegos, el archivo de intercambio y el TLS por completo. Desmóntalo con tc-operator uninstall --local --config operator.yaml --purge.