# Cutia: a browser video editor that keeps your footage on your machine

> Cutia is an open source video editor built as a Next.js application with a timeline, layered clips and browser-side export, and it is a fork of the opencut project. It suits a creator who wants to trim and layer short video without uploading it to someone else's server.

**msgbyte/cutia** — An open-source, in-browser alternative to CapCut.

- Repository: https://github.com/msgbyte/cutia
- Website: https://cutia.msgbyte.com
- Stars: 885 · Forks: 149
- Language: TypeScript
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/msgbyte-cutia

## The pitch is basics that stay free

The framing is a positioning against the market rather than a feature list, and it is worth taking at face value. Cutia is designed for creators who want a clean editing workflow without subscriptions, tracking or watermark traps, and the project describes itself as privacy-first, open-source video editing where you build, trim, layer and export directly from your browser. The at-a-glance section lists a local-first editing mindset, a timeline-based multi-track workflow, real-time preview while editing, and being open-source and contribution-friendly. The stated reason the project exists is that most lightweight editors are either too limited or progressively locked behind paywalls, and the principle behind it is that powerful basics should stay accessible. What you can actually do is listed separately and is short: arrange clips in a timeline, layer video, text, audio and stickers, preview changes in real time, and export without watermark pressure. That list is honest about being a subset of what a full editor does, and it is also exactly the subset that a short-form creator needs.

## Local-first means the browser does the work

The local-first mindset is the load-bearing claim and it has a specific architectural consequence in this repository. The stack snapshot is a Next.js application in the apps/web directory, Bun for dependency management and scripts, PostgreSQL and Redis marked as optional for frontend-only work, and TypeScript across the project. The optionality of the backing services is the tell. If you only want to edit and export, you can run the web application with no database and no cache at all, and the quick start path is five commands:

```bash
git clone <your-fork-url>
cd cutia/apps/web
cp .env.example .env.local
bun install
bun dev
```

Then you open the local port. The full setup adds the services, where Redis and a serverless Redis HTTP interface are started for local development, and the environment values for the Redis REST URL and token are given, along with the node environment. Authentication is the optional extra on top, requiring PostgreSQL with its connection string and a generated auth secret, and the secret is generated with a random base64 command. So the shape of the product is a browser editor that does not need a server for the core work, with a server appearing only if you want accounts.

## The two service tiers, and why Redis has an HTTP face

The compose file is more informative than it looks, because it explains an unusual choice. The Redis service runs the standard Alpine image with a ping healthcheck. The second service is a serverless Redis HTTP interface, configured with a mode of env, a token and a connection string pointing at the Redis service, and it waits for Redis to report healthy before it starts. The reason for the HTTP layer is that the browser talks to it rather than talking to Redis directly, which is the pattern that makes the frontend work with a hosted Redis offering over REST, and the environment variable names reflect that with a REST URL and a REST token. The web service then depends on that HTTP interface and sets the site URL. The PostgreSQL service is present in the file but commented out, with the note that it is only needed if you want authentication, and it carries the same credentials pattern with a matching healthcheck. The consequence for a deployment is that the browser-side code is written against a REST interface, so you can point it at a managed service rather than running Redis yourself, and the Docker path is the one that gives you both.

## What the contribution guidance admits is unfinished

The contributing section lists the current high-impact areas and the areas under active refactor, and it is the most valuable paragraph in the readme for anyone deciding whether to use this. The high-impact areas are timeline behaviour and interaction quality, project management and reliability, performance tuning and bug fixing, and user interface improvements outside the preview internals. The areas under active refactor are the preview panel internals, covering fonts, stickers and effects, and the export pipeline internals. Read together, that is a precise statement of where the rough edges are. The timeline interaction is the thing you touch most, the preview panel and the export path are the two places where the code is being rewritten, and project management and reliability is called out as needing work. The project is also explicit about its build tooling, with a per-workspace script set for the web app and a tools app, Turbo driving both, Biome for linting and formatting with a generous diagnostics limit, and the test command running under the Bun test runner.

## A fork of opencut, and what that means for maintenance

The last line of the readme is the one to read before adopting anything. It is a note saying this is a fork of opencut, with a specific commit hash recorded. That single line changes how you should think about the project, because the upstream is a separate codebase with its own contributors and its own trajectory, and this repository is a derivative snapshot of a particular point in it. It also explains the shape of what you find here, since a fork that has moved forward with its own authentication, its own preview work and its own export work will have diverged from the original in ways that are not documented in the readme. The fork point is recorded, which is the right way to do it, and it gives you a way to see what changed. The repository layout is a Turbo monorepo with the web application and a tools application under apps, a packages directory, a docs directory, a Dockerfile, a compose file, a biome configuration, an i18n script, a vercel configuration, and agent instruction files. The Docker build itself is a two-stage image, building on the Bun base and running on a node Alpine image as a non-root user, with the build performing environment validation at build time using placeholder values for the required variables.

## Running it with Docker, and deploying it

The Docker path is the shortest route to a running instance. One command starts the whole thing:

```bash
docker compose up --build
```

And then you open the local port. The compose file builds the web image from the repository root, maps the port, and sets the site URL and the Redis REST variables, so the browser reaches the HTTP interface on the service name rather than on localhost. The readme notes that this starts Redis and the web app, and that to enable authentication you uncomment the PostgreSQL service and the related environment variables in the compose file. For hosting, the readme carries a Vercel deploy button that clones the repository and creates a project, and the vercel.json at the root is what makes that work. Between the local Docker path, the Vercel button and the full local setup with PostgreSQL, there are three ways to run it, and the differences between them are exactly the differences between editing only, editing with accounts, and editing with a database.

## Conclusion

Cutia is a good fit for a creator who edits short video locally and does not want their footage uploaded to a service they do not control, since the editing runs in the browser and the local-first stance is a design goal rather than a promise. It is the wrong tool if you need the advanced timeline features of a professional editor, because the contribution guidance names the timeline behaviour and interaction quality as an area still under active work, and the preview panel internals and the export pipeline internals are both listed as under active refactor. It is also the wrong tool if you need multi-user collaboration, since the authentication path is an optional extra built on a database and an auth library rather than a core feature. Before adopting it, read the fork notice, because this repository is a fork of opencut at a specific commit and the upstream relationship determines who fixes what, and check the deployment options, since there is a one-click Vercel button and a Docker path. The project is MIT licensed, the last push was on 2026-10-09, and it publishes no GitHub releases.

## FAQ

### What is Cutia and what can it do?

It is an open source, privacy-first video editor that runs in the browser, with a local-first editing mindset, a timeline-based multi-track workflow and real-time preview. You can arrange clips in a timeline, layer video, text, audio and stickers, preview changes as you make them, and export without watermark pressure.

### How do I run Cutia locally?

Clone the repository, move into the cutia/apps/web directory, copy the example environment file to .env.local, run the Bun install and then the Bun dev command, and open the local port. The backing services are optional for frontend-only work, with Redis and a serverless Redis HTTP interface started separately for local development.

### Does Cutia need a database to work?

Not for the core editing work, since PostgreSQL and Redis are marked optional for frontend-only use. The compose file ships the PostgreSQL service commented out with a note that it is only needed for authentication, which additionally needs the database connection string and a generated auth secret, and the Redis HTTP interface exists so the browser can talk to it over REST.

### What is unfinished in Cutia right now?

The contribution guidance names the high-impact areas as timeline behaviour and interaction quality, project management and reliability, performance tuning and bug fixing, and user interface improvements outside the preview internals. The areas under active refactor are the preview panel internals covering fonts, stickers and effects, and the export pipeline internals.

### Is Cutia related to other open source video editors?

It is a fork, and the readme records the fork point with a commit hash, so the upstream codebase and its own trajectory are worth checking. The project is MIT licensed, it can be run with a single Docker compose command, and there is a one-click deploy button for Vercel, with the last push on 2026-10-09 and no GitHub releases published.

## Sources

- [Issues](https://github.com/msgbyte/cutia/issues)
- [License: MIT](https://github.com/msgbyte/cutia/blob/main/LICENSE)
- [msgbyte/cutia on GitHub](https://github.com/msgbyte/cutia)
- [Project website](https://cutia.msgbyte.com)
- [README](https://github.com/msgbyte/cutia/blob/main/README.md)

---

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