Server topology

Short answer: 2 Linux VMs, 0 Windows VMs

BIAM needs no Windows machine of its own. The existing Windows servers (domain controllers, legacy applications) remain target systems: BIAM reaches them over the network — LDAPS to the domain, APIs or handlers to the applications — and nothing of BIAM is installed on them.

Scenarios

Pilot / PoC — 1 VM

All-in-one (app + PostgreSQL): 4 vCPU / 8 GB / 100 GB SSD. Enough to evaluate the product with real data.

Standard production (recommended) — 2 VMs

• App VM: nginx + php-fpm, queue worker, cron, SPA — 4 vCPU / 8 GB / 80 GB.
• DB VM: PostgreSQL — 4 vCPU / 8 GB / 150+ GB SSD.

Separating app and DB simplifies backups, upgrades and independent growth.

High availability (banking) — 4–5 VMs

2 app VMs behind a load balancer + primary/replica PostgreSQL (streaming replication). The queue worker runs on one app at a time, or with shared locks.

RPA runner (AutoIt)

The platform itself is 100% Linux — "0 Windows VMs" refers to BIAM's base. The one optional Windows VM appears when an RPA connector must automate a Windows application through its GUI (no API available): a dedicated AutoIt runner. How it works:

• 1 Windows Server VM (2019+) — 4 vCPU / 8–16 GB / 80 GB — dedicated exclusively to automation, no other roles.
• AutoIt scripts (compiled .au3) are versioned in the repository and deployed to the runner. There are no blind clicks: each script implements a defined action (create account, assign role, reset password…) and returns structured JSON.
• Invocation from BIAM: the connector's handler, running on the Linux app VM, calls the runner via WinRM (5985/5986), passes parameters and secrets via stdin — they are never written to the runner's disk — and collects the result. Stored evidence is redacted.
• Interactive session: GUI automation needs an open, unlocked desktop — a service account with auto-logon and no screen lock on this VM only, compensated with network isolation (only WinRM from the app VM) and local firewall.
• Serialization and resilience: BIAM runs one active automation per connector (like a human operator). If the runner goes down, the connector's circuit breaker holds the tasks — nothing is lost — and drains them on recovery.

Is one runner enough with several RPA connectors and many users? Usually yes. User volume only lengthens the queue — the concurrency ceiling equals the number of RPA connectors. Parallel automations on one VM need one RDP session per connector (more than 2 concurrent requires RDS licensing); otherwise everything effectively serializes, acceptable for low-volume provisioning events. Rule of thumb: 1–3 RPA connectors → 1 runner. Split into one runner per connector when queues lag consistently, automations interfere, or a legacy app keeps hanging sessions.

Network matrix

Source → destination	Port	Purpose
Users → app VM	443	Web console + API
App VM → DB VM	5432	PostgreSQL
App VM → domain controllers	636 (LDAPS)	Active Directory
App VM → target systems	per connector (typically 443)	Provisioning
App VM → mail server	587/465	SMTP
App VM → RPA runner (if any)	5985/5986	WinRM
App VM → Bayoex Hub	443 (optional)	Licenses and connector packages

Air-gapped: internet egress is not mandatory — connector packages (.biampkg) and licenses can be installed offline with locally verified signatures.