Astrofox 2.0: audio reactive motion graphics in the browser, with an Electron export path

No backend, no account, project files on your disk

Astrofox is described as a motion graphics program that lets you turn audio into visuals. The architectural decision that follows from that description is stated plainly in the README: Astrofox is a client-side Next.js app, projects are opened and saved as local `.afx` files, and there is no backend or auth service required for development.

That single choice has consequences. Nothing you draw leaves your machine through the app's own code path, because there is no server to send it to. The format is JSON underneath, with legacy gzip-compressed `.afx` files still openable, so a project is inspectable with ordinary text tools rather than being an opaque container.

The package manifest matches the story: `"main": "electron/main.mjs"` and `"productName": "Astrofox"`. The web build is a normal Next.js application and the desktop build wraps it, and both talk to the same files.

pnpm dev, pnpm build, pnpm start

The README documents the loop in four commands, and the exact sequence matters because a plugin library copy step runs ahead of the Next.js invocation:

git clone https://github.com/astrofox-io/astrofox.git
pnpm install
pnpm build
pnpm start

The `dev` script is `node ./scripts/copy-plugin-libs.mjs && dotenv next dev --turbo`. That leading script is not incidental: the repository ships an `examples/plugins/` directory and a `loaders/` directory, so plugin libraries have to be staged into the app before the dev server or the build sees them. A bare `next dev` will not reproduce the same tree.

Note also `dotenv` in front of the dev command. Configuration is read from an environment file, and the README does not enumerate the variables, so a fresh clone may need a local env file that the repository does not describe. Linting is handled by Biome, via `biome check .` and `biome check . --write`, configured in `biome.json`. Tests run under Vitest, configured in `vitest.config.ts`.

Export takes two completely different paths on web and desktop

This is the sharpest technical boundary in the project.

On the web, export uses the browser `MediaRecorder`, producing WebM or MP4 when the browser supports it. MediaRecorder uses a real-time browser recording path, so the supported container and codec depend on the browser rather than an explicitly chosen desktop export format.

On the desktop build, export is an offline frame render piped into a bundled ffmpeg to produce MP4 with H.264 video and AAC audio. The packaging scripts run `pnpm install-ffmpeg` first, which downloads the platform binary, and the packaging commands then include it under `bin/`. The result is deterministic output with no real-time recording constraint, at the cost of requiring a working ffmpeg on the target platform.

The README states that the Electron bridge is reserved for window chrome, temp files and ffmpeg export, with absolute paths only when needed, and points to `docs/desktop-capabilities.md` for the details.

Packaging the desktop app and the BUILD_TARGET split

Desktop builds work as a static export plus electron-builder. The renderer build sets `BUILD_TARGET=desktop` with `NODE_ENV=production`, producing an export in `out/`, which is then packaged with the `electron/` directory into installers written to `release/`.

pnpm package:dir
pnpm package:mac
pnpm package:win
pnpm package:linux

`pnpm package` is an alias for `pnpm package:dir`, the unpacked variant, and each platform target maps to the matching electron-builder flag with `--publish never`. Publishing is deliberately excluded from these commands, so release distribution is your own step.

One constraint is stated explicitly and should be read before changing anything: `pnpm build` is what Vercel runs on commits, and the README says not to change that script for desktop packaging. The two targets share a Next.js config and diverge only through `BUILD_TARGET`.

Fonts behave differently offline and online, and Inter is the floor

Font handling is where the web and desktop builds diverge most visibly to a user, because the failure is silent.

Inter is the only bundled font and the default for every new text layer. The desktop app scans installed font families through Chromium's Local Font Access API and never downloads text fonts, so a project opened on a machine missing a family falls back to Inter. The web build instead searches the Google Fonts catalog and loads the chosen families and their regular, bold and italic faces from Google's CSS API on demand, which means internet access is required for uncached fonts.

Projects store family names rather than embedded font data. That keeps `.afx` files small, but it means a project can render differently on a second machine with different fonts installed, and there is no warning in the format, only a fallback.

The catalog itself is a snapshot in `src/lib/config/googleFonts.json`, refreshed with `pnpm fonts:refresh`. The README is candid that the source endpoint is not a documented API contract, and that refreshes validate the expected response shape.

An MCP server, and a two year gap before 2.0.0

The desktop build exposes an MCP server. You enable it in Settings, in the MCP server panel, and copy the connection details shown there; the setting and its token persist across restarts. `docs/mcp.md` documents the setup and the tools. That is the feature most likely to matter for automation, since it gives an agent a scripted path into an editor that has no public API.

The release history is worth understanding before you adopt. v1.4.0 shipped on 2022-04-28 and v1.3.0 on 2022-01-07, then nothing until v2.0.0 on 2026-08-28. The repository is not archived and the last push was on 2026-10-07, so work is happening now, but the 2.0.0 gap means pre-2026 documentation, plugins and project files may describe a program that no longer matches. The repository also carries a `GLOSSARY.md` and a `messages/` directory, suggesting the user-facing text is localised.

Editorial conclusion

Astrofox suits a creator who wants an audio reactive editor that runs without a backend, keeps project files on their own disk as `.afx`, and can export a real H.264 MP4 on the desktop build. It does not suit someone who needs frame accurate editing, colour grading or a timeline with cuts, because the repository describes a motion graphics program driven by audio analysis rather than a video editor. Verify first that your audio renders as expected in a project opened from disk, and that the ffmpeg step completes on your platform, by running `pnpm dev` and then `pnpm package:dir` before committing to the release pipeline.

Frequently asked questions

Official sources

1. astrofox-io/astrofox on GitHub
2. License: MIT
3. Project website
4. README
5. Releases