Architecture & deployment

How PixelCore is built and hosted.

The engineering view of the platform: how payloads are decoded, where objects, state and history are stored, which interfaces applications and integrations use — and whether the whole thing runs in the cloud or inside your own perimeter.

Signal path

For the engineers who will run it

Signals flow left to right; each stage has one well-defined job, and every application reads the same core.

Sources

Sensors, meters, gateways, building and facility systems

Bridges

Protocol adapters and drivers decode payloads into typed properties

PixelCore

PostgreSQL · TimescaleDB — objects, state and full history

Dispatcher

Rules, derived metrics, alarm state, RPC registry

API layer

GraphQL queries and subscriptions · gRPC between services

Applications

Monitor · Board · Tables · Assistant · Admin

Decoding

Raw payloads are parsed once, in the bridge layer, into typed properties with units — so no application repeats the work.

Storage

PostgreSQL holds the object model; TimescaleDB holds the time series. Current value and history are queried together.

Interfaces

A typed GraphQL layer serves apps, integrations and the assistant agent; the RPC registry carries commands back out.

Deployment

Run it where your data needs to live

The same platform, the same model and the same applications in both cases — the choice is about where the data sits and which network the integrations reach.

Cloud

Managed and quick to provision — the usual starting point for a pilot and for multi-site rollouts.

  • Provisioned in days rather than months
  • Scaling storage and compute as the estate grows
  • Regional hosting options, confirmed per project

Customer-hosted

The same platform inside your own network and security perimeter, for data-residency and OT requirements.

  • Data stays within your infrastructure
  • Suited to regulated and segmented environments
  • Integrates with on-site building and plant systems
Operating footprint

What it takes to run it

Delivery

One containerised stack

The same build runs in our cloud and on your own hosts.

Network posture

Outbound only

Bridges connect out over TLS — no inbound ports towards the OT network.

Identity & access

Roles, not shared logins

Users, permissions and device credentials live in PixelAdmin; SSO per project.

Retention

Policy per property

High-rate signals never force the whole estate onto one retention policy.

Backup & recovery

Standard database tooling

PostgreSQL and TimescaleDB backups — model and history restore together.

Self-monitoring

The platform watches itself

Gateway health and last-seen times are properties, so silence is alarmable.

Host sizing depends on point count and sample interval rather than floor area — the estimator below gives the order of magnitude, and we confirm the specification against your own data before a pilot.

Sizing

Estimate the scale of your deployment

Six inputs are enough to see the data volume the platform would carry.

Your estate

Connected points
Samples per day
Volume over retention
Indicative topology

Rough numbers are fine. Volume assumes one stored sample per property per interval at roughly 24 bytes compressed, before downsampling.

Send it for a scoped quote

Attached to your messageConnected pointsSamples per dayVolume over retentionHosting

Prefer email?

What happens next
  1. An engineer reads your figures and replies within one business day.
  2. A short call to confirm protocols, access and integration scope.
  3. A written quote per site and per connected point.
Talk to the engineers

Review the architecture against your own estate