Self-Hosted Ontology Platform: Run Foundry in Your Cloud

Yes: Helix Foundry is a self-hosted ontology platform you can run on your own machine, deploy into your own cloud (BYOC), or use on Helix Cloud, and it can work with self-hosted models, your own inference or a model you bring. It is open source under Apache-2.0, built on object storage, and data is encrypted at rest.

If you are a data, ops or security lead, the question is rarely whether an ontology would help. It is where the data goes, who else's model reads it, and what leaves your boundary. This post is a Q&A on exactly that: deployment, models and data residency. It states what the Foundry README and docs document. Where something is an option and not a documented step, it says so and does not invent commands.

Can you self-host an ontology platform, and what does Helix Foundry run on?

Yes. Helix Foundry connects your databases, tools and documents, drafts one ontology over them and loads it into HelixDB as a connected graph you can explore and question. Every value traces back to the row or document quote it came from. Foundry is the app; HelixDB is the database it loads into.

There are three ways to run it. Locally, with Docker, on your own computer. In your own cloud account (BYOC, bring your own cloud). Or on Helix Cloud at foundry.helix-db.com. Everything in the helix-foundry repository is Apache 2.0, including Foundry's three images, so you can read, build and run the code you are evaluating.

The platform is built on object storage, which is what lets it scale, and data is encrypted at rest. The rest of this post takes those choices one at a time.

How do you run Helix Foundry locally?

Run it with Docker Compose. Then:

git clone https://github.com/helixdb/helix-foundry.git
cd helix-foundry
docker compose up -d --wait

The quickstart walks a new workspace from sign-in to a first answer and an explored graph. The docs also include a sample company, so you can see every step on made-up data before connecting your own.

Know what this install is. The local setup is for one person on their own computer, with no sign-in. It listens on localhost only, so do not put it behind a proxy, tunnel or port forward. Treat it as a single-user evaluation and build environment, not a shared team server. If you need something other people in your organisation can reach, that is the BYOC or Helix Cloud question below.

Can Helix Foundry run in your own cloud (BYOC)?

Yes. BYOC is a supported deployment option: Foundry can be deployed into a cloud account you control, so the application and the data it holds stay inside your boundary instead of a vendor's.

Be precise about what is documented. The README and docs spell out the local Docker flow in detail and the Helix Cloud flow at foundry.helix-db.com. They do not publish a step-by-step BYOC runbook, so this post gives you no commands for it, and you should not expect them to be inferable from the local setup. The local Compose install is deliberately a single-user, localhost-only setup and is not a template for a shared, internet-facing deployment.

BYOC rests on the architecture. Foundry is built on object storage, and HelixDB, the database underneath, can run against S3-compatible object storage. Your storage can therefore live in your own account. Use the Foundry docs for the product concepts and talk to the Helix team about the BYOC rollout for your environment.

Can Foundry use self-hosted models, your own inference or your own model?

Yes. Foundry can work with self-hosted models, with your own inference, and with a model you bring (BYOM), so the model reading your data does not have to be a third-party API.

This matters because the model is the other place company data can leave. That is real data going to a model. If the model is one you host or one running on your own inference, that data goes to infrastructure you run.

The docs do not publish configuration steps for pointing Foundry at a particular self-hosted model server, so this post names the capability and not a setting. When you evaluate, ask for the exact model and endpoint configuration for your target. Then confirm in a test generation where requests are going before you connect production sources.

Where does the data live, and is it encrypted at rest?

The data lives in the Foundry deployment you run, in HelixDB, on object storage, and it is encrypted at rest.

Here is what that means in each mode. Locally, everything stays on your machine and the app is reachable only from it. In BYOC, it stays in your cloud account. On Helix Cloud, it is in a managed service, which is the one option here that is not your infrastructure. Building on object storage is what lets the platform scale: HelixDB Cloud keeps nodes, edges, properties and indexes durably in object storage, with readers that scale horizontally.

If you are choosing between modes on residency alone, the rule is simple. If the data cannot sit in a vendor's cloud, run locally or BYOC. If it can, Helix Cloud is the least work. Either way, check encryption at rest and key custody against your own policy during evaluation.

What does Foundry send to a model, and what does it never do to your sources?

It never writes to your sources.

Two statements from the docs are worth quoting to a security reviewer. The scope is limited to what you synced and the document sets involved, not your whole estate. Second, on sources: under what Foundry does not do, the docs say it never writes to your sources. Connectors read. They do not modify the sources you pointed them at.

Pair that with traceability. Every value in the ontology is tied to the row or document quote it came from, so an auditor can ask where a fact originated and get a concrete answer. Add a self-hosted model and you get an ontology built from your data, by a model you run, in a place you control.

Which deployment fits which constraint? Trade-offs to weigh

Pick the deployment by the constraint that binds you hardest.

Constraint	Best fit	Trade-off
Data cannot leave my machine, evaluating alone	Local Docker	Single-user, localhost only, no sign-in, not shareable
Data cannot leave my cloud account, team needs access	BYOC	Not a documented step-by-step flow; plan it with the Helix team
No third-party model API allowed	Self-hosted model or own inference	You operate the inference; confirm configuration for your setup
Fastest route, no residency limit	Helix Cloud	Managed by Helix, not your infrastructure

People get two things wrong. They treat the local install as a team deployment, and it is not: it has no sign-in and must stay on localhost. And they secure the database but forget the model. If the model is a hosted API, the data you thought stayed home does not. Decide both on purpose.

FAQ

These are the questions data and security leads ask first.

Start local, then plan BYOC with your own models

Foundry is a self-hosted ontology platform you can verify before you commit: Apache-2.0 code, a documented local install, and options for BYOC, self-hosted models and bring-your-own-model. Clone the helix-foundry repo, run docker compose up -d --wait, and try the sample company to see an ontology built and traced to source on your own machine. Then take your residency and model requirements to the Helix team and scope the BYOC deployment from there.