Dev Servers

The registry of hosts allowed to do development work, what each is signed to do, and whether that signature verified.

Overview

Dev Servers is the hub of the Quox Dev Suite. It answers one question the rest of the suite depends on: which hosts are allowed to do development work, and what exactly is each one allowed to do?

A dev server is a fleet host whose quoxagent carries a signed dev-mode capability profile. The profile is the authority. A host does not decide it can run builds; the org signs a profile saying so, the agent verifies the signature, and the host then refuses anything the profile does not name.

That is the whole design: capabilities are granted, signed and narrow, rather than assumed.

What a capability is

Each dev-suite member plugin corresponds to a capability the host may hold:

A host holding only dev.register is visible and inert. That is a valid and common state, and the page shows it as such rather than implying the host is broken.

Enabling a host

quox dev enable <hostId> \
  --capabilities dev.register,dev.build,dev.sessions \
  --max-concurrent-sessions 4

This signs a capability profile and delivers it to the host's quoxagent, which verifies the signature before adopting it.

--capabilities REPLACES the set, it does not add to it. Omitting the flag does not preserve what the host already had; it resets the host to dev.register alone. Always pass the complete list you want the host to end up with. This is the single most common mistake with the command, and it silently narrows a working host.

To check a host is genuinely functioning as a dev server rather than merely listed:

quox dev doctor <hostId>

doctor is the honest check. The registry row tells you what was signed; doctor tells you what is actually true on the host right now.

What the page shows

• Every host in the durable dev_servers registry for your org
• Whether each host's signed profile verified, not merely that it was delivered
• Per host, which capabilities are enabled versus available, so the gap is visible
• Capability panels for the members you have licensed, opened from the host row

Capability pills derive from what the agent itself reports holding. A pill is dim when the host does not hold that capability, and dim is the honest state, not a rendering fault.

Limits and honest status

• Read-heavy today. The page is an inventory plus per-capability panels. Granting and revoking capabilities is done with quox dev enable, not from the page.
• Registry is org-scoped. A host appears only for the org that registered it. Cross-org listing was a real defect, found and fixed on 2026-08-19; the handler now fails closed rather than falling back to an unscoped list.
• --capabilities replaces. See the warning above. There is no --add-capability flag yet.
• A verified profile is not a health check. Verification proves the signature; quox dev doctor proves the behaviour. Run both.

For the current per-surface maturity map, see STATUS_AND_LIMITS_DEVSUITE.md in the dashboard repo.