kneo-studio

Turn an n8n workflow export or a Dify app export into a governed Kneo agent spec — and be told, in detail, what could not be carried across.

This is the distributed package: a FastAPI backend-for-frontend that serves a React SPA from inside the wheel. pip install kneo-studio gives you the whole application, with no container and no database service to run — SQLite is created for you.

$ pip install kneo-studio
$ kneo-studio

It binds loopback and, by default, needs no login: your own machine is the default deployment. The same artifact runs for a team on a shared host under a login mode, and refuses to bind a routable address without one — an unauthenticated shared instance would make every request the local owner, with full rights over the project tree.

What it is for

Studio's contract is that it tells you what it could not convert. An n8n workflow or a Dify app uses constructs Kneo has no form for — output parsers, memory, retrieval, inline secrets, branch predicates, prompt variables — and the failure mode worth designing against is not a crash but a spec that looks complete and quietly does something else. Every such construct becomes a gap card the developer has to see. The blocking ones refuse export until they are resolved, and the manual ones until someone acknowledges them — which is why a clean import started by a webhook, schedule or chat trigger still asks for one acknowledgement, for that trigger, before it hands you a file.

That is why an import can succeed and still refuse to hand you a file.

Documentation

• Quickstart
• What imports, and what does not — four n8n example workflows and the exact gaps each produces, measured rather than estimated; start with chat-agent.json, the clean one
• Importing a Dify app — the support matrix: every app mode and node type, converted or carded
• Changelog
• Repository

Studio talks to a kneo-serv platform through kneo-client; it holds no platform logic of its own.

Licence

See LICENSE.