CLI

One tool. Two ways to run it.

Oynix installs as a single command. Pick the build that fits: the local CLI runs entirely on your machine, and the server CLI runs a shared engine your whole team queries from. The commands you learn carry across both.

Local

The local CLI

Runs entirely on your machine. One person, no account, no Docker or server.

  • The engine auto-starts. You rarely type it.
  • Your graph stays on your machine, at ~/.oynix/local.
  • Start key-free with a structural graph. Add a model later in the Models UI and re-index.
  • A lean menu: init, connect, graph, status, doctor.

Best for trying Oynix, solo work, or a private repo on your laptop.

The whole flowinstall → oynix init → oynix connect → oynix graph → ask in your agent
Server · coming soon

The server CLI

A shared team engine. Roles, workspace keys, and a web console, on a Docker stack or your own server.

No installer yet. Drop your email and we'll tell you when it ships.

  • Runs the Docker engine: graph, indexer, and ingestion together.
  • Sign in, bind a workspace key, add members with roles.
  • One shared memory the whole team queries from their agents.
  • Ask from your agent or from Slack, plus architecture checks as a CI quality gate.
  • Governance, keys, and members live in the web console.

Best for a team that wants one shared memory, access control, and CI.

What setup will look likeInstall, sign in, create the workspace, start the engine. The exact commands are not final, so we are not publishing them yet.
GoalLocalServer
First-time setupinit → connect → mcp setupSign in, create the workspace, start the shared engine
Add code and docsThe connectors page (oynix connect)The connectors page, shared across the workspace
Set a provider keyModels UIOne workspace key, held once for the whole team
Ask about your codeIn your agent, over MCPIn your agent, in Slack, or in the console
See the graphoynix graphThe graph view, on the shared engine
Stay currentengine updateUpdates in place, data preserved
Quality gate in CInot in localArchitecture rules enforced on every pull request
Team keys and membersnot in localRoles and members in the web console
The wikinot in localA handbook written from the graph, with citations

The menus stay small on purpose. Adding code lives on the connectors page, keys and roles live in the web console, and answers come from your agent. Every command, flag, and output is written up in the full reference.