OpenCut is a free, open source video editor that runs in your web browser and never uploads your footage anywhere, and it is one of the hottest repositories on GitHub right now, adding more than 4,200 stars in a single day on top of roughly 69,500 total. It bills itself as the open source CapCut alternative: the timeline editing most people use CapCut for, minus the account, the subscription creep and the clips leaving your machine. Self-hosting the version that actually runs today takes about fifteen minutes with Bun and Docker, and this guide walks the exact commands from the project's own README.
- OpenCut is MIT licensed and browser-based: your video files stay on your device, and there is no sign-up wall to start editing.
- The headline repo is mid-rewrite toward a Rust core with a plugin system and an MCP server; the code you self-host today lives in the opencut-classic codebase.
- Local setup needs Bun and Docker: clone, start Postgres and Redis in containers, then run one dev command to reach the editor at localhost:3000.
- A one-line Docker Compose self-host path builds the whole app and serves a production build at localhost:3100.
What is OpenCut and why is it trending?
OpenCut is a browser-based video editor: a timeline, a preview panel, cuts, trims and text, built with TypeScript. The pitch is aimed squarely at CapCut users who have watched a free tool slowly move core features behind a paywall, and who never loved the idea of uploading personal footage to a vendor in the first place. OpenCut keeps the media on your machine and puts the whole codebase under the MIT license, so nothing is gated and nothing phones home. That combination is why it sits near 69,500 stars barely a year after its first commit, and why it keeps returning to the GitHub trending page.
Relateddcg Setup: Block Destructive Commands From AI Coding Agents
One thing to understand before you clone anything: the project is in the middle of a ground-up rewrite. The main repository, OpenCut-app/OpenCut, is being rebuilt around a shared Rust core with a plugin-first architecture, a headless mode for batch rendering, and an MCP server so AI agents can drive it. That rewrite is not ready to run yet. The version that powers opencut.app today, and the one you should self-host today, is the classic codebase at OpenCut-app/opencut-classic. Everything below uses that classic repo, exactly as its README documents it.
How do you run OpenCut locally?
You need two things installed first: Bun as the runtime and package manager, and Docker with Docker Compose for the local database and Redis. Docker is technically optional if you only touch frontend code, but the defaults expect it, so install it unless you have a reason not to. With those in place, the development setup is four steps:
# 1. clone the runnable classic codebase
git clone https://github.com/OpenCut-app/opencut-classic
cd opencut-classic
# 2. copy the env file (Windows PowerShell shown on the right)
cp apps/web/.env.example apps/web/.env.local
# Windows: Copy-Item apps/web/.env.example apps/web/.env.local
# 3. start the local database and Redis in containers
docker compose up -d db redis serverless-redis-http
# 4. install dependencies and start the dev server
bun install
bun dev:web
The editor comes up at http://localhost:3000. The README notes that the checked-in .env.example already carries sensible defaults that line up with the Docker Compose config, so it should work out of the box with no secret-hunting. If you are only building UI and skip Docker, the frontend still starts; you just lose the pieces backed by the database.
How do you self-host the production build?
If you would rather run a built, production version of the whole thing, including the app itself in a container, the classic repo ships a single command for that:
# build and run everything in Docker
docker compose up -d
That path serves the app at http://localhost:3100 (note the different port from the dev server). It is the closest thing to a turnkey self-host: point it at a box on your network, put it behind a reverse proxy, and you have a private CapCut-style editor for a team without a single cloud account. Because the media never leaves the browser, the server here is mostly hosting the app and its metadata, not warehousing your footage.
RelatedVibe-Trading Setup: Self-Host an AI Trading Agent Free
How does OpenCut compare with the alternatives?
| Trait | OpenCut | CapCut | Clipchamp | Kdenlive |
|---|---|---|---|---|
| Runs in | Browser | App + web | Browser | Desktop app |
| Clips stay local | Yes | No | No | Yes |
| Price | Free, MIT | Free tier + paid | Free tier + paid | Free, GPL |
| Open source | Yes | No | No | Yes |
| Self-hostable | Yes | No | No | N/A local |
Kdenlive is the honest apples-to-apples on privacy and licensing, but it is a heavyweight desktop program with a steeper learning curve. OpenCut's bet is that most people want the CapCut interaction model, in a browser, without the account, and that a self-hostable web app fits how teams actually share tools. The cloud editors still win on polish, mobile apps and a deep effects library; OpenCut wins wherever control of the footage is the point.
What are the gotchas before you rely on it?
Four things to know before you make this your editor of record. First, you are self-hosting the classic codebase while the maintainers pour their energy into the rewrite: it works and powers the live site, but do not expect a stream of new features on the classic branch. Second, the team has explicitly flagged that export and the preview panel (fonts, stickers, effects) are being refactored with a new binary rendering approach, so those are the roughest edges today. Third, this is a browser editor, which means large 4K projects lean on your machine's memory and the browser's limits rather than a render farm. Fourth, there is no packaged one-click desktop or mobile installer yet; the desktop app and the Rust core are works in progress in the new repo. None of these block a working install, but they are the difference between a calm setup and a surprised one.
- The rewrite shipping. The Rust-core rebuild promises desktop, mobile and browser from one codebase; when new.opencut.app takes over from the classic version is the milestone that matters.
- Export getting solid. The new binary rendering path is the feature that decides whether OpenCut is a real editor or a nice timeline demo.
- The plugin and MCP story. A plugin-first architecture plus an MCP server would let AI agents cut video directly, which is a genuinely new capability, not a CapCut clone feature.
Our take
OpenCut is riding a real shift: the parts you need to edit video in a browser, timeline logic, WebAssembly-backed processing, local storage, finally got good enough that a small team can package them into something a non-engineer can run. The star count is not hype for its own sake; it is a referendum on CapCut's paywall creep and on the discomfort of uploading personal footage to edit it. The risk is the same one every mid-rewrite project carries: the classic version you can run today is stable but frozen, and the exciting version is not finished. If you want a private, free, self-hostable editor right now, the classic setup above delivers it in fifteen minutes. If you want the plugin-and-Rust future, star the repo and wait. Either way, the license argument is the one CapCut cannot answer.
- OfficialOpenCut-app/OpenCut main repository and rewrite status
- OfficialOpenCut-app/opencut-classic the runnable codebase and setup README
- Officialopencut.app hosted version of the classic editor
- ReferenceBun runtime and package manager the setup uses
Original analysis by GenZTech. Tool documentation: OpenCut-app/opencut-classic on GitHub.
