Topología de servidores

Respuesta corta: 2 VMs Linux, 0 VMs Windows

BIAM no necesita ninguna máquina Windows propia. Los servidores Windows existentes (controladores de dominio, aplicaciones legacy) siguen siendo sistemas destino: BIAM les llega por red — LDAPS al dominio, APIs o handlers a las aplicaciones — y no se instala nada de BIAM en ellos.

Escenarios

Piloto / PoC — 1 VM

Todo en uno (app + PostgreSQL): 4 vCPU / 8 GB / 100 GB SSD. Suficiente para evaluar el producto con datos reales.

Producción estándar (recomendado) — 2 VMs

• VM app: nginx + php-fpm, worker de colas, cron, SPA — 4 vCPU / 8 GB / 80 GB.
• VM BD: PostgreSQL — 4 vCPU / 8 GB / 150+ GB SSD.

Separar app y BD simplifica backups, actualización y crecimiento independiente.

Alta disponibilidad (banca) — 4–5 VMs

2 VMs app detrás de un balanceador + PostgreSQL primaria/réplica (streaming replication). El worker de colas corre en una sola app a la vez o con locks compartidos.

Runner RPA (AutoIt)

La plataforma en sí es 100 % Linux — el "0 VMs Windows" se refiere a la base de BIAM. La única VM Windows opcional aparece cuando un conector RPA debe automatizar una aplicación Windows por interfaz gráfica (sin API disponible): un runner AutoIt dedicado. Cómo será:

• 1 VM Windows Server (2019+) — 4 vCPU / 8–16 GB / 80 GB — dedicada exclusivamente a la automatización, sin otros roles.
• Scripts AutoIt (.au3 compilados) versionados en el repositorio y desplegados al runner. No hay clics a ciegas: cada script implementa una acción definida (crear cuenta, asignar rol, resetear contraseña…) y devuelve JSON estructurado.
• Invocación desde BIAM: el handler del conector, corriendo en la VM app Linux, llama al runner por WinRM (5985/5986), pasa parámetros y secretos por stdin — jamás se escriben al disco del runner — y recoge el resultado. La evidencia se guarda redactada.
• Sesión interactiva: la automatización GUI exige un escritorio abierto y desbloqueado — cuenta de servicio con auto-logon y sin bloqueo de pantalla solo en esta VM, compensado con aislamiento de red (solo WinRM desde la VM app) y firewall local.
• Serialización y resiliencia: BIAM ejecuta una automatización activa por conector (como un operador humano). Si el runner cae, el circuit breaker del conector retiene las tareas — nada se pierde — y las drena al recuperarse.

¿Alcanza un runner con varios conectores RPA y muchos usuarios? Normalmente sí. El volumen de usuarios solo alarga la cola — el techo de concurrencia es el número de conectores RPA. Las automatizaciones paralelas en una VM necesitan una sesión RDP por conector (más de 2 simultáneas exige licenciamiento RDS); si no, todo se serializa en la práctica, aceptable para eventos de provisioning de bajo volumen. Regla práctica: 1–3 conectores RPA → 1 runner. Separa en un runner por conector cuando la cola se atrase de forma sostenida, las automatizaciones interfieran o una app legacy cuelgue sesiones con frecuencia.

Matriz de red

Origen → destino	Puerto	Uso
Usuarios → VM app	443	Consola web + API
VM app → VM BD	5432	PostgreSQL
VM app → Controladores de dominio	636 (LDAPS)	Active Directory
VM app → sistemas destino	según conector (típico 443)	Provisioning
VM app → servidor de correo	587/465	SMTP
VM app → runner RPA (si existe)	5985/5986	WinRM
VM app → Hub Bayoex	443 (opcional)	Licencias y paquetes de conectores

Air-gapped: la salida a internet no es obligatoria — los paquetes de conectores (.biampkg) y las licencias pueden instalarse offline con firma verificada localmente.