Run ToRun on your own infrastructure — on-prem and self-hosted
Not every team can send prompts to a third-party cloud. Regulated industries, government workloads, and companies with strict data-residency rules need their AI stack to stay inside their own network. ToRun ships as a se…
Not every team can send prompts to a third-party cloud. Regulated industries, government workloads, and companies with strict data-residency rules need their AI stack to stay inside their own network. ToRun ships as a self-hostable platform for exactly this case — and it is not a stripped-down edition. It is the same product, running under your control.
What self-hosted actually means here
Self-hosted ToRun is the full platform deployed on infrastructure you own: your servers, your Kubernetes cluster, or a single Docker host in a colocation facility. There is no phone-home requirement for inference. When you route a chat message, an image generation, or a workflow step, the request goes to the models you have configured — which can be entirely local.
The deployment is designed to be operable by a small team. A one-command Docker installation stands up the API, the Angular front end, MongoDB, Redis, and the event bus. From there you point it at your model backends and your object storage, and the platform behaves identically to the hosted version.
Bring your own local LLMs
ToRun's capability-first routing does not care whether a model lives at a cloud provider or on a GPU box in your own rack. You register a model in the catalog with the capabilities it supports (text, vision, tools, structured output, and so on), point the client at your local inference endpoint, and it enters the same routing pipeline as everything else.
That means you can run open-weight models through a local server — the same OpenAI-compatible inference endpoints most self-hosting teams already use — and have ToRun select among them by capability and cost the same way it would select among cloud providers. A workflow can mix a local model for sensitive steps with a cloud model for non-sensitive ones, if your policy allows it. Or you can keep every call inside the perimeter.
The same primitives, under your keys
Self-hosting does not mean giving up the platform's trust machinery. On your own infrastructure you still get:
- Capability-first routing with automatic fallback across whatever model backends you register.
- One billing record per call — the cost-accounting ledger works against your configured rates, so you can still attribute spend per team, per mode, and per model even when the compute is your own.
- BYOK vault for any cloud providers you do choose to use, with encrypted-at-rest credentials and a resolution audit trail.
- Hash-chained audit for the actions that need tamper-evidence.
- GDPR/KVKK data-rights tooling — data-subject access and erasure run against your own database, so a deletion request is satisfied entirely within your control boundary.
Licensing and updates
The self-hosted edition is licensed per deployment with access to the source, so your security team can review what runs inside your perimeter. Updates arrive as signed releases you choose when to apply — there is no forced auto-update pushing changes into a regulated environment without your sign-off. For teams that require it, a source-escrow arrangement is available so the deployment remains operable regardless of vendor status.
Who this is for
If your objection to adopting an AI platform has always been "we cannot send that data outside our network," self-hosted ToRun is the answer. You get a modern multi-provider AI workspace — chat, generation, workflows, memory, knowledge bases — running against your own models, on your own hardware, with the auditability a compliance team actually asks for.
Talk to us about a self-hosted deployment, or read the on-prem section under /docs to see the reference architecture.