How it works & security
Read-only on site. One model for the estate. Live in weeks.
A collector per datacenter reads your equipment and sends outbound only. SynapseDC builds one estate model and never controls plant, polls tenant gear or reads job data. People decide and act.
Architecture
From the equipment to the answer.
- BMS · UPS · PDUs · metersBACnet · Modbus · SNMP
- CRAH · CDUs · sensorsBACnet · Modbus
- Routers · switches · opticsSNMPv3 · gNMI · syslog
- Servers · BMCsRedfish · IPMI
- GPUs · scheduler · fabricDCGM · Slurm · UFM
- Doors · cages · CCTVPACS · VMS
- Read each source with a read-only role
- Normalise alarms; keep source and time
- Buffer when the uplink drops
- Send outbound only, one channel
- ITSM · incidents, changes, tickets
- CRM · customers, contracts, notices
- IPAM · DNS · DHCP
- SIEM · OCSF events
- Your tools · REST API v1 · webhooks · Kafka
Security boundaries
What SynapseDC will and will not do.
Clear limits, stated early. It reads, explains and recommends; people decide and act.
Never controls plant
SynapseDC reads the BMS, UPS, PDUs, meters, network and BMCs. It never changes a set point or switches anything. People act through a change request.
Outbound only
The collector (active + standby) sends outbound over mTLS on port 443. Nothing connects into the site.
Tenant equipment sealed
In colocation, tenant gear is never polled. Power at the cabinet, inlet temperature and the cage door are measured from outside.
GPU jobs, not their contents
In a GPU cloud, GPUs and jobs are monitored. A job's data, model weights and code never are.
Your identity provider
Screens run with your identity (OIDC), in the platform shell or embedded in your portal.
Every change recorded
Record edits run under a change request; decisions, approvals and plan edits are audited.
Data
Numbers you can trust, because nothing is typed in.
Every count is derived
Counts come from devices, interfaces, links, services, alarms and incidents, never typed in.
Every sample keeps its source
Source and receipt time on every reading. Fresh means younger than two polling intervals.
Stable identities
Entity ids are stable strings, so adding data never reshuffles the rest.
Your currency, your tariffs
Money in your currency and format, priced with your own tariffs and benchmarks.
Onboarding
One site, live in 6–10 weeks.
A pilot runs the operate core on one datacenter, read-only. Further sites and modules follow once the pilot has proved what you agreed it should.
- 011–2 weeks
Discovery
Your sites, the systems you run and what the pilot should prove.
- Business model and sites in scope
- BMS, EPMS, DCIM, ITSM, CRM, PACS, SSO
- Success criteria agreed up front
- 022–3 weeks
Site survey and data
Collector placement, the one firewall rule and your records.
- Collector placement, active + standby
- One outbound rule: mTLS 443
- Racks, devices and customers imported
- 032–4 weeks
Connect
The sources that prove value first, the rest in later waves.
- Network, UPS / PDUs and BMS first
- Then BMCs, GPUs and the scheduler
- Then ITSM, paging and CRM
- 04the pilot site
Go-live
Live alarms in scope and the first incidents with impact, checked against the criteria.
- Reconciliation checks green
- Alarms in scope, incidents with impact
- Next sites and modules planned
With your security team
What we walk through in discovery.
The collector
Placement inside the site, active and standby, what it reads and how it buffers when the uplink drops.
Ports and protocols
Every southbound protocol, its credentials and the read-only role it uses; the single outbound port.
The data each one carries
Per source, the records and samples that leave the site, and the ones that never do.
See your own estate in it.
Bring the fault your team keeps dealing with. We walk it end to end on a demo estate shaped like yours, then agree what a one-site pilot should prove.