All EidOS core modules and SaaS pioneer applications are executing within normal operating limits. Zero immediate need to provision additional infrastructure.
#1 Target to Extract First
--
MUS Score: --
--
24-Hour System Load Trajectory
Hourly telemetry trend samples from PostgreSQL
● CPU %
● Memory (RAM) %
--- Saturation Trigger (80%)
Migration Urgency (MUS)
Ranked extraction priority
Subsystem & SaaS Process Attribution
Detailed memory, CPU, and database connection metrics per module
Module / Process
Role / Domain
CPU (%)
RAM (MB)
DB Conns
MUS Score
Status
Zero-Downtime Strangler-Fig Migration Plan
When ready to extract to a dedicated secondary node:
Step 1: On the New Target Worker Node (e.g. 10.0.0.2)
# Spin up module service on target worker:
git clone https://github.com/eidolonai/eidos.git /opt/eidos
sudo systemctl enable --now
Step 2: Update Nginx on the Single VPS Host
# In /etc/nginx/sites-available/eidos-gui:
upstream {
server 10.0.0.2: max_fails=3 fail_timeout=10s;
}
# Reload proxy with zero downtime:
sudo nginx -t && sudo systemctl reload nginx
Step 3: Verify Single VPS Capacity Reclamation
VPS CPU and RAM immediately free up; remaining modules continue running undisturbed.