Self-managed and operated

nyxory is the operations layer your software runs on: its agents deploy it, keep it healthy, and re-ship it. You build it, nyxory runs it. How your software gets there is up to you — both paths share one cookbook and one set of primitives.

Self-managed — your coding agent, over MCP

Your own coding agent — Claude Code, Cursor, Codex, or any MCP client — connects to nyxory and drives the deploy from your chat. You keep the reasoning; nyxory hands your agent the primitives and runs the result. This is the path every page in these docs describes, and it works today.

• You pay tokens to your model vendor; nyxory provides the platform and runs what you ship.
• Best when you already live in your coding agent and want it to handle deploys too.

Operated by nyxory

Beyond the deploy, nyxory’s operations agents run the production side — the work that comes after “it’s live”: diagnosing, re-shipping, patching. This is the heart of the platform; see Platform → Agents for the full picture. What your coding agent hands over, nyxory operates.

The deploy surface

Either way, the work lands on a real target environment — the deploy surface. Your coding agent drives it over MCP; nyxory provisions and operates everything inside it, so you never touch the Kubernetes underneath:

Where that environment lives is your choice — from shared, the default, to your own cloud:

Same cookbook, same primitives, same operations agent across all three — only the isolation and the underlying account change. Full detail on the pricing page.

Same cookbook either way

Both paths retrieve recipes from the same source and call the same primitives. The cookbook is the moat — not which agent drives it.

Next: How nyxory works →