Yeling, I had the same question earlier this year -- how can I set up a node-red "Editor" for drawing process flows, without having a "server" runtime working behind the scenes...
Nick, please correct me if I'm wrong, but from what I understand, the first "deliverable" will be separated packaging for the editor and the runtime -- not usable applications and/or tooling that allow someone to execute the editor or server flow independently. Those will naturally follow, but the repackaging is needed first to allow this community to build those 3rd party applications and tools.
In the meantime, I believe I've found a simple and relatively non-invasive way to "disable" the runtime server (I know, I know -- why would anyone work to undo all the good stuff going on in the server?!? but that's what the customer needed).
Since I am already running my node-red instance behind an nginx reverse proxy, it was easy to "redirect" the internal http requests for retrieving/saving the content of the editor flows file. In my case, the /flows GET or POST request from the client-side Editor is proxied to an external web server, which handles the flow JSON string outside of node-red. This means that the runtime server never receives any updates to the flow contents. So essentially the runtime is always running, but it's working with an empty flow. This also means that two individuals running the same Editor instance in different browsers are not pushing updates to each other's editor session -- so if you need to have multiple users working on the same flow content, this may not be a solution for you.
The other potential solution is to replace the built-in storage implementation with your own. Check out the docs for the storage API -- you can also look at the current filesystem implementation that's included with node-red, or the bluemix version based on MongoDB. Although now that I think about it, that doesn't give you a no-op runtime... but there ya go
