Edit Mind: a local video index built from Whisper, YOLO and DeepFace, wired together with Docker Compose
Local-first Video Knowledge Base. Index your video library with multi-modal analysis (YOLO, DeepFace, Whisper), search semantically via natural language, Docker-ready.
At a glance
- What is it?
- Edit Mind is a self-hosted pipeline that transcribes, scans and embeds your video library so you can query it in natural language. It is explicitly not production-ready, and the README says so before it says anything else.
- Who is it for?
- Adopt Edit Mind if you have a fixed video archive, a machine with Docker, and the patience to run a project whose own README calls it not yet production-ready. Do not adopt it if you need a supported product with a stability guarantee, or if your library sits on a NAS path you cannot add to Docker Desktop's File Sharing list, because HOST_MEDIA_PATH has to resolve inside the container.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 78 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Edit Mind attacks: video you own but cannot search
A folder of footage is opaque to every tool except the one that plays it. Filenames lie, timestamps drift, and the only index most editors have is memory. Edit Mind's stated goal is to turn that folder into something queryable: the README describes searching videos by spoken words, objects and faces, and it frames the project as the editor's second brain. The name is short for Video Editor Mind, which tells you who the author is aiming at. This is not a media asset manager for a broadcast archive with a dozen stakeholders. It is for one person, or a small team, with a local library and a machine that can run containers. The privacy claim is the other half of the pitch: the README says it runs fully locally, which is only true in the Ollama configuration, since the Gemini option sends work to Google. That distinction matters more than the marketing line suggests, and the README does expose it through the two mutually exclusive model switches.
Three services, one compose file: how the pipeline is actually split
The architecture is a monorepo managed with pnpm workspaces, and the README's technology table separates it into distinct runtime pieces. A web service built on React Router V7, TypeScript and Vite serves the interface. A background jobs service runs on Node.js, Express and BullMQ, and the README says it watches for new video files and queues them for analysis. A separate ML service is written in Python and pulls in PyAV for decoding, PyTorch for the models, OpenAI Whisper for transcription, and either Google Gemini or Ollama for the language-model step. Results land in two stores: ChromaDB for vectors and PostgreSQL via Prisma for relational data. The data flow implied by that split is straightforward. A file appears in the watched folder, BullMQ hands a job to the ML service, the ML service decodes frames and audio, produces metadata (the README lists face recognition, transcription, object and text detection and scene analysis), and the embeddings go into ChromaDB while the structured records go into Postgres. Search then queries the vector store. Keeping the ML work in Python and the queue in Node is a reasonable boundary, because it means a crashed model does not take the web UI with it, but it also means you are running at least four containers before you index a single second of footage.
Getting it running: the two-file environment and the switches that decide everything
The README offers a one-liner, curl -sSL https://get.edit-mind.com | sh, and a manual path. The manual path is more informative. You create a directory, download three files (docker-compose.yml, .env.example and .env.system.example), and rename the examples to .env and .env.system. If you have an NVIDIA GPU you fetch docker-compose.cuda.yml instead, which is the README's own admission that the default compose file does not use your GPU. On macOS and Windows you must add your video folder to Docker Desktop under Settings, Resources, File Sharing, and the README stresses that HOST_MEDIA_PATH must match that path. Then you pick a model. Option A sets USE_OLLAMA_MODEL to true with OLLAMA_HOST, OLLAMA_PORT and OLLAMA_MODEL, and the README's example uses qwen2.5:7b-instruct with the host pointed at 172.17.0.1, the Docker bridge address. You have to run the server yourself with OLLAMA_HOST=0.0.0.0:11434 ollama serve and pull the model first. Option B sets USE_GEMINI to true and supplies GEMINI_API_KEY. The README does not document what happens if both flags are set, and it does not give a default for OLLAMA_MODEL beyond the example value.
The honest limitation is in the first paragraph of the README
Most project pages bury the warning. Edit Mind leads with it: active development, not yet production-ready, expect incomplete features and occasional bugs, contributors welcome to help reach v1.0. Take that at face value. The version numbers support it. The repository shows v0.21.0 in April, v0.22.0 in May, v0.30.0 in late June, which is a fast minor-version cadence with no 1.0 in sight. For anyone deciding whether to put this in front of a paying client's footage, that cadence is the answer: you would be running a moving target. There is a second, quieter limitation. The desktop app is commercial, sold as a preorder with early-bird pricing, a lifetime licence and a year of updates, and the README is candid about why it exists: people did not want to run a server, and Docker cannot reach the Apple GPU, so the desktop build is the only route to Apple silicon acceleration. The self-hosted version is free and, in the author's words, not going anywhere, but the performance ceiling on a Mac is set by that container boundary.
Where a plain transcription tool would be the better choice
Whisper is available as a standalone CLI, and if all you want is searchable speech, that is the smaller tool: one process, one output file, no Postgres, no ChromaDB, no queue. Edit Mind's value is in the union of signals. Searching for a person by face, an object by detector, and a phrase by transcript in one query is something a transcript-only workflow cannot do at all, and that union is the reason to accept the container overhead. The reverse also holds. If your footage is mostly talking heads on a fixed set, the object and face detectors add indexing time without adding much recall, and you are paying for three models to answer a question one would have answered. The Gemini option is a third fork in the road: it removes the need to run and pull an Ollama model, at the cost of sending content to an external API, which contradicts the local-first framing the README opens with. The project does not hide the trade, but it also does not resolve it.
Maintenance cost and the licence question the repository leaves open
Running this is not a one-time install. You maintain a Postgres instance and a ChromaDB instance, both of which hold state you would want to back up, plus a queue and two application containers. The ML service carries PyTorch, PyAV and Whisper, which is the heaviest image in the stack and the one most likely to break on a base-image bump. Upgrading means re-pulling images and re-running the compose file, and because the project is pre-1.0, minor versions can change environment keys. The .env and .env.system split helps here: your personal settings live in one file and the system defaults in another, so a changed default does not silently overwrite your HOST_MEDIA_PATH. On licensing, the repository metadata reports NOASSERTION, which means GitHub could not map the licence file to a known identifier. The README does not state terms for the self-hosted code. That is a gap you should close by reading the actual licence file in the repository before you build anything commercial on top of it. This is not legal advice, but an unresolved licence identifier is a question, not an answer.
Who this is for, and what to check before you commit disk space
The fit is narrow and specific: a solo editor or small studio with a large local archive, a Linux box or a Windows machine with an NVIDIA card, and a tolerance for rough edges. The CUDA compose file is the tell that the author expects that hardware. If you are on a Mac and want GPU acceleration, the README points you at the paid desktop app instead, which is an unusual shape for an open source project and worth weighing honestly rather than treating as a footnote. Before you index anything, confirm three things: that the ML container builds and starts on your machine, that your model path is live (Ollama answering on the configured host and port, or a valid Gemini key), and that HOST_MEDIA_PATH resolves to the same folder Docker Desktop has been granted. Those three checks are the difference between a working index and a queue that fills with failed jobs.
Editorial conclusion
Adopt Edit Mind if you have a fixed video archive, a machine with Docker, and the patience to run a project whose own README calls it not yet production-ready. Do not adopt it if you need a supported product with a stability guarantee, or if your library sits on a NAS path you cannot add to Docker Desktop's File Sharing list, because HOST_MEDIA_PATH has to resolve inside the container. Verify first that the ML service container actually starts on your hardware (the CUDA compose file exists precisely because the default one does not use an NVIDIA GPU) and that your chosen model path works: either an Ollama server reachable at OLLAMA_HOST with the model already pulled, or a Gemini API key with USE_GEMINI set.
Community notes