the dominions — on-premises
Isolated, on your hardware.
For environments where data cannot leave the building, Pantheon runs on hardware you own and makes no outbound calls. It launches from containers and needs little underneath it: a Postgres for definitions and the run log, a blob store for content, and - for the jobs that use agents at all - a model endpoint you point it at.
What an on-premises deployment gives you
- Your hardware: the engine runs on infrastructure you rack, image, and control.
- Container-based: the executor, the worker pool, and the connectors ship as containers rather than a bespoke appliance.
- No outbound calls: every dependency, including the model endpoint, is one you host.
Built for regulated environments
Isolation does not mean losing visibility. Every run is still an append-only stream of events in your Postgres, and executor state is still a fold of that stream - so status, the audit trail, approval suspend and resume, and crash recovery all read the same table, inside the isolated environment exactly as outside it.
Approval gates work the same way behind the boundary: a task that gates on a human suspends durably, survives a restart of the executor, and continues on sign-off.
The trade to weigh
Running isolated means the model endpoint is yours to host and keep current, and whatever you can serve locally sets the ceiling on what agent tasks can accomplish. That is a real constraint rather than a footnote, and it is better examined before the posture is chosen than after.
When to choose on-premises
Choose on-premises when policy or regulation requires that no operational data cross your network edge. If you want infrastructure you control but with less to operate, the private VPC deployment runs the same engine inside your own cloud account instead.
Put Pantheon to work.
A 30-minute call. We map one job you already do by hand and show you the audit log by the end of it.