Open-source project
alfredxw/denova avatar
alfredxw/denova

Denova: a Go desktop-style workspace where novel writing and AI roleplay share one project store

An AI creative platform for novel writing and AI generated RPG, with built-in support for AI agents, Skills, subagent workflows, automations, image generation, and version control. 一个面向小说创作与 AI 角色扮演游戏的 AI 创作平台,内置支持 AI Agents、Skills、Subagent Workflows、Automations、图像自动生成与项目版本管理等核心能力

726 stars119 forksGoApache-2.0

At a glance

What is it?
Denova bundles Markdown novel drafting, branching interactive fiction, a shared lore database, AI agents with Skills and SubAgents, image generation and local version control into one Go plus web application. It is worth a look if you maintain long-lived fiction settings; it is not a drop-in replacement for a general writing editor or a plain LLM chat client.
Who is it for?
Adopt Denova if your project is a long-running fiction world where the same character sheets, world rules and style presets need to feed both drafted chapters and branching game scenes, and if you are willing to run a Go and Node toolchain or install a release binary.
Can I use it commercially?
Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 1 day ago.
What is it written in?
Mainly Go, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

The problem Denova is aimed at: settings that outlive a single draft

Most writing tools treat a novel as a pile of documents. Denova treats it as a project with a structured lore layer. The README describes a database that manages characters, locations, factions, world rules and narrative style, and states that the same stable settings serve both the writing flow and the game flow. That is the actual claim being made: you define a character once, and both a drafted chapter and a branching roleplay scene can read from it. The target user is someone maintaining a world over months, not someone writing a one-off essay. The README frames it as suitable for projects that need to maintain settings long term, revise repeatedly and accumulate content. The second audience is interactive fiction authors. Denova has a first-class game entry point with player input, plot branches, story line switching, action suggestions, character and world state, rule checks and adjustable plot planning. The README notes that both entries share the lore database, presets, Skills and version management, while chapter progress and game state stay separate so that temporary state in one does not bleed into the other. That separation is a design decision worth noting, because it implies the two flows are intentionally not unified into one state machine.

Architecture visible from the repository: Go backend, web frontend, local project storage

The primary language is Go, and the README lists Go 1.26.6+ and Node.js 22.13+ as build requirements, along with pnpm, ripgrep and Bash. That combination points to a compiled backend serving a web frontend rather than a native desktop shell. The default development addresses confirm it: the frontend runs at http://localhost:5173 and the backend at http://localhost:8080, which matches a Vite dev server talking to a Go HTTP server. The README also states that when running from source, the QR code and connection link use the web/dist build artifacts served by the backend port, and that you should run pnpm --dir web build and restart the backend after the first use or after updating the frontend. So the production shape is a single Go process serving a built frontend, with the Vite entry kept for development hot reload. Version control is described as local: save local versions, view diffs, restore historical files, and review or undo agent modifications to the workspace. Nothing in the material indicates a Git-backed or remote-synced history, so treat it as project-local snapshots. Agents are described as able to read project content, call tools and modify files, with all important changes still inspectable, revertible and recoverable. The safety story here rests on the version layer, not on sandboxing language, which the README does not discuss.

Getting it running: install script, source bootstrap, and the config that actually matters

The fastest path on macOS and Linux is the install script: curl -fsSL https://raw.githubusercontent.com/alfredxw/denova/master/scripts/install.sh | sh, after which you run denova. Windows users and anyone preferring a manual install download the platform archive from GitHub Releases and run denova.exe. The README advises choosing a Release for stable use because the master branch may contain unreleased changes. If you build from source, the sequence given is git clone https://github.com/alfredxw/denova.git, cd denova, corepack enable, then ./scripts/bootstrap.sh. On Windows the README says to run these in Git Bash or WSL. Development commands are split: ./scripts/bootstrap.sh fe, ./scripts/bootstrap.sh be, and ./scripts/build.sh. Configuration is done in the settings page rather than a config file, according to the README. You add a provider connection first, then select or enter a model and test the connection, and one connection can be reused across multiple models. Language models support built-in providers and custom compatible endpoints. Image models support OpenAI, xAI/Grok, Volcengine Seedream, Google Gemini Image, ComfyUI Workflow and custom endpoints. The first-run flow is: add an API key and model name, then create or import a book or open an existing project directory, then start from Writing or create an interactive story line from Game. Image model configuration is only needed when you want generated images.

Remote access and the mobile story, including the HTTPS caveat

Denova is not limited to the machine it runs on. In Settings, Access, you can enable LAN access, set a username and password, and restart, after which other devices log in using the address shown on the page. The local machine can also generate a one-time login QR code and link valid for 5 minutes; a phone on the same LAN scans it and is logged in. The browser session is described as lasting 30 days, and refreshing or restarting the service does not require re-entering the password. There is a logout option in settings. Mobile browsers can add the page to the home screen, and the README says the layout is phone-adaptive and PWA-capable. The caveat is explicit in the README: when deploying over the public internet or a domain, use a reverse proxy such as Caddy or Nginx to provide HTTPS, to avoid transmitting login credentials in cleartext. That is not boilerplate caution; the 30-day session cookie makes the transport question more consequential than it would be for a per-request token. The one-time QR flow also depends on the backend serving built frontend assets, which is why the README ties it to the pnpm --dir web build step.

Where Denova is the wrong tool, and what the documentation leaves open

Denova is a workspace, not a library. If you want to drive an agent pipeline from your own code, the README offers no API surface, no SDK and no server mode description beyond the local HTTP ports used by the frontend. There is nothing in the supplied material about authentication for programmatic clients, rate limits, or headless operation. A team that needs CI-integrated generation should look elsewhere or plan to reverse-engineer the backend. The second limitation is upgrade friction, and it is documented rather than implied. The README states that before upgrading from v0.3.3 you should read the v0.4.0 update and data migration notes in CHANGELOG.md, and that old global automations must be recreated inside the project, with some model and context options needing to be set again. That is a real migration cost, not a footnote. Third, the project is labelled Beta at v0.4.5, and the release cadence in the supplied list (v0.4.3, v0.4.4, v0.4.5 within a few days in September 2026) suggests rapid iteration. Rapid iteration plus a local version store plus agent file writes means you should understand the restore path before letting an agent loose on a manuscript. Finally, the README does not describe how the lore database is stored on disk, whether it is plain text or a database file, or how conflicts are handled if two devices edit the same project. Those gaps matter for anyone planning multi-device use.

How it differs from a general writing editor and from a chat client

Compare Denova to a conventional Markdown writing editor such as Obsidian or Zettlr. Those tools give you documents, links and plugins, and they stay out of the generation loop. Denova puts the model inside the workspace: agents read the current selection, project files and the lore database, can call tools and modify files, and can be extended through Skills with optional SubAgent collaboration across multiple sessions. The trade is that you now depend on provider configuration, on image endpoint compatibility and on a Go plus Node runtime, none of which a plain editor asks of you. Compare it instead to a chat client plus a folder of notes. A chat client has no concept of chapter progress, no story line branching, no rule checks and no diff-and-restore layer over its own edits. Denova's version management is the piece that makes agent file writes tolerable, and it is the piece a chat client lacks entirely. The narrower comparison is against tools that do interactive fiction only. Denova's distinguishing choice is that the lore database and presets are shared between the novel and game entries while progress and game state stay separate, so a world rule written for a chapter is immediately available to a scene. Whether that sharing is well implemented is something only hands-on use will tell you; the README asserts the design, not its ergonomics.

Licence, maintenance cost, and what to check before you commit

The licence is Apache-2.0, which permits commercial use, modification and redistribution provided you keep the notices and state changes, and it includes a patent grant. It also means there is no copyleft obligation on your own novel text or game content, though the usual caveat applies: this is a description of the licence text, not legal advice, and if you plan to redistribute a modified Denova you should read LICENSE and NOTICE handling yourself. Maintenance cost has two parts. The runtime cost is a Go binary plus a built web frontend, which is light, but the build path requires Go 1.26.6+, Node.js 22.13+, pnpm, ripgrep and Bash, so source builds are not trivial on a locked-down machine. The upgrade cost is the more serious one: the v0.4.0 migration note about recreating global automations inside projects and re-setting model and context options means version jumps can require manual reconfiguration. Pin to a Release rather than tracking master if you are mid-manuscript. Before adopting, verify three things in order: read CHANGELOG.md for the migration steps that apply to your current version, confirm your language and image providers appear in the supported list (built-in or custom-compatible endpoints for language; OpenAI, xAI/Grok, Volcengine Seedream, Google Gemini Image, ComfyUI Workflow or custom for images), and test the local version save and restore on a throwaway project before pointing an agent at real chapters.

Editorial conclusion

Adopt Denova if your project is a long-running fiction world where the same character sheets, world rules and style presets need to feed both drafted chapters and branching game scenes, and if you are willing to run a Go and Node toolchain or install a release binary. Do not adopt it if you want a plain Markdown editor with no model configuration, or if you need a documented public API for programmatic access, because the README describes a user-facing workspace, not a service contract. Verify before committing: read CHANGELOG.md for the v0.4.0 migration notes if you are coming from v0.3.3, confirm your image provider is one of the six listed endpoints, and check that your machine meets Go 1.26.6+ and Node.js 22.13+ if you intend to build from source.

Official sources

  1. alfredxw/denova on GitHub
  2. License: Apache-2.0
  3. Project website
  4. README
  5. Releases
Community notes

Community notes