operator.yaml

operator.yaml es el único archivo que editas. Cópialo de scripts/tc-operator/operator.yaml.example, mantenlo en modo 0600, y nunca lo subas a control de versiones — guarda tu contraseña SMTP, que es el único secreto que vive en él. Cualquier otro secreto se genera en /etc/trusted-codes/secrets.env.

Obligatorio

home_server: node1.example.com
admin_email: ops@example.com

home_server es la identidad del nodo. No se puede cambiar en un nodo en marcha — consulta Límites más abajo.

Correo

smtp:
  host: smtp.resend.com
  port: 465
  user: resend
  pass: <tu clave de API>
  sender_name: Your Node
  sender_email: '' # por defecto noreply@<home_server>

Un proveedor para todo el correo del nodo. Mantén el puerto en 465. Consulta Antes de empezar para saber por qué, y para el requisito de dominio verificado, que es lo otro que suele salir mal.

Quién puede tener una cuenta

auth:
  registration_mode: invitation_only

Solo invitation_only (el valor por defecto) y closed son tuyos para fijarlos. Puedes restringir, nunca aflojar. El registro abierto y orgánico se autoriza de forma centralizada mediante la concesión firmada del nodo; poner open aquí se ignora y se trata como invitation_only.

Dos preguntas relacionadas no se fijan en este archivo, y se fijan en la aplicación de administración bajo Node Settings en su lugar:

1. Qué pasa cuando uno de tus miembros invita a alguien que no tiene cuenta en ningún sitio — rechazar, o enviarlo a Trusted Codes a registrarse. Elegir enviarlo envía el correo electrónico de la persona invitada a Trusted Codes. Es una doble puerta: el servidor central también tiene que aceptar ofertas de tu nodo, o la invitación de tu miembro simplemente falla sin ningún motivo mostrado.
2. Si otros servidores pueden colocar invitaciones en tu nodo para tus miembros. Este es tu interruptor de corte de entrada, y se puede poner a denegar desde cualquier estado.

Están deliberadamente fuera de este archivo, porque cada reload reescribe los indicadores de federación de forma incondicional — un valor fijado aquí reiniciaría en silencio una decisión que tomaste después.

Indicadores de federación

federation: true

federation: true activa todo el conjunto participante — code_lookup, open_link_claim, invitations, groups y multi_account. Cualquier clave individual sobrescribe el atajo.

Dos cosas que vale la pena saber:

• Un transporte de correo es un requisito previo obligatorio. Sin smtp.host, el instalador fuerza a desactivado todo el conjunto y te lo dice.
• El archivo de ejemplo pone cada indicador a false explícitamente. Si lo copias sin editar tienes un nodo con la federación desactivada, aunque un nodo con SMTP configurado por lo demás se active por defecto. Fíjalos deliberadamente.

Lo que expone cada superficie, y por qué dos de ellas fueron hallazgos de seguridad, está cubierto en la sección Servidor federado. Léela antes de activarlas.

El descubrimiento WebFinger siempre está activo. Un nodo tiene que ser descubrible para federarse.

Superficies

Qué superficies web sirve este nodo bajo tu dominio. Usa la forma de bloque; la forma en línea my: { enabled: true } no se procesa.

surfaces:
  admin:
    enabled: true
  my:
    enabled: false
  verify:
    enabled: false
  provider:
    enabled: false
  status:
    enabled: false
  business:
    enabled: false
    # host: verify.example.com   # anulación de dominio por superficie

admin está activa por defecto y nunca se puede detener — es la superficie de recuperación. Cada superficie activada se construye en la máquina y necesita su propio registro A de DNS.

Marca

branding:
  product_name: Trusted Codes
  primary_color: '#1a3a5c'
  # logo_url: https://node1.example.com/logo.svg

El nombre, el color y el logo se publican en la información firmada del nodo y se aplican al contenido propio del nodo — correos, ayuda, incorporación.

Integraciones opcionales

Todo aquí es opcional. Deja una clave vacía y esa función simplemente se desactiva: el nodo sigue funcionando, y tanto el resumen de instalación como tc-operator status muestran qué integraciones están activas y cuáles no. Nada falla en silencio. Obtienes estas claves tú mismo, para tu propio despliegue; Trusted Codes nunca las ve.

Integración	Claves	Vacía significa
MaxMind — geografía y puntuación de fraude en accesos y búsquedas	integrations.maxmind.account_id, license_key	los accesos siguen sin puntuar, lo que es abierto por fallo
Chat de IA	integrations.ai.mistral_api_key o gemini_api_key	el asistente está desactivado
Metabase — paneles integrados en la aplicación de administración	integrations.metabase.site_url, embedding_secret	los paneles no están disponibles

El valor por defecto de MaxMind merece una segunda mirada. Para un nodo que debería bloquear los accesos cuando la puntuación no está disponible en vez de dejarlos pasar, hay un parámetro aparte que fijar.

La facturación y las notificaciones push móviles son solo centrales y no tienen ningún ajuste aquí.

Relevo de push

push_relay_server: app.trusted.codes

Un nombre de servidor de federación, no una URL. Tu nodo es dueño de los tokens push de sus usuarios, pero la credencial push de la aplicación móvil compartida pertenece a Trusted Codes, así que tu nodo no puede hablar directamente con los servicios push de las tiendas de aplicaciones. Con esto fijado, las notificaciones push viajan como sobres de federación firmados a través del relevo.

El relevo ve un token, una hora y el nombre de tu servidor. Nunca contenido. En esta versión solo viajan avisos silenciosos de “despierta y sincroniza”; el dispositivo entonces obtiene y muestra los datos reales de tu nodo. La consecuencia es real: tus usuarios reciben despertares de sincronización en segundo plano, no texto de notificación enviado por el servidor. Las alertas visibles aparecen cuando la aplicación pasa a primer plano y sincroniza.

Dejarlo sin fijar mantiene los envíos directos, que funcionan hasta que la seguridad push se active en toda la plataforma. Si el push falla por completo no se rompe nada — los clientes convergen en barridos de primer plano. El push nunca es crítico en este producto.

Aplicar un cambio a un nodo en marcha

sudo scripts/tc-operator/tc-operator reload --config operator.yaml

Piénsalo como poner todo el nodo al día con lo que dice ahora el archivo. Vuelve a verificar SMTP contra el proveedor en vivo antes de aplicar nada, vuelve a generar secrets.env a partir del archivo, deja que Docker recree exactamente los contenedores cuyos ajustes cambiaron, vuelve a aplicar los ajustes del lado de la base de datos (indicadores de federación, interruptores de superficies, marca, URLs del portal), vuelve a firmar la información publicada del nodo, recarga en caliente el proxy y se autoevalúa.

Los secretos generados — las claves JWT, las claves de cifrado, la identidad de federación — nunca los rota un reload. Una configuración sin cambios es una operación nula, así que es seguro ejecutarlo en cualquier momento.

Cubierto: smtp, auth, integrations, branding, surfaces, los indicadores de federación, push_relay_server, y las anulaciones de registro y de concesión.

Lo que reload no hará

• home_server no se puede recargar. Cambiarlo es un cambio de identidad — DNS, TLS, admisión al registro. Reload se niega y te dirige a la instalación.
• admin_email solo se aplica en parte. Reload actualiza la dirección de contacto del certificado. Una cuenta de administrador nueva necesita tc-operator add-admin --email <dirección>.
• Una superficie recién activada no se construye. Reload avisa y te dirige a tc-operator service start <superficie>, que la construye y la sirve.
• Reload es autoritativo para las superficies. Cualquier interruptor improvisado en la aplicación de administración desde la última reconciliación se restablece a lo que declara el archivo. La instalación se comporta igual.
• El código nuevo y las migraciones nuevas nunca viajan por reload. Eso es actualizar.