This site is being rebuilt and some pages are out of date. For current details, write to nevio@inorbit.hr. This notice goes away when the rebuild is done.

No analytics unless you allow it, no tracking. This site keeps in your browser the language you pick, the theme, its colour, which site you chose, the currency on the pricing page and that you closed this notice; signing in adds session cookies. The legal page has the details.

Sign in

ProductWays in

The agent in your networkpreview

One program inside your network. It dials out, and your policy wins.

iohr-agent runs checks where your systems are: the database behind the API, the internal service, the node on a private network. It opens one connection out to the platform and listens on nothing, does only what a local policy file allows, and reads a credential from your vault or cluster at the moment of a call. Pre-releases only so far.

Early access: partners get in by request and a signed NDA. No SLA while it lasts.

01Watch it

From the product tour, started at this product's chapter. The narration is an AI voice.

Watch it

InOrbit the engineering platform
Understand your system.
Detect what breaks.
Prove what fixes it.
Monitor, respond, understand and verify, in one loop, with the evidence kept.
01 Monitor live
checkout-api · GET /healthz · every 30 s
13:50p95 per run14:40
PASS 14:01:30 212 ms 200 OK
FAIL 14:02:00 2.9 s 503 from our cloud
FAIL 14:02:00 3.1 s 503 from your agent
Every run becomes evidence.
what was checked
where it ran from
when to the second
what actually happened
example data
02 Respond preview
INC-0142 · CHECKOUT-API
14:02The monitor fails from both places
14:04Opened from the monitor page, responders named
14:05Acknowledged from the lock screen
14:31Resolved
29 min · 4.2% of checks failed · p95 3.4 s
impact measured from 58 monitor runs, not estimated
Today a person opens the incident. Alerts that open it by themselves come next.
14:05
Wednesday 8 October
INORBIT · NOW
INC-0142 · checkout-api failing
Monitor fails from both places
Acknowledge
example data
Every sensor, one evidence model
Direct sensors
HTTP & gRPC monitorslive
Agent checks in your networkpreview
Envoy access logsin dev
Trails browser recordingspreview
eBPF capture, optionalcoming
Read from config
Envoy routesin dev
Kubernetes manifestsin dev
Kubernetes API, read-onlyin dev
Network policiesin dev
Cargo metadatain dev
Read from code
rust-analyzercoming
go/typescoming
TypeScript compilercoming
Java JDTcoming
Python ASTcoming
tree-sitter, the restcoming
Your tools
GitHub pull requestslive
incident.ioin dev
Grafana · Lokicoming
Datadogcoming
PagerDutycoming
Cloud providerscoming
People and models
Reviews of PRDs, ADRs, RFCslive
Acknowledged from the phonepreview
Owner's answerscoming
Docs read by a modelcoming
ONE EVIDENCE MODEL
Every item keeps its method, its source and how it can fail
static resolution · runtime observation · configuration · logs · metrics · traces · external record · testimony · interpretation
Atlas decides what each kind can prove. A model's reading is never proof on its own.
livepreviewin devcoming
real run · 2026-10-08
We tried it on our own platform.
Nobody told it anything. The agent read the system and mapped how it is really built.
0
facts, each linked to its source
0
parts of the system found
0
running services mapped
WHERE THE FACTS CAME FROM
Traffic rules710
Deployment files641
The live cluster385
Code dependencies267
Network rules167
What it worked out by itself:
✓ Which service answers each web address
✓ Which services are allowed to reach the internet
Every fact can be traced back to where it came from. Nothing is a guess.
03 Understand · Atlas in development real topology · example trace
EDGE · ENVOYKUBERNETESNODE · KERNELpackets · connections · DNS · drops · retriesread by the agent's eBPF observer · comingPROCESS · CODEsyscalls · sockets · files · stack samplessame observer, on the process · cominglistener edge :8080Envoy, TLS terminatedroute /v1/* → protocoljwt_authn: iohr-apisvc/protocol :8080EndpointSlice 2/2 readypod protocol-7c9fnode k3d-agent-0veth → conntrack → accept()netns of the podtbd-protocolGET /v1/me handlerengine-lb :50051gRPC, routed by servicepod engine-5d8bnode k3d-agent-11234567
GET /v1/me, traced from the edge to the code and back through the engine load balancer
TRACE · GET /v1/me
1✓envoy.routelistener and route, from the edge config
2✓k8s.manifestthe route's cluster is svc/protocol
3✓k8s.api.read2 of 2 endpoints ready, on agent-0
4?eBPF, optionalkernel path: veth, conntrack, accept()
5✓cargo.metadatacrate tbd-protocol serves the route
6✓configurationprotocol reaches engine via engine-lb
7✓k8s.api.readengine pod, ready, on agent-1
6 of 7 hops proved by 5 methods · hops 4–5 not observed yet
contradictedexit test 2, as specified
Decision: paging makes no calls outside our network
Running system: NetworkPolicy egress-internet-https allows paging and nine other workloads egress to any public host on 443/TCP
Manifest and live cluster agree. Both sides shown; Atlas doesn't pick one.
valid since 2026-10-05recorded 2026-10-08 09:12
the decision is an example
04 Ask your system Atlas · in development example
On a call · 12:04sharing: InOrbit Atlas
SESales engineeryou
CTCustomerCTO
webcheckoutpaymentsledger · down
CUSTOMER ASKS
What breaks for customers if the ledger goes down?
ATLAS ANSWERS, WITH SOURCES
Checkout can't complete payments.
It calls the ledger on every order.
static resolutionruntime observation
ADR-0017 caps retries at 3, so customers see an error in about 2 s.
ADR-0017
Refunds queue and recover later.
k8s.manifest
Not known yet: whether the nightly export needs it.
no observer covers batch jobs
Every answer cites its evidence. What isn't known is said, not guessed.
05 Verify preview real run · 2026-10-04
$ mise run verify:before 251
PASS http_healthz 206.5 ms
PASS grpc_protocol_health 115.0 ms
44 passed, 0 failed
# 39 minutes later, after the change rolled
$ mise run verify:after 251
PASS http_healthz 308.0 ms
FAIL http_mcp_tools 8.3 ms 401 without resource_metadata
43 passed, 1 failed
VERDICT: FAIL
Posted on pull request #251.
Three claims held, one check broke, and the record says so. A verdict only covers what was tested.
06 Install and connect
$ brew install inorbithr/tap/iohr
✓ iohr 0.1.0 installed
$ iohr login
✓ signed in as you@company.example
$ iohr ext install agent
✓ agent enrolled with a one-time code
✓ outbound only · nothing opens inbound
command line · liveagent · previewthe agent is on every plan, Free included
CONNECTIONS · ONLY THE ACCESS EACH ONE NEEDS
GitHublive
Kubernetes, via the agentin dev
incident.ioin dev
Claude, via MCPpreview
Other AI assistants, MCPcoming
Grafanacoming
Lokicoming
Datadogcoming
PagerDutycoming
01Monitorlive
02Respondpreview
03Understandin development
04Verifypreview
EVIDENCE
↺ the evidence feeds the next turn
Every system you run gets its own loop.
InOrbit the engineering platform
Understand your system.
Detect what breaks.
Prove what fixes it.
Request access →inorbit.hrearly access · partners
0:00 / 0:00AI voice Narrated by an AI voice (Bella, ElevenLabs).

Chapters

    Space play or pause · ← → 5 s · 1 to 9 chapters · C captions · F full screen

    Chapter 8 of the tour: Install and connect · 1:58Watch the whole tourRead the transcript

    02What it does todaypreview

    Each line says how far it is built today. Live means anyone with access uses it; preview means it runs for admins and partners or as a pre-release; coming means it is written down and not built yet.

    What it does today

    • preview

      Checks where your systems are

      HTTP (status, latency, certificate expiry), TCP, TLS and gRPC health, for monitors and for checks run on demand. Hosts outside your verified domains are refused before a job is sent.

    • preview

      It only dials out

      One WebSocket to the platform's API host, kept open; nothing listens on your side, so there is no inbound firewall rule to ask for. When the connection drops, work stops.

    • preview

      Declared in one file

      A checks.toml says what it watches; the platform turns each check into a monitor managed by that agent, with its category and tags. It reports its own machine so a devops team sees where and under which rules it runs.

    • preview

      A binary a security team can check

      Built from public source in inorbithr/dataplane, every artifact signed keyless at its tag with SLSA provenance and a CycloneDX SBOM. Linux and macOS, amd64 and arm64, a container image and a Helm chart.

    • in development

      Reading your system for Atlas

      Observers for Kubernetes, Envoy, cargo, network policy and the host are built and not in a release yet. Load and faults on your side come later and are refused until then.

    03How it works

    The console decides what should happen; the agent does it where the systems are and reports what happened. Your local policy file is checked last, on your machine, and it wins.

    How it works

    01EnrollA one-time token from the console, valid an hour.live
    02The agentMakes its own key; dials out over one socket.preview
    03Your policyA local file that decides what runs.preview
    04Checks and monitorsRun inside your network.preview
    05Evidence for AtlasObservers built; no release yet.in development
    One connection out; the work comes down it and the results go back up
    04In the consoleExample data

    An agent as the console lists it, and the file that declares its checks.

    In the console

    agent-0 · iohr-agent 0.1.0-alpha.7 preview

    online · 4 checks · last seen 2 s ago · linux/arm64 · environment staging

    The checks it declares · checks.toml

    [[check]]
    name = "orders-api"
    surface = "http"
    target = "https://orders.internal.example/healthz"
    every = "30s"
    expect = { status = 200, max_ms = 500 }
    fail_after = 2
    category = "availability"
    
    [[check]]
    name = "orders-tls"
    surface = "tls"
    target = "orders.internal.example"
    every = "1h"
    expect = { valid_for_days = 14 }

    Example data

    Drawn from the console's own layout. The services, times and numbers are made up for the example.

    05Proof and links

    Every claim on this page has its evidence: the documents that define it, the docs that say how to use it, and the API it runs on.

    Proof and links

    Documents

    Not on the public RFCs host yet, so named here without a link.

    API

    • RESTliveMake an enrollment, list, read, revoke and delete agents, and run a check through one. GET /v1/accounts/orgs/{org_id}/agents
    • iohrpreviewiohr ext install agent, then iohr agent init and iohr agent run.
    • MCPcomingNot an MCP tool yet: an assistant cannot enroll or run an agent today.

    The evidence rule: a model saying it succeeded is never evidence. What counts is what was measured, by what, and when.

    Your data, your call

    The agent sends timings, status codes and verdicts. Never a request or response body, a header value or a secret: a credential is read from your vault or cluster at the moment of a call and forgotten after.

    Logs record who did what and the outcome, never content. Self-hosted models by default; a third-party model provider needs a data processing agreement before it sees anything of yours. InOrbit is not certified: no auditor has attested its controls yet, and the known gaps are listed.

    The company's facts, controls and gaps →

    06Questions

    Questions, answered plainly

    Do we have to open a port?

    No. The agent opens one outbound HTTPS connection and keeps it; nothing listens for the internet on your side.

    Can we host the images ourselves?

    Yes. The container image, the Helm chart and the packages are signed artifacts you can copy into your own registry and verify there before anything runs.

    When does it update?

    When you say so. Installed through iohr it is pinned in iohr-ext.lock and nothing changes until you run iohr ext upgrade; with Helm you pick the chart version.

    Why preview?

    Every release so far is a pre-release, and the part that reads your system for Atlas is not in a release yet. It runs in production on our own platform first.