Operational memory for everything you build

Git remembers the code.
DevHub remembers how it runs.

Your coding agent can build and deploy it. DevHub shows where it runs, how it is monitored, what safety and cost evidence exists, and how to recover it across every laptop, server and cloud.

2projects
3services
0reachable
0needs action
Developer laptopmacDevHub serverlinuxManaged cloudcloud

Operational catalog

2 visible projects

Waiting for live probes

Portfolio guardian

What needs a decision before it becomes a surprise?

Catalog-only review of ownership, monitoring and recovery evidence. Unknown is a question to investigate, not a claim that production is broken.

2/3
with a Passport
2
with expected evidence gaps
0
stale evidence items
Review with your agent →Read-only · no magic score · no network scan
platform · native

DevHub

also: Service registry

Active

Self-hosted operational map running with a fictional demo catalog.

product · native

Example App

also: Demo application

Active

Fictional application showing local and managed services.

One operational contract

Everything you build stays findable, trustworthy and recoverable.

DevHub does not care whether a service runs in Docker, systemd, a cloud platform or a terminal on another laptop. It keeps the context that disappears first: ownership, location, lifecycle, trustworthy status and the next safe action.

01

Find it

Search every application, API, worker, bot, database and internal tool from one reviewed catalog.

02

Trust it

See whether a state comes from a live probe, a timestamped report or catalog-only knowledge. Unknown never pretends to be green.

03

Operate it

Open the right entry point, move to the right device, copy reviewed recovery guidance or hand the exact context to your coding agent.

04

Recover it

Keep monitoring, backup, restore, rollback, security, ownership and cost evidence together without pretending unknown means safe.

Web appsAPIsWorkersBotsDatabasesLocal toolsManaged services

Codex handoff

One request. DevHub handles the rest.

With the DevHub plugin installed, open a Codex task beside any project and say what appeared or changed. Paste the universal request only when you want the full workflow spelled out.

  1. 01

    Open the project taskAny Codex task that can inspect the project files and runtime.

  2. 02

    Say what changedFor example: “new admin”, “URL changed”, or “this moved to another Mac”.

  3. 03

    Review the proposalCodex queries DevHub through MCP, chooses the safe boundary and shows the catalog diff.

devhub-agent-request.txtuniversal
Use the DevHub plugin and its read-only MCP tools to register or update this project and its runnable services in the configured registry.

Search DevHub for an existing project and services before proposing anything. Then inspect the current project locally to infer the services, URLs, host, runtime, operating mode, health endpoints and safe start/restart/log guidance. Propose an App Passport with a non-secret owner, data classification, cost model, deployment revision and critical dependencies, plus evidence for monitoring, backup, restore, rollback, security review, privacy, ownership and cost. Mark anything you cannot verify as unknown rather than passing. If a record already exists, update it instead of creating a duplicate.

Use native registration only when we control the repository and the metadata belongs there; otherwise use a private DevHub overlay without changing the project repository. Keep separate machines or independently operated instances as separate services. Never put secrets in the catalog.

The MCP interface is read-only. Locate the registry checkout from the workspace or repository instructions and make catalog changes through a reviewed branch or pull request, never through a hidden control action. Ask me only for facts you cannot discover. Present the manifest diff, validate and test it, then publish the reviewed change and tell me how to open, start or recover the service.

If the DevHub tools are unavailable, tell me that the DevHub plugin needs to be installed; do not require a checkout at a machine-specific path.