Self-hosting

Run Surface inside your own infrastructure. Arranged with us, and here is what it takes.

Surface is a hosted service. Everything else in these docs assumes the console at console.superalign.ai and laptops reporting to *.superalign.ai.

If your policy says the console and its database have to stay inside your own network, we support that. It is arranged with us rather than self-served: there is no public installer, and the images are not on a public registry.

Talk to us first

Write to SuperAlign support before you plan the infrastructure. Tell us:

How many laptops you expect to enrol, and over how long. This is the number that decides the sizing.
Where it will run: cloud provider and region, or on-premise.
Whether the laptops will have any internet access at all.

We size the deployment with you and give you the images, the Helm chart, and the licence.

Minimum specification

Everything runs as a container. This is a floor for a small fleet, not a target for a large one.

Component	Pods	Each pod	What it does
Backend	2	2 vCPU, 4 GB RAM	The HTTP API: sign-in, enrolment, scan ingest, decisions
Gateway	2	2 vCPU, 4 GB RAM	Holds one live WebSocket per laptop, for decisions that arrive in seconds instead of at the next scan
Console	1	2 vCPU, 4 GB RAM	The web interface
Postgres	1	2 vCPU, 4 GB RAM, 50 GB disk	Every asset, finding, decision, and session

Two backend pods and two gateway pods are a minimum for availability rather than for throughput: either can be restarted or lost without the fleet noticing.

What is not in that table

You provide these, and they are sized separately. Authentication is not among them: the backend handles sign-in itself, so there is no identity provider to stand up.

You need	Why
An ingress that terminates TLS and passes WebSocket upgrades	Laptops reach the backend and the gateway through it
The configuration API and its own small Postgres database	Laptops fetch their discovery rules from it. It is a separate service with a separate hostname
Backups of Postgres	Everything Surface knows lives there. Losing it means re-enrolling the fleet

A read replica is worth having for failover and for backups without touching the primary. The application does not read from one today: the backend takes a single database URL, so a replica is a resilience measure, not extra query capacity.

Postgres is the constraint

Under load, the database saturates before the pods do. A scan from one laptop becomes roughly a hundred row writes, and the backend is waiting on Postgres long before it runs out of CPU. Adding backend pods raises how many requests are accepted; it does not raise how fast they drain.

So the sizing conversation is mostly about the database. Fleet size, scan interval, and how much changes between scans decide it, which is why we ask for the laptop count first.

How much load this handles

Each gateway pod holds 10,000 laptop WebSockets. Two pods carry 20,000 laptops connected at once, and every further 10,000 laptops takes one more pod. The cap is exact: past it a laptop’s connection is refused, rather than everyone’s slowing down. A laptop with no live connection still scans on its own, so its decisions arrive at the next 15-minute scan instead of within seconds. The cap is the gateway’s MAX_CONNECTIONS setting, and we set it for your deployment.

Postgres decides everything else. A scan from one laptop becomes roughly a hundred row writes, so the backend waits on the database long before it runs out of CPU. More backend pods accept more scans at once; they do not clear them any faster. Fleet size, scan interval, and how much changes between scans are what the database has to be sized against.

That is the one number we size rather than publish. Tell us the laptop count and the scan interval you want, and we will tell you the Postgres it needs.

Requirements for what the laptops themselves need
Data handling for what is stored and for how long