Orbit is a work platform for software and business teams. Orbit (work tracking), Forge (code and CI/CD), Pulse (observability), Folio (knowledge) and Lumen (an AI assistant) run as one product with one account and one project membership model. Each company works on its own address, with its data isolated at the database level.
From a work item to a postmortem, and a question about both
Each link below is a built, tested behaviour. Where a link is still in development or planned, it carries a badge.
1Work itemPlanned, ranked and assigned on a boardOrbit
2Merge requestKeys in branches and commits link the codeOrbit Forge
3PipelineBuilt and tested on your own runnersOrbit Forge
4DeploymentRecorded on the work it shippedOrbit Forge
5MonitorPulse compares errors and latency before and afterOrbit Pulse
6Alert files a bugOne Orbit bug per problem, synced both waysOrbit Pulse
7PostmortemAn incident becomes a Folio page with tasksOrbit Folio
8Lumen answers"What broke?" with sources you may seeOrbit Lumen
Forge and Orbit: code lives with the work
A repository belongs to an Orbit project and inherits its members. Put a work item key in a branch, a commit or a merge request and the link is made for you.
Keys in branches, commits and merge requests link to the project’s work items
Deployments are recorded on the work they shipped
Closing patterns and smart commits run as their actor through the workflow
GitHub and GitLab webhooks for code that lives elsewhere In development
Forge and Pulse: every deploy is watched
Pulse records each Forge deployment, compares error rate and latency before and after it, and points at the commits behind a new error.
Stack frames and spans open the file at the deployed commit
Deployment markers and release health on charts
Suspect commits with their merge requests and linked work
Pipeline and job duration and failure rate as metrics for monitors
Pulse and Orbit: one bug per problem
An error group or a monitor files an Orbit bug through Orbit’s own create path, as a person, and keeps it in sync in both directions. A recurring problem comments on the existing bug.
Closing the bug resolves the error. A regression reopens it
One open bug per monitor and group, with a comment on re-trigger
An Observability panel in the work item shows live counts
Incident follow-ups become Orbit tasks
Pulse and Folio: runbooks that know the state
A runbook page shows the live state of every monitor that points to it. When an incident closes, a postmortem page is generated from its timeline.
Runbook pages with live monitor state
Postmortems from an incident, linked back to it
Follow-up actions tracked on the page as Orbit tasks
Embedded Pulse charts for a chosen period
Folio and Orbit: pages and work, both ways
A key in text becomes a live link with status and title. Select text, create a work item from it, and the page and the work item keep a link to each other.
Embedded work lists by filter, respecting the reader’s permissions
Related pages appear inside the work item
Sprint review pages generated from the sprint
A page goes stale when a linked work item closes or changes
Folio and Forge: docs next to the code
Show a file or line range from a repository at a pinned commit, and sync a Markdown folder into a space. Changes to managed pages go through merge requests.
Code at a pinned commit, with "show latest" when it moved
Release notes generated from a deployment
Merge request and pipeline status chips inside a page
A mentioned Forge file that changes flags the page for review
Lumen over all of it: "What broke?"
One cited answer from the incident, its monitors, the deploy and its commits, the related work items and the Folio runbook. Lumen reads each product through its API as you, so it never shows what you may not see.
Read tools for Orbit, Forge, Pulse and Folio
Find everywhere works with no model at all
Changes are cards you run in your own browser
Lumen on every company address is needed before launch Planned
One identity
One sign-in, one permission model
Forge, Pulse, Folio and Lumen resolve the same Orbit session and check your current project role on every request.
One session
Every product reads the Orbit session. Sign in once, and every product knows who you are.
Project roles checked on every request
A repository, a space and a telemetry project belong to an Orbit project and inherit its members.
Product access per person
Choose, in one people directory, who may open Code/CI, Observability, Knowledge and Lumen.
Your company, your address
Isolation you can test
Each company works on <company>.orbit.inortix.com. The site is taken from the host name, and the data sits behind PostgreSQL row-level security on all 139 site tables. The browser test suite runs two company sites side by side with the same project keys, and each sees only its own.
Every API, search, export and live event excludes other tenants
Orbit’s cloud runs on servers in Hetzner’s Helsinki data centre, Finland (EU)
Forge, Pulse, Folio and Lumen answer on every company address Planned Today they answer on the default site only, and separating them per organization is needed before launch.
acme.orbit.inortix.com
WEB-12WEB-13API-7
row-level security
example.orbit.inortix.com
WEB-12WEB-13OPS-3
One quota, one bill
How plans will work at launch
Pulse data, within its retention
Forge repositories, packages and artifacts
Folio files
Orbit attachments
Illustration of the planned quota.
Plans will give each organization one storage quota for all four kinds of data, one maximum file size and one bill. Planned Per-organization quotas and billing are still being built, and limits are not yet set per organization. There is no per-seat telemetry: who sees telemetry is decided by project permissions.
Every write appends history and an outbox row in the same transaction. Workers de-duplicate and resume after a crash.
Typed outage errors
A PostgreSQL or Redis outage answers a typed, retryable error. It is never a fake success, and committed work survives.
Backups with restore drills
Backups cover the database, attachments and configuration. A drill checks row counts and every attachment hash.
Integrations and API
Open by design
A versioned REST API, tokens you control and manifests that let a product join Lumen without code changes.
Versioned REST API with OpenAPI 3.1
/api/v1 with typed error bodies, paging headers, rate limits and a public OpenAPI document.
API contract tests on every release
A committed route list is compared with the server, and responses are checked against the schemas.
Pulse OTLP/HTTP intake
Logs, traces and metrics with project ingest keys.
Forge Git over HTTPS and SSH
Scoped, expiring, hashed project access tokens and SSH keys.
Your own product through a manifestPlanned
A product publishes a manifest and Lumen reads it, with no code changes. Joining a new product is a Lumen setting that Orbit controls, so it is not available on Orbit’s cloud yet.
Outgoing webhooksIn development
Signed HMAC-SHA256 event subscriptions with filters, rotation, retries and a delivery log.