Self-hosted service
FujiwaraChoki/MoneyPrinter avatar
FujiwaraChoki/MoneyPrinter

MoneyPrinter: a local-Ollama pipeline that turns a topic into a YouTube Short

Automate Creation of YouTube Shorts using MoviePy.

13,969 stars1,811 forksPythonMIT

At a glance

What is it?
MoneyPrinter is a Python project that generates a short video from a topic string, using local Ollama models for the script and a Postgres-backed queue for the work. It is a self-hosted tool with real external API dependencies, not a push-button service.
Who is it for?
MoneyPrinter fits engineers who already run Ollama locally and want a self-hosted pipeline they can read and modify, and who accept that Pexels, ImageMagick and a Postgres queue are part of the deal. It is the wrong choice if you want a managed service with no API keys, or if you need a support commitment: pull requests are not being accepted, and the last push was on 2026-03-26.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 173 days ago.
What is it written in?
Mainly Python, 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 MoneyPrinter solves, and who it is actually for

Producing a short video by hand means writing a script, finding stock footage, cutting it to a voice track, burning in subtitles and uploading. MoneyPrinter collapses that into a topic string. You give it a subject, and the pipeline produces the video file. The README states the goal plainly: automate the creation of YouTube Shorts by providing a video topic.

The audience is narrower than the pitch suggests. This is a Python project with a Flask backend, a Docker Compose stack and a Postgres dependency, so the person who gets value from it is comfortable running containers, editing a .env file and reading tracebacks. Someone who wants a hosted editor will spend more time on setup than on making videos. The project is explicit that it is Ollama-first, meaning script generation and metadata run on local models rather than a hosted LLM API. That is the design decision that shapes everything else: no per-token cost, but you supply the GPU or CPU and you pull the model yourself.

One structural caveat sits at the top of the README. Pull requests will not be accepted for the time being. A tool you cannot upstream fixes into is a tool you fork, and that should factor into the decision before you build a workflow around it.

How the queue, worker and Ollama fit together

The repository layout shows three moving parts rather than a single script. docker-compose.yml defines a postgres service on port 5432, a frontend container serving on port 8001, and a backend container on port 8080 that runs backend/main.py. A fourth service, worker, runs the generation jobs. The README describes this as a DB-backed generation queue for restart-safe processing, which is the main architectural change from a simple script: a job survives a container restart because its state lives in Postgres, not in memory.

The data flow follows from that split. The frontend sends a request to the backend, the backend writes a job row, and the worker picks it up. The worker calls Ollama for the script and metadata, using OLLAMA_BASE_URL and OLLAMA_MODEL. In the Compose file the backend reaches a host Ollama through host.docker.internal:11434, with extra_hosts mapping host.docker.internal to host-gateway. That detail matters on Linux, where the host alias is not automatic. The worker then pulls stock footage through the Pexels API, assembles the video with MoviePy, and uses ImageMagick for text rendering, which is why the Dockerfile compiles ImageMagick 7.1.0-31 from source and sets IMAGEMAGICK_BINARY=/usr/local/bin/magick.

Database configuration is deliberately flexible. DATABASE_URL defaults to a Postgres connection string pointing at the postgres service, and .env.example notes that leaving DATABASE_URL empty gives a local SQLite default outside Docker. AssemblyAI is optional and only relevant if you use it for transcription.

Installing MoneyPrinter and running a first generation

The README points to setup.sh as an interactive setup script and to docs/quickstart.md for the detailed path. The project uses uv, and the Dockerfile installs dependencies with uv pip install --system -r pyproject.toml, so uv is the expected toolchain. Python 3.11 or newer is required according to pyproject.toml.

Start by copying the environment template and filling in the required keys. The README and .env.example agree that PEXELS_API_KEY is necessary for footage and IMAGEMAGICK_BINARY can be left empty for auto-detection.

bash
cp .env.example .env

Ollama must be running and the model must exist locally before the backend can generate anything. The README gives these two commands directly.

bash
ollama serve
ollama pull llama3.1:8b

If you run the full stack, Compose brings up Postgres, the frontend on 8001, the backend on 8080 and the worker. The backend container points at the host Ollama by default.

bash
docker compose up

Once the containers are healthy, open the frontend on port 8001, enter a topic, and start a generation. The job is written to Postgres and the worker processes it, so you can watch the worker logs rather than the browser tab if a job appears stuck. If ImageMagick is not found, the README's fallback is to set the path explicitly in .env, with doubled backslashes on Windows.

env
IMAGEMAGICK_BINARY="C:\\Program Files\\ImageMagick-7.1.0-Q16\\magick.exe"

Where MoneyPrinter breaks or becomes the wrong tool

The failure modes are mostly environmental, and they are the kind that cost an afternoon. ImageMagick is the classic one: the README devotes a FAQ entry to auto-detection failing and asks you to set IMAGEMAGICK_BINARY by hand. In Docker this is handled by compiling ImageMagick into the image, but a local install has no such guarantee.

playsound is the second. The README documents a wheel build failure and suggests installing wheel first with uv pip install -U wheel followed by uv pip install -U playsound. That is a workaround for a dependency that does not build cleanly on every platform, and it is pinned at 1.2.2 in pyproject.toml.

Ollama is the third and the most consequential. Because the project is Ollama-first, quality and speed are bounded by the model you pull and the hardware you run it on. The README does not document a fallback to a hosted LLM provider, so if local inference is not viable for you, this is not the right tool. The same applies to the Pexels dependency: no key, no footage.

Finally, the TikTok path depends on a session cookie. The README explains that you obtain the TikTok session ID by logging into TikTok in your browser and copying the sessionid cookie. Session cookies expire, and the documentation does not describe a refresh or rollback mechanism for that credential. Treat any upload automation as something you re-check rather than set and forget.

MoneyPrinter compared with MoneyPrinterTurbo

The searches around this project frequently land on MoneyPrinterTurbo, and the two are genuinely different bets rather than renamed versions of the same thing. MoneyPrinterTurbo is a separate repository, so anything said here about MoneyPrinter's internals does not transfer to it.

The difference that is visible from this repository is the inference layer. MoneyPrinter is Ollama-first: the README states that script generation and metadata are fully powered by local Ollama models, and .env.example ships OLLAMA_BASE_URL and OLLAMA_MODEL with a localhost default. That means no hosted LLM key is required for the generation step, and your prompts and topics stay on your machine. The cost is hardware and model management: you run ollama serve, you pull the model, and you own the latency.

The second difference is the queue. MoneyPrinter now runs a DB-backed generation queue with API, worker and Postgres in Docker. A single-process script that generates synchronously is simpler to start and simpler to debug, but it loses in-flight work when it crashes. MoneyPrinter trades that simplicity for restart-safe jobs, and it asks you to run Postgres to get it. If you are generating one video occasionally, that trade is probably not worth it. If you are queueing many, it is the reason to pick this project over a plain script.

Maintenance, upgrade cost and the MIT licence

The repository is not archived, but the last push was on 2026-03-26, which is roughly six months before the date of this article. That is a gap worth noting rather than glossing over: the project is not being pushed to frequently at the moment, and the README states that pull requests will not be accepted for the time being. Anyone adopting it should plan to maintain a fork if they need changes.

Upgrade cost is driven by pinned dependencies. pyproject.toml pins requests, moviepy, flask, sqlalchemy, psycopg and others to exact versions, and the Dockerfile compiles ImageMagick 7.1.0-31 from a source tarball. Moving to a newer MoviePy or ImageMagick means testing the rendering path yourself, because the pins are the only compatibility statement the repository makes. There are no retrieved releases, so upgrades are tracked through commits on main rather than versioned tags.

The licence is MIT, per the repository metadata and the LICENSE file the README points to. That is permissive and generally friendly to commercial use, but it comes with no warranty. The project also bundles fonts and depends on Pexels footage and TikTok upload; those are separate terms you accept when you use them, and this article is not legal advice. Check the licence of any asset you redistribute.

Editorial conclusion

MoneyPrinter fits engineers who already run Ollama locally and want a self-hosted pipeline they can read and modify, and who accept that Pexels, ImageMagick and a Postgres queue are part of the deal. It is the wrong choice if you want a managed service with no API keys, or if you need a support commitment: pull requests are not being accepted, and the last push was on 2026-03-26. Before adopting it, verify that your Ollama model is pulled and reachable from the backend container, that ImageMagick is detected or IMAGEMAGICK_BINARY is set, and that PEXELS_API_KEY is present, because the pipeline stops at each of those points.

Frequently asked questions

Which AI provider does MoneyPrinter use?

MoneyPrinter is fully Ollama-based. You start Ollama, pull a model such as llama3.1:8b, and select the model in the UI.

How do I install MoneyPrinter?

The README points to an interactive setup script at setup.sh and to docs/quickstart.md. Dependencies are installed with uv, and Python 3.11 or newer is required.

How do I get the TikTok session ID for MoneyPrinter?

Log into TikTok in your browser and copy the value of the sessionid cookie. The README does not describe a way to refresh it automatically.

Why is MoneyPrinter not detecting my ImageMagick binary?

The README says MoneyPrinter auto-detects ImageMagick from PATH on Linux, macOS and Windows. If that fails, set IMAGEMAGICK_BINARY in .env, using double backslashes in the path on Windows.

Why does installing playsound fail for MoneyPrinter?

The README documents a wheel build failure and suggests running uv pip install -U wheel followed by uv pip install -U playsound. If that does not resolve it, the README points to docs/troubleshooting.md, the Discord, or a new issue.

Does MoneyPrinter need a database to run?

The README describes a DB-backed generation queue with API, worker and Postgres in Docker, and docker-compose.yml defines a postgres service. Outside Docker, .env.example notes that leaving DATABASE_URL empty gives a local SQLite default.

Official sources

  1. FujiwaraChoki/MoneyPrinter on GitHub
  2. Issues
  3. License: MIT
  4. README
Community notes

Community notes