Kitsu, a production tracker built around the way studios actually deliver

What the application is for

Kitsu is a web application that lets a studio collaborate on its creative productions and manage its deliveries. The stated purpose is to improve the communication between all stakeholders, which leads to better results and faster shipping.

That is a production management problem rather than a software problem, and the way Kitsu is described tells you the model. The topics are animation, pipeline and VFX, so the units of work are the things an animation studio actually tracks: shots, assets, versions and review cycles. A studio does not have tasks in the abstract, it has a shot that goes from layout to animation to lighting, with a review at each stage and a client who comments on the result.

The homepage is at kitsu.cg-wire.com, and the README notes that more than 300 studios around the world use Kitsu for their projects. Kitsu is written by CGWire, a company based in France that describes its work as helping animation and VFX studios collaborate better through efficient tooling.

The licence is AGPL-3.0, and that is the single most important fact for anyone considering it. Kitsu is the user interface half of a larger system, and the package metadata is explicit that this repository is the production management software user interface. That means there is a separate back end, the API, and the two are versioned and deployed independently, which is the arrangement that lets a studio run the interface against an existing API or a hosted one.

The project is not archived, the last push was on 2026-10-20, and the release history shows v1.0.69, v1.0.70 and v1.0.71 landing on 6, 7 and 14 October 2026. A weekly release cadence on a 1.0 line is the pattern of a product with real users and an active issue tracker, and it also means upgrade planning is a normal part of running it.

The front end stack and the dependency choices

The package.json describes the front end precisely, and the dependency list is where you can see what the application actually does.

The framework is Vue 3, with the type field set to module and the project built with Vite, since the dev and build scripts are simply vite and vite build. The build tool is configured through vite.config.js, and the styling pipeline runs through PostCSS with a postcss.config.js.

The visual stack is Bulma for the layout primitives, with fabric and a fork of fabric for canvas work, which is the drawing surface for storyboards and annotation, and lucide-vue-next for icons. Colour handling runs through the color and color-hash packages, which is the mechanism behind the per-asset colours studios use to distinguish work at a glance.

The 3D and media side is where it gets specific. three is a dependency, and so is @google/model-viewer, which means the interface can show a glTF model inline, and that is how a shot is reviewed in 3D. The @animxyz/vue3 package handles animation, and marked with marked-emoji renders the markdown that appears in descriptions and task notes, with sanitize-html alongside it, which is a sensible pairing given the content comes from many users.

The scheduling and reporting side is chart.js with chartkick for graphs, and @fullcalendar with its daygrid, list and multimonth plugins drives the calendar views that sit above the shot list, with @vuepic/vue-datepicker for the date inputs. Exceljs and papaparse handle spreadsheet import and export, and diff2html renders the visual diffs between two versions of an asset, which is the feature a supervisor uses to see what changed between two takes.

The realtime and error handling choices are notable. socket.io-client is present, which is how the interface stays in sync with changes other people make without polling, and @sentry/vue is the error reporting integration.

The date libraries are a small curiosity: date-fns, moment and moment-timezone are all present. Carrying two date libraries is not a sign of good judgement, and it usually reflects an incremental migration rather than a decision, so it is worth knowing about if you plan to work on the codebase.

The development workflow and the tooling around it

The scripts section describes a working setup rather than a minimal one, and each entry says something about the project.

Development is vite, the production build is vite build, and there is a preview script that serves the built output. Formatting is prettier, run over the source files with the write and list-different flags together, so the script both rewrites and reports what changed. Linting is eslint over src/ with a separate script for the tests directory, and a fix variant for each. Tests run through vitest, with a unit mode and a coverage mode, and the default test script points at the unit mode.

The prepare script runs husky, which is the conventional way to install git hooks on install, and the .husky/ directory at the top level holds them. That pairs with the .mergify.yml file, which is the configuration for Mergify, an automation service that manages merge and review queues on GitHub.

There is a .storybook/ directory, so the component library is developed and reviewed in Storybook rather than only in the application, which is the normal arrangement once a front end has more than a handful of components. There is a .browserslistrc, which tells you which browsers the build targets, and a .editorconfig for whitespace, and a .git-blame-ignore-revs file, which is the convention for keeping the history readable after a bulk reformat, and a .gitguardian.yaml for secret scanning in the repository.

The formatting configuration is split across a .prettierrc.json and a .prettierignore, and the lint configuration is eslint.config.js, the flat config format, which matches the modern eslint setup.

The repository also has two documents aimed at people joining rather than at users. CONTRIBUTING.md is the contributing guide the README points at, described as explaining everything about the many ways to contribute, from simple tasks to the most complex ones. DEVELOPMENT.md covers the development setup, and CLAUDE.md is present as well, which is the pattern of a project that has adopted an agent-assisted workflow and has written down the conventions for it. RELEASE.md documents the release process, which is worth reading if you are running a studio on it, because it tells you what to expect when you upgrade.

There is a jsconfig.json alongside the package configuration, which is the JavaScript equivalent of a tsconfig and tells you the editor how to resolve the module aliases in the project.

Where it fits against the alternatives

The alternatives in this space fall into three groups, and it helps to be clear about which problem each one solves.

The first is the general purpose work management tool. Jira, Linear, Asana and Trello all track work, and a studio can be forced to use one with shots as tickets. The failure mode is well known: the data model of a general tracker has no concept of a shot having a pipeline of steps with per-step owners, a version history and a review chain, so the studio ends up maintaining that structure in convention, in naming and in a parallel spreadsheet. Kitsu's pitch is that it does not require that parallel system.

The second is the spreadsheet, usually per department. A layout spreadsheet, an animation spreadsheet, a lighting spreadsheet, each with its own column conventions and its own version of the truth, merged by hand into a weekly status report. This is what a small studio starts with and what a large studio is trying to get away from. Kitsu is a shared source of truth across departments, which is exactly the thing spreadsheets cannot be.

The third is the other dedicated production trackers, and there are several, most of them commercial with annual licences per seat. The comparison there is mostly about cost and about hosting, and about whether the tool is open. An AGPL-3.0 application that a studio can self-host and modify is a genuinely different proposition from a per-seat licence, particularly for a studio that wants to add a field that only their pipeline produces.

What Kitsu is not is a rendering pipeline tool. It tracks the state of work and the review of assets; it does not render, composite or manage a farm. Studios use it alongside those systems, not instead of them, and the asset and version model is the interface between them.

The practical cost is the one any studio tool carries: it is a system people have to keep up to date, and a tracker that is not updated stops being a source of truth. The reason Kitsu survives that is the same reason studios keep spreadsheets, which is that the work is already being tracked somewhere informally, and Kitsu is only more effort if it is a second place rather than the first. Whether it is worth the setup is a question about studio size and about how much of the pipeline is already bespoke.

For a team evaluating it, the documentation site is the place to start, and the fact that the front end is a separate repository from the API means you can evaluate the interface against a hosted instance before deciding to run your own.

Editorial conclusion

Adopt Kitsu if you run an animation, VFX or game production and need a shared source of truth for shot status, asset tracking and client review. Skip it if your pipeline is small enough to live in a spreadsheet, since the setup cost is real. Verify first by running the front end against a local API instance and entering a shot through the interface, and by reading the deployment documentation before committing a studio to it.

Frequently asked questions

Official sources

1. cgwire/kitsu on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases