Multi-hop impact and where-used
Budgeted traversal at any depth, over a real query engine. Blast radius before the merge, reverse reachability for a library, a database or a signing key.
observed systembounded evidenceself-hosted
A developer portal that stores
relationships, not rows.
HodosGraph is a graph-native Internal Developer Portal for AI governance. It maps code, runtime, ownership, identity and supply chain into one graph you host yourself. Ask it what breaks before you merge. Give your agents a policy-filtered view of it instead of API keys.
Postgres + Apache AGE · FSL-1.1-ALv2 → Apache-2.0 in two years
machines are never seats · no phone-home · runs air-gapped
What can this agent reach?
Every agent is a subject in the graph, filtered by policy on every single call.
reachable(agent)What breaks if I change this?
Impact analysis across repositories, clusters and teams, before the merge.
blast_radius(node)Where is this used, at any depth?
Reverse reachability for anything: a library, a database, a signing key.
where_used(node)Everything a platform team asks of a portal, on one graph
You cannot govern agents that move across services, owners, deployments and permissions until you can model all four in one place. So HodosGraph is a developer portal first.
catalogueServices, repositories, clusters, databases, workloads, teams and agents, modelled as nodes and relations.exploreA graph explorer for the map, a visual query builder for the question, openCypher when you want to write it yourself.agentsEvery agent, its capabilities, its workload identity and its governed egress, inventoried next to the code it came from.as codeSchema, policies, workflows, dashboards and golden paths in YAML, reviewed as a pull request, applied with plan and apply.workflowsReal operations from the portal, with inputs, approvals and an audit trail, against Kubernetes or your own automation.scorecardsWhat a service is expected to have, how far a migration has got, and who is behind.supply chainSBOM dependencies, artefact provenance and vulnerability context on the same nodes as ownership and runtime.
Governed context for agents, over MCP
Give an agent raw API keys and you have given it your whole company. HodosGraph hands it agraph instead: every read filtered by policy, every running agent inventoried alongside the code it came from, every action recorded. Connect over the Model Context Protocol and an agent gets exactly what it is allowed to see.
Withheld context is withheld silently. The agent never learns what it could not see.
hodos-mcp · tool call
// the agent asks, HodosGraph answers, policy filters → impact_of_change("checkout-web") Affected: payment-api (tier-1), ledger-svc Owners to notify: team-payments Scorecard: Silver, this change requires Gold Verdict: block, and open a ticket 3 nodes withheld by policy. The agent never saw the production secrets it is not allowed to reach.
The question a flat catalogue cannot answer
Flat catalogues store attributes. HodosGraph stores relationships, so a real query engine walks your dependency graph with bounded, budgeted traversal. Multi-hop where-used and blast radius come from the storage engine, which is why they hold at any depth. Ask what breaks? and get an answer, not a list.
hodos-cli · impact
$ hodos impact orders-db --max-hops 4 ┌──────────────┬───────────────┐ │ 17 services │ 4 teams │ ├──────────────┼───────────────┤ │ payment-api │ team-payments │ │ checkout-web │ team-web │ │ ledger-svc │ team-fintech │ └──────────────┴───────────────┘ 2 agents currently hold read access to this path
Batteries included, then extend in YAML
docker compose up, connect GitHub, and you have a catalogue with owners and dependencies in minutes, with zero modelling. Outgrow the defaults and you define your own entity kinds, scorecards, workflows and policies in YAML: versioned in git, reviewed as a pull request, applied with a plan /apply you can read before it runs.
In a hosted portal you wait for an admin to build a blueprint. Here your team ships its own, and review is the guardrail.
schema/process.yaml
apiVersion: hodos/v1 kind: EntityKind metadata: {name: process} spec: fields: criticality: {type: enum, values: [low, high]} relations: - {rel: IMPLEMENTS, from: component, to: process} $ hodos plan # read the diff, like Terraform $ hodos apply # exactly what you reviewed
From zero to a governed graph in four steps
01
Run it
One Postgres with Apache AGE and the HodosGraph server. Run docker compose up locally, then use Helm on Kubernetes when you are ready.
02
Connect a source
Point a collector at GitHub or a cluster. Ownership, dependencies and workloads land in the graph without you modelling anything first.
03
Write the rules
Declare who, and which agent, may see what, in YAML you review in a pull request. The engine explains every decision it makes.
04
Point your agents at it
Connect over MCP. Each agent gets a filtered view of the graph, and every request it makes is recorded against its identity.
public packaging in progress
The release will ship as one verified path
Docker Compose for a local evaluation, Helm for Kubernetes, generated API and CLI references, and a tested upgrade path. We will publish the command only when every linked artifact is reachable without private repository access.
Try the public demo
A full HodosGraph instance loaded with a realistic estate: services, clusters, owners, workflows and a pair of AI agents, open to anyone, with no account and no email address. Walk the graph, break something on purpose, ask what the blast radius is, and watch an agent get told no.
No company data input
No account, email form, upload or free-text integration setup. The demo resets on a schedule and does not ask you to provide information about your environment.
Real product, synthetic data
The same build you would self-host, running against a generated company. Nothing on screen is a mock-up, and nothing on screen is anyone's real infrastructure.
Read-only where it matters
You can query, explore and simulate. Destructive operations are demonstrated through workflow runs rather than by letting the internet delete things.
demo opening shortlyHow demo privacy works
Connect what you already run
Collectors are ordinary, inspectable code. Every one of them is in the free core, and the SDK that builds them is the same one we use.
GitHub
repos, ownership, CODEOWNERS, pull requests
Kubernetes
workloads, services, namespaces, admission
OCI registries
images, provenance, signatures
Cilium / Hubble
observed network flows between workloads
Hetzner
servers, networks, volumes
Keycloak
OIDC, SAML, directory sync
Microsoft Entra
identity and workload federation
Terraform
manage HodosGraph itself as code
Model Context Protocol
the agent-facing interface
Collector SDK
anything else you run
Two editions, both self-hosted
A complete Free core, and Enterprise for federation, compliance evidence, fleet operations and support.
Free
The entire product for one workspace, on your own infrastructure. Not a trial and not a crippled edition. It is the complete graph, the complete governance engine.
Contact sales
Everything in Free, plus the controls a compliance function asks for and the scale features a fleet needs. Unlocked by a signed licence file, verified offline.
Fair source, and what that means for security
Inspectable by design
The public release includes the enforcement engine. Governance you cannot audit is governance you cannot trust, so policy evaluation is never the part we sell.
Becomes Apache-2.0
Fair source, not open source: FSL-1.1-ALv2 today, and every release converts to Apache-2.0 two years after it ships. The conversion is in the licence, so we cannot pull it back.
No phone-home, ever
The enterprise licence is a signed file verified locally. HodosGraph runs air-gapped in every tier, and telemetry, if it ever exists, will be opt-in and separate.
Security is not an upsell
The capability to be secure is in the free core: RBAC, ABAC, ReBAC, field-level grants, audit logging, OIDC. What is sold is proving it at enterprise scale.
Your infrastructure, your region
HodosGraph runs where you run it: locally, on Kubernetes or in an air-gapped estate. Your graph stays within the boundary and integrations that you configure.
Report a vulnerability
Send it to [email protected]. We answer, coordinate disclosure and credit you unless you ask us not to.
Where HodosGraph sits
Four real alternatives, described from their current public documentation. The categories overlap; the execution model, deployment boundary and operating cost do not. If one fits your problem better, use it.
| HodosGraph | Port | Cortex | Roadie | Backstage | |
|---|---|---|---|---|---|
| Relationship model | Typed operational graph on PostgreSQL + Apache AGE; openCypher | Context Lake with blueprints, entities, properties and relations | Catalogue entities, dependencies, custom relationships and CQL | Managed Backstage catalogue plus an Enterprise Context graph | Catalogue graph from entity descriptors and derived relations |
| Impact queries | Bounded traversal, reverse reachability and blast radius, with hop and node budgets | Upstream and downstream search plus queries over declared relation paths | Recursive relationship queries with optional depth; dependency graph | Connected service and dependency context through the catalogue, API and MCP | Core relation graph; live runtime impact needs data sources and usually plugins or code |
| Agents and MCP | Agent inventory linked to workload identity; policy-filtered MCP context and audited actions | Native and external agent registry, Port MCP, allowed tools and workflows | MCP over the catalogue, scorecards and engineering intelligence | Permissioned context, RAG and MCP servers for the catalogue, docs and Scaffolder | Official MCP Actions backend; identity, context and governance are assembled by the adopter |
| Deployment | Complete Core self-hosted; no vendor account required | Multi-tenant SaaS; integrations and agent can run in your infrastructure; single tenant by agreement | SaaS or commercial self-managed/on-prem | Managed SaaS that connects to on-prem systems | Self-hosted Apache-2.0 framework |
| Configuration | Kubernetes-style typed resources through one API, CLI and Terraform boundary; native plan/apply | Predefined integration models; UI, API, AI, Terraform and Pulumi | YAML entities and relations, integrations, scorecards and workflows | Managed catalogue, templates, TechDocs and 75+ integrations/plugins; upgrades included | Catalog, Templates and TechDocs in core; adopter composes plugins and operations |
| Commercial model | Free Core with no seat or entity cap. Enterprise platform fee + active humans; machines and graph size are not billed | Free up to 15 seats and 10,000 entities; paid plans per seat with entity and automation limits | Custom quote; no public unit price | $24 per contributing developer/month for Teams (50–150); unlimited entities; larger plans custom | No licence fee; your team owns hosting, integration and upgrade cost |
| Best fit | Teams that need a self-hosted, inspectable graph control plane for humans and agents | SaaS-first teams that want a packaged IDP and Context Lake | Organisations standardising engineering practices, scorecards and workflows | Teams that want Backstage without operating it | Teams that want framework freedom and can own the platform engineering |
Evidence checked 7 August 2026 against the vendors' own documentation.
- Port: data model, relation queries, agent management, deployment and pricing
- Cortex: relationships, MCP, deployment and pricing
- Roadie: product and pricing and API and MCP
- Backstage: catalogue graph, MCP Actions and installation
Documentation ships with the product
The docs are written and versioned alongside the code, and reference pages are generated from the schema, the OpenAPI description and the CLI itself, so they cannot drift from what the product actually does. The public link appears only after the complete docs build is reachable at docs.hodosgraph.com.
public docs in release verification GitHub
What will be there on day one
- Getting started, self-hosted quickstart and core concepts
- Catalogue, explorer, query builder and saved analyses
- Schema as code: kinds, relations, migrations, plan and apply
- Agents: capabilities, MCP, workload identity, lifecycle workflows
- Governance: scorecards, initiatives, evaluation
- Security: RBAC, ReBAC/ABAC, tenancy, supply chain, admission control
- Administration: identity providers, integrations, secrets, projects
- Reference: CLI, REST API, Terraform provider
Questions we get asked
Is HodosGraph open source?
Not in the OSI sense. The public release is licensed as fair source under FSL-1.1-ALv2. Source links remain hidden until the repository and its release artifacts are publicly reachable.
Every release converts automatically to Apache-2.0 two years after it ships. That conversion is written into the licence, so it does not depend on us staying friendly.
What exactly is free?
The self-hosted core, forever, with no seat cap and no entity cap. That includes the catalogue, the graph, impact analysis, the MCP server, collectors, schema-as-code, workflows, dashboards, scorecards, and the full RBAC/ABAC/ReBAC enforcement engine with audit logging and OIDC.
We do not gate security primitives. The capability to be secure is core. What we sell is the capability to prove it at enterprise scale: SAML and SCIM federation, access reviews, tamper-evident export, compliance reporting.
Does it phone home?
No. The enterprise licence is a signed file verified locally, with no network call. HodosGraph runs fully offline and air-gapped in every tier. That is a requirement for the regulated, EU-heavy buyer this product is built for, not a feature we would sell back to them.
How is this different from Port, Cortex, Roadie or Backstage?
Port, Cortex and Roadie are mature commercial products. Port has a Context Lake with relations, Cortex supports recursive relationship queries, and Roadie operates Backstage for you. Backstage itself is an Apache-2.0 framework that your team assembles and runs.
HodosGraph makes a different tradeoff: the complete Core runs in your infrastructure on a disclosed PostgreSQL and Apache AGE engine. It exposes openCypher, bounded graph traversal and Kubernetes-style typed resources through one API, CLI and Terraform boundary. Choose it when ownership of the runtime and graph execution model matters. Choose a managed product when operating the portal is the problem you want to avoid.
What does it run on?
PostgreSQL with the Apache AGE extension. One database you already know how to operate, backed up the way you already back up Postgres. Start with docker compose up; run it on Kubernetes with the Helm chart when you outgrow that.
Where does HodosGraph run?
You deploy HodosGraph inside infrastructure you control. For evaluation, the public demo uses a generated environment and does not accept uploads or information about your company.
Can I migrate off it?
Yes, and the design assumes you will want the option. Your schema, policies, workflows and dashboards are YAML in your own git repository; the graph is queryable over openCypher and exportable over the API; the product runs in infrastructure you control.
What state is the product in?
The self-hosted core is built and running. Public packaging, documentation and the synthetic demo are being prepared as one release, so this site does not link to private repositories or unfinished endpoints.
Enterprise is available as a design-partner pilot with scope agreed before deployment.
Does the demo collect anything about me?
The demo has no account, sign-up, analytics, upload or free-text company-data form. It uses generated data and resets on a schedule. As with any public website, the hosting and security layers may process limited request metadata such as an IP address. The privacy page explains that boundary plainly.
Give your agents a map, and a policy boundary
Evaluate HodosGraph with synthetic data, then run your real graph inside your own infrastructure.
No signup form · no newsletter · no customer-data upload