YumCut: a self-hosted pipeline for short vertical video generation

One prompt in, a finished 9:16 file out

The scope is end-to-end short-form production rather than editing. YumCut is described as an open-source AI short video generator for TikTok, YouTube Shorts and Instagram Reels, and the workflow is that you provide the idea and YumCut generates the script, the voice, the visuals, the captions and the final edit for a ready-to-post 9:16 video. That last part is what separates it from a script writer or a voice tool, and it is also where the cost and the failure modes live, because every stage is a call to some model or service. The stated purpose gives the reasoning behind the design, and the reasoning is about workflow rather than about the model: to turn short-form production into a repeatable workflow instead of manual editing chaos, to reduce production cost with open-source and self-hosted control, and to help teams publish more often and test more content ideas per week. The use cases follow that: daily publishing for faceless channels, turning one idea into multiple language versions for wider reach, testing different hooks and styles quickly without rebuilding videos from scratch, and agency-style batch production across multiple brands or clients. The last of those is the one that distinguishes the product from a creator tool, because batch production is a scheduling and accounting problem as much as a generation problem.

Local-first does not mean no external providers

The cost story is the interesting part of the positioning. The claim is that you can bring your own providers, run local components where possible, and tune the quality and speed trade-offs, and the project is described as a free and self-hosted alternative to closed short-video SaaS tools. The description also says local-first pipeline plus templates, and FFmpeg-ready, multi-language output. What that means in practice is that self-hosting removes the vendor from the middle of the workflow without removing the vendors from the workflow entirely, because the visual generation step is the expensive one and is the part most likely to depend on a hosted model unless you have a GPU of your own. The cost positioning section makes the commercial comparison explicit, with a figure of around 10x cheaper than popular closed video generators depending on your stack and providers, and it names the closed alternatives teams compare against, Veo on Vertex AI and its premium tiers, Runway Gen video models, Pika premium plans, Luma Dream Machine paid plans, and other closed credit-based video generation APIs. That comparison is a claim in the project's own words, and the qualifier it carries, that the figure depends on your stack and providers, is the honest part. A team that has already bought a Runway subscription will not see the same ratio as a team with local models on hand.

A bearer-key API that keeps the same rules as the web app

Automation is the reason to run this yourself rather than use a hosted service, and the API is designed with that in mind. YumCut includes a bearer-key User API for automating project workflows from external tools, backend jobs and AI agents, with interactive documentation, an OpenAPI schema, and API key management in the account area. The list of what it can do is specific: quote token costs, create video or Image Prank projects, poll status, stop or cancel work, update settings, read catalog data and fetch final media download URLs. The design constraint stated in the documentation is the part that makes it safe to expose, and it is that the API uses the same account ownership checks, read and write key scopes, token balance rules and project creation paths as the web app, so automation and AI agents can run production workflows without bypassing credits or user data boundaries. That is the right way to build it, since the alternative, an API that bypasses the billing model, becomes an unauthenticated cost centre the moment the key leaks. The mention of Image Prank projects as a distinct project type is a small signal that the pipeline supports more than one visual template.

Next.js, Prisma, and a daemon that does the rendering

The repository is a Next.js application, and the package metadata is private with the name app.yumcut.com, which tells you the deployment shape is a hosted web app rather than a library. The scripts in the package file show the operational surface, and it is a large one. The dev and build scripts look like this:

    "dev": "next dev --webpack",
    "build": "next build --turbopack",
    "start": "next start",

The pairing of webpack for development and turbopack for the build is unusual and suggests the two bundlers are not interchangeable across the project. Everything else is run through tsx, one script per operational job: a publish daemon, a daemon for the generation work, a doctor script that checks external tools, a cleanup script for stale jobs, and separate scripts for project status and project download. There is a Telegram integration with a webhook setter and a polling worker, an email stack with scripts for planned sends, campaigns and Resend provisioning, plus two migration scripts that move email contacts from Plunk and from Resend into a local store. The database is Prisma, with generate, migrate dev, migrate deploy and studio scripts. A public key directory and several environment example files, daemon.env.example, publish.env.example, ssh.env.example and example.env, show that the deployment is split across several distinct processes with their own credentials.

The script list is the actual feature documentation

Because the technical setup was moved to a separate document, the package scripts are the closest thing to a feature list, and they are worth reading as such. The type checking runs tsc with no emit across the main project and then again against a separate tsconfig for the welcome prank video, with another target for a common configuration, which tells you the project has a shared layer and a project-specific layer that are type-checked separately. The test script runs vitest, and the fast variant excludes the daemon and daemon-and-api test directories, which is a pragmatic split for a codebase where the integration tests need the heavy services. The templates script fills template data, the admin script sets an admin user, and the token script manages token balances, which is the piece that connects the API to the credit system the API documentation talks about. The repository also carries an AGENTS.md, an eslint config, a postcss config, a vitest config, several tsconfig files, a components.json, a content directory, a keys directory, a public directory, a scripts directory, a src directory and a tests directory. The presence of keys/ and the ssh environment example is a deployment detail worth noticing, since it implies a server-side signing setup for signed upload and delete grants, which the why section names as part of the production-oriented architecture.

Free for personal use, licensed for commercial hosting

The licensing is the part to read most carefully, and it is split in a way that is unusual for an open source repository. The cost positioning section states that for personal use YumCut is free, that a hosted version is already deployed at YumCut.com, and that if you want to host YumCut for clients, sell access, or run it as a commercial service, you need to acquire a commercial licence, with a licensing contact address given in the documentation. The licence field on the repository says Other, with a note that it is a custom licence GitHub cannot classify and that the LICENSE file is the place to look. Those two facts together mean this is not a permissively licensed codebase in the usual sense, and the distinction between personal use and running it as a service is the distinction between installing it and operating a business with it. This review takes no position on what the terms mean, and a team considering an agency deployment should read the LICENSE file and get a direct answer. The repository publishes no GitHub releases, and the last push was on 2026-09-03, so there is no versioned artefact to point at.

How it positions against the short-form tools you already know

The documentation names its competitors and says plainly where it does and does not compete. The tools directly focused on short vertical generation are listed as Clippie AI, Wava AI, FacelessReels, Faceless.video, Revid.ai and Viralmaxing. The adjacent tools are listed separately, with the qualifier that they are useful but have a different primary use case: Submagic for a strong caption and editing workflow, Klap for repurposing long-form into shorts, and Creatify for an AI ad creative focus. The distinction the project draws for itself is that it focuses on being the open-source and free analog for end-to-end short vertical generation, not only post-editing. That is a coherent position but it is a narrow one, and it is worth being honest about what it implies. A tool like Klap takes a long video you already have and cuts it down, and that problem does not need a model at all. YumCut starts from an idea and generates everything, which is a much more expensive and much more failure-prone path. The examples in the documentation show the range, with a Simpsons style video, a creepy Italian story video, the Simpsons video in Spanish, a 99 Nights in the Forest story video and a Bitcoin story video, and the language variants visible in that set are the clearest illustration of the multi-language use case.

Editorial conclusion

YumCut is a good fit for a creator, agency or growth team that publishes vertical video daily, that wants one idea turned into several language versions, and that is prepared to supply the model providers and the machine that runs the render. It is the wrong tool for a one-off video, since a hosted service is less work, and it is the wrong tool for a team that cannot take on FFmpeg, Prisma migrations and API key management. Before adopting it, read the technical document at docs/tech.md, because the setup and implementation details were moved out of the repository overview, and settle the licensing question first, since the licence field on the repository says GitHub cannot classify it and the project states that hosting it for clients or running it as a commercial service requires a commercial licence. The last push was on 2026-09-03 and the repository publishes no GitHub releases.

Frequently asked questions

Official sources

1. IgorShadurin/app.yumcut.com on GitHub
2. Issues
3. Project website
4. README