Serpent: an MIT-licensed asset manager for game art, VFX and motion design

The problem Serpent targets: art files that no file browser understands

A game artist's working drive is not a documents folder. It holds PSDs, EXRs, FBX and OBJ models, WAV stingers, reference video, and a pile of plain text notes. Finder and Explorer show all of that as a list of names and dates. They cannot tell you which of two hundred textures is the final approved one, which model belongs to a shelved project, or which clip was the reference for a shot that shipped last quarter. The usual answer is a folder convention plus discipline, and the usual result is that the convention decays.

Serpent is aimed at the people who feel that decay: game artists, VFX professionals, and graphic or motion designers. The README lists the asset types it accepts as most video, image and audio formats, plus 3D models and text assets. It is a desktop application for macOS and Windows, not a web service, so the library lives on local disk and the machine does the indexing work.

The interesting claim is not that it stores files. It is that it stores files of types that asset managers usually ignore. A tool that can hold an FBX model, a text file and a 4K clip in the same tagged collection is solving a different problem from a photo catalog.

How Serpent works: Electron, SQLite with FTS5, and a plugin runtime

The repository layout shows an Electron application built with Electron Forge and Vite. `package.json` points `main` at `.vite/build/main.js`, and the config files at the repository root split the build into separate bundles: `vite.main.config.ts`, `vite.renderer.config.ts`, `vite.preload.config.ts`, `vite.worker.config.ts`, `vite.plugin-runtime.config.ts`, `vite.plugin-trusted-runtime.config.ts` and `vite.script-runtime.config.ts`. That split is the architecture in one line: a main process, a renderer, a worker for background jobs, and separate runtimes for plugins and scripts, with a trusted variant of the plugin runtime alongside the ordinary one.

The `rebuild:native` script gives away the storage layer. It exists to "align better-sqlite3 with the Electron ABI" and to verify FTS5, according to the README's comment on that command. So the library index is a SQLite database accessed through better-sqlite3, and full-text search runs on FTS5 rather than on a scan written in JavaScript. The worker bundle is where indexing and thumbnail work would live; the repository also contains `offscreen-thumbnail.html`, which suggests thumbnails are generated in an offscreen renderer rather than in the main process.

Three capabilities sit on top of that core. A plugin system extends the application, with a separate manual for plugin, script and MCP authors. A script interface and an MCP server let external programs drive Serpent, which the README frames as letting an agent connect and manage assets automatically. And an AI analysis module inspects images, video and 3D assets. The README states that the module exists; it does not describe which models it calls or whether anything leaves the machine, so treat that as the first thing to check in the user guide before pointing it at client work.

WebDAV sync is the other moving part. The README describes two-way synchronisation of a library between devices, with automatic sync and a configurable polling interval. Polling rather than push means conflict handling is the design question, and the README does not document how conflicts are resolved.

Installing Serpent and opening your first library

The README directs users to the GitHub Releases page rather than to a package manager, so installation is a download and a drag. On macOS the artefact is named `Serpent-<version>-arm64.dmg`; you drag it into Applications. Because the build is not notarised, the first launch is blocked by Gatekeeper. The README gives two ways past it: right-click the app and choose Open, or run the following in a terminal, which clears the quarantine attribute on the bundle.

xattr -cr /Applications/Serpent.app

On Windows you run `Serpent-<version> Setup.exe`. The README notes that unsigned builds trigger SmartScreen on first run, and that you proceed through "More info" then "Run anyway". There is no Linux installer in the README; the stated targets are macOS and Windows only.

If you want to build it yourself, the README pins Node.js 24.15.0 and points at `.nvmrc`. Two constraints are stated explicitly: native development targets macOS arm64 and Windows x64, and you should not build on an SMB or NAS mount. The install sequence is three commands.

npm ci --registry=https://registry.npmjs.org
npm run rebuild:native
npm start

The middle command is the one that matters. It rebuilds better-sqlite3 against the Electron ABI and checks that FTS5 is available, so a failure there means search will not work even if the app launches. `npm start` runs `scripts/dev-start.mjs` after a `prestart` hook that ensures native modules and patches the development Electron name.

The browser extension is installed separately. You download it from the extension release page, open `chrome://extensions`, enable developer mode, and load the unpacked directory. The README gives the path inside the app bundle: `Serpent.app/Contents/Resources/extension` on macOS, and `resources/extension` in the install directory on Windows.

Where Serpent is the wrong tool

The README does not document a schema migration path, a library backup format, or a rollback procedure. That is a real gap for a tool that owns your index. If a release changes the SQLite schema and you have already opened your only library with it, the README gives you nothing to fall back on. Treat the library directory as something to copy before each upgrade, and treat the version number as a compatibility signal until the developer documentation says otherwise.

WebDAV sync is the second place to be careful. Two-way sync with a polling interval is a design that tolerates latency but not simultaneous edits, and the README describes the interval as configurable without describing what happens when two devices change the same asset between polls. If your workflow involves two machines editing the same library at once, the documentation does not currently support that assumption.

The AI analysis module is the third. It is listed as a feature with no statement about where the analysis runs. Until the user guide or the developer documentation says otherwise, assume nothing about whether asset data stays on the machine.

Finally, there is no Linux build and no headless or server mode in the README. If your pipeline runs on Linux render nodes, or if you need the library to be reachable over HTTP from a browser, Serpent is not that product. The browser extension is a companion to the desktop app, not a replacement for it.

Serpent compared with Eagle and Billfish

Eagle and Billfish are the two libraries Serpent explicitly reads. The README states that Serpent can open an Eagle or Billfish library directly, converting it and then browsing and searching it. That is the clearest statement of where Serpent sits: it is a migration target and a superset, not a from-scratch alternative in a vacuum.

The difference in approach is licensing and format. Eagle and Billfish are closed-source commercial products; Serpent is MIT, and the source is in the repository you can read. For a studio that needs to audit what touches its assets, or that wants to add a format handler through the plugin system, that difference decides the question. The plugin, script and MCP interfaces are the part Eagle does not offer in the same form, and the MCP server in particular is aimed at agent-driven workflows that neither Eagle nor Billfish documents.

The trade-off runs the other way too. Eagle and Billfish have shipped for years and their libraries are stable surfaces. Serpent is at 0.2.4, with releases on 2026-09-10, 2026-09-14 and 2026-09-17, and the README does not promise format stability. Adopting Serpent means accepting that the library format can move while the product is young. The conversion path from Eagle is one-way in the documentation; the README does not describe writing back to an Eagle library.

Licence, dependencies and the cost of keeping Serpent current

The project is MIT, which covers the application code. The README is explicit that bundled media components and assets carry their own licences: FFmpeg under LGPL, OpenImageIO, ufbx under MIT, and Poly Haven assets under CC0, with LICENSE files in the relevant `resources/` directories. If you redistribute a packaged build, those terms travel with it. THIRD_PARTY_NOTICES.md at the repository root is the file to read before shipping anything built from this source. This is not legal advice; check the notices against your own distribution plan.

The upgrade cost is dominated by two things. The first is the native module. Every Electron upgrade changes the ABI, and `npm run rebuild:native` has to be re-run and pass, including the FTS5 check, before the app will search. The second is the library schema, which the README does not describe. Releases landed three times in the week before 2026-09-17, which is a fast cadence for software that holds your index, and the repository has no documented downgrade path. Budget for a copy of the library before each upgrade and for reading the release notes rather than assuming compatibility.

Maintenance is current: the last push to `main` was on 2026-09-17. That says the project is moving, not that it is finished.

Editorial conclusion

Adopt Serpent if you are a game artist, VFX generalist or motion designer on macOS or Windows who wants an MIT-licensed library that indexes 3D models and text alongside images and video, and that can open an existing Eagle or Billfish library. Do not adopt it if you need Linux, a browser-only workflow, or a tool with a long release history behind it; version 0.2.4 shipped on 2026-09-17 and the README documents no rollback or migration path between schema versions. Verify three things before committing a working library: that `npm run rebuild:native` passes on your machine if you build from source, that the AI analysis module behaves the way you expect on your own 3D files, and that WebDAV sync converges correctly between two devices rather than duplicating entries. Test on a copy of the library first.

Frequently asked questions

Official sources

1. dolag233/Serpent on GitHub
2. License: MIT
3. Project website
4. README
5. Releases