# HeliosGen: a Tauri desktop app for wiring image and video models into node graphs

> Next.js and React driving an infinite canvas, SQLite on local disk, and a model list that spans OpenAI, Google, ByteDance, Kling and X. The local part is real, the no-subscription part has a footnote.

**SegFault42/HeliosGen** — 🏆 Self Hosted Gen AI desktop app. Free alternative to Higgsfield, OpenArt, Freepik....

- Repository: https://github.com/SegFault42/HeliosGen
- Website: https://helios.sdd.cash/
- Stars: 2,587 · Forks: 308
- Language: TypeScript
- License: not declared
- Published: 2026-10-07 · Updated: 2026-10-07 · Language: en
- Canonical page: https://hysenlabs.com/projects/segfault42-heliosgen

## What HeliosGen is, and where its boundaries sit

HeliosGen is a desktop application for building generative media pipelines visually. The repository description calls it a self hosted Gen AI desktop app and names Higgsfield, OpenArt and Freepik as the hosted tools it is an alternative to. The README puts it more plainly: a free and open source visual AI workflow builder for image and video generation, with an infinite node-based canvas, multi-model generation, reference images and automation chains.

The interesting structural choice is that this is not a native app in the usual sense. The tech stack table lists Tauri 2 in Rust for the desktop shell, Next.js with React and TypeScript for the app itself bundled as a Node sidecar, SQLite for the database, local disk for storage, and kie.ai as the AI backend. The dependency list in `package.json` confirms it: `@xyflow/react` for the canvas graph, `next` at 16.2.3, `react` at 19.2.5, `zustand` for state, `sharp` for image work, `motion` for animation, `lucide-react` for icons and `undici` for HTTP. So the interface is React rendered inside a native shell, talking to a Rust host that owns the filesystem.

The homepage is helios.sdd.cash. The repository has no license field and no LICENSE file, which is worth flagging given the README's opening claim of being free and open source. If you intend to build on the code rather than just run the binary, that gap needs resolving before anything else.

One number to reconcile early: `package.json` says version 1.2.1, while the newest tagged release is 1.2.0. The repository is not archived, with 11 open issues, 2,275 stars, 278 forks and a last push on 2026-09-17.

## Installing: macOS only, unsigned, with a clear escape hatch

The README is unusually direct about what is missing. Of the three desktop platforms, only macOS has a build. The download table marks Windows and Linux as looking for a contributor to build and submit, and the note underneath explains why: Tauri does not cross-compile, so each platform has to be built on that platform. The filename convention is given for the one build that exists, as `HeliosGen_<version>_aarch64.dmg`.

Note the architecture qualifier. The macOS build is Apple Silicon only, so an Intel Mac has no prebuilt artifact here.

The app is not code-signed, and the README gives the two workarounds. On macOS, right-click the app and choose Open once, or clear the quarantine attribute with `xattr -cr /Applications/HeliosGen.app`. On Windows, if you build it yourself, SmartScreen needs More info then Run anyway. Building from source is a single command on whichever OS you want to target, gated behind a version check: `npm run desktop:build`.

The `scripts` block in `package.json` shows what sits behind that. The desktop build runs a version check script first and only then invokes tauri build with `CI=true`, which suggests the version mismatch between `package.json` and the release tags is enforced somewhere in there. There are also desktop dev, check-version and icon scripts. Note that `package.json` declares pnpm 9.15.9 as its package manager even though the build command is written with npm, and the lockfile in the tree is `pnpm-lock.yaml`, so either works but they are not interchangeable.

## First run, the local database, and what happens when you delete it

First launch is three steps: open the app, go to Settings then API Keys and paste a kie.ai key, then generate. The README emphasizes that nothing requires an account with HeliosGen itself, no server and no cloud setup.

What stays local is concrete. Generations, uploads, folders, workflows and settings all live in a local database, and media is written to a local folder. The README gives the exact per-platform paths: `~/Library/Application Support/cash.sdd.helios.desktop/` on macOS, `%APPDATA%\cash.sdd.helios.desktop\` on Windows, and `~/.local/share/cash.sdd.helios.desktop/` on Linux. Delete that folder and the app resets. That is a clean answer to a question most local-first apps leave vague, and the bundle identifier in the paths matches the homepage domain, which suggests this is a rebranded internal tool rather than a purpose-built open source project.

The `.env.example` file reinforces the same point and adds detail. It opens by stating that HeliosGen is a local-only desktop app, that the packaged build sets everything it needs at runtime, and that you only need the file for `pnpm dev` in a browser, with every value optional. It defines `KIE_API_KEY` as an optional fallback, `AZURE_API_KEY` for routing GPT Image 2 through Azure AI Foundry, and `NEXT_PUBLIC_DEBUG` for verbose client logging. So there are two paths for the image model: the credit reseller, or your own Azure deployment.

## The model list is the substance, and it spans five vendors

HeliosGen's differentiation from a single-purpose generator is the breadth of the model menu. For images it lists GPT Image 2 from OpenAI, four Google variants named Nano Banana and Nano Banana Pro, Seedream 5.0 Lite and Pro, Z-Image from Z-AI, and Grok Imagine from X. For video it lists Veo 3.1 in Lite, Fast and Quality variants plus Gemini Omni Video from Google, Kling 3.0 with Turbo and Motion Control 2.6 and 3.0, Seedance 2.0 with Fast and Mini from ByteDance, Grok Imagine and its 1.5 preview from X, and HappyHorse from Alibaba.

Read that list as a routing table rather than a capability claim. The app is not running these models; it is a client that formats requests and collects results. Which is exactly why the multi-model pipeline feature matters. Parallel and sequential execution are both listed, so a workflow can fan four models off one reference image and compare, or run a chain where a later step conditions on an earlier step's output.

The rest of the feature list covers the canvas mechanics: an infinite node-based canvas, drag-and-connect wiring, reference image support and real-time generation history. Two screenshots deserve a specific mention because they describe UI affordances the feature list omits. There is a native JSON prompt preview, which matters if you want to see the request body a model will actually receive, and an AI prompt improvement assistant, which is the one place the app applies a model to your text rather than to your media. Whether that assistant earns its place depends on how much you trust rewriting before it reaches a paid endpoint.

## Routing GPT Image 2 through a Codex subscription instead

The optional Codex CLI integration is the most unusual feature in the project and the one worth understanding before you dismiss it. Instead of spending kie.ai credits on GPT Image 2, HeliosGen can call a ChatGPT subscription you already pay for, through a third-party tool called `codex-imagegen-cli`. The app finds `codex` on your PATH automatically and, if it is missing, shows the feature as NOT CONFIGURED while everything else continues to work. That failure design is worth noting: a missing optional backend degrades one model rather than blocking the app.

Setting it up takes three installs plus a login. The CLI itself, on macOS:

```bash
brew install codex
```

or cross-platform:

```bash
npm install -g @openai/codex
```

Then the image generation wrapper:

```bash
git clone https://github.com/jdmnk/codex-imagegen-cli.git
cd codex-imagegen-cli
uv sync --dev
uv tool install -e .
```

That produces a `codex-imagegen` binary that must be on your PATH. Requirements are a ChatGPT Plus, Pro, Team or Enterprise account with Codex access, the codex CLI, and `uv` as the Python package manager.

The login step carries a warning with real consequences. Starting a new login, either via `codex login` in a terminal or through the device-code flow in Settings then API Keys, immediately invalidates any existing session on that machine. The CLI clears old credentials the moment a login attempt begins, whether or not it completes. The README's instruction is to start one only when the status badge reads NOT CONFIGURED, which is the correct guard against logging yourself out of a working setup. Once logged in, flip GPT Image 2's provider toggle to Codex CLI under Settings then Image Models, and the badge changes to READY.

## Where the local-first framing needs qualifying

The feature list says 100 percent local and your data never leaves your machine, and the README is careful to attach the caveat elsewhere: HeliosGen now works with kie.ai, and all credits are purchased directly on your own account. The README reframes the benefit as billing shape rather than cost. Credits never expire, there is no monthly reset, nothing is lost, and you own your usage. Every one of those claims is about the kie.ai account you create, not about the app.

The practical distinction is between two different kinds of data. Your workflows, uploads, folders, settings and generation history are local, stored in SQLite and on local disk, and deleting the app data folder erases them. The prompts, reference images and parameters you send to generate something are not: those travel to whichever vendor serves the model, whether that is kie.ai, Azure AI Foundry, or the Codex path. A privacy claim about local storage is not a privacy claim about transmission.

There is also an affiliate consideration. The kie.ai link carries a `ref=25abb3f2236cbff9780ab9c2f84479ec` query parameter and appears in the first-run instructions, so the README's recommended provider is a tracked referral. That is common practice and not deceptive on its face, but it does mean the default routing is chosen for the author's benefit. If you already pay for Azure or for a Codex subscription, both alternatives are in the app and the routing toggle is the whole decision.

Finally, note what the README does not cover. It ends mid-section at a Prerequisites heading with nothing after it, so dependency installation for a source build, Node and Rust versions, and the Node sidecar configuration are all undocumented here. The `.env.example` and the desktop scripts in the tree are where you will have to look, and `DESKTOP.md`, `AGENTS.md`, `CLAUDE.md` and `skills-lock.json` suggest more documentation exists elsewhere in the repository.

## Conclusion

HeliosGen is worth a look if your actual problem is prompt choreography rather than a single image. Most tools ask you to write one prompt and give you one picture; a node canvas lets you keep a reference image wired into four successive generations, which is a different job. What the README's local-first framing does not settle is the credit layer. Your generations, uploads, workflows and settings sit in a local SQLite database and the app makes no account of its own, but every image and video call is billed to a kie.ai account, so the marketing line about no subscription lock-in is a claim about billing shape rather than about cost. The honest gaps are practical: macOS is the only binary available, Windows and Linux need someone to build them, and the README stops right where the prerequisites section starts. Build from source with the desktop build command on your own OS, decide whether a third-party credit reseller fits your threat model, and read the model list first since it is the part most likely to change.

## FAQ

### What is the Helios application?

HeliosGen is a desktop app for building image and video generation pipelines on an infinite node-based canvas, so you can chain prompts, models, reference images and automation steps rather than running one prompt at a time. The interface is Next.js with React inside a Tauri 2 shell, data lives in a local SQLite database, and generations run through kie.ai or, optionally, your own Codex subscription.

### Is Helios open-source?

The README describes it as free and open source, and the full source is in the repository, including the Tauri shell, the Next.js app and the desktop build scripts. What is missing is a license file: the repository has no LICENSE and GitHub reports no license, so reuse rights are not actually granted by anything in the tree.

### Is there a free alternative to Higgsfield AI available on GitHub?

HeliosGen positions itself against Higgsfield, OpenArt and Freepik as a desktop app you build yourself, with no account of its own and no subscription, and the source is on GitHub. The model calls are still billed to a kie.ai account you fund yourself, or optionally to a ChatGPT Codex subscription, so the app is free while the generation is not.

### What is helios ai?

HeliosGen is a self hosted generative AI desktop app for image and video work, built as an alternative to hosted services such as Higgsfield, OpenArt and Freepik. It runs a Tauri 2 shell around a Next.js and React interface, keeps its data in local SQLite, and lists image models from OpenAI, Google, Seedream, Z-AI and X plus video models from Google, Kling, ByteDance and Alibaba.

## Sources

- [Issues](https://github.com/SegFault42/HeliosGen/issues)
- [Project website](https://helios.sdd.cash/)
- [README](https://github.com/SegFault42/HeliosGen/blob/main/README.md)
- [Releases](https://github.com/SegFault42/HeliosGen/releases)
- [SegFault42/HeliosGen on GitHub](https://github.com/SegFault42/HeliosGen)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/segfault42-heliosgen
