MoneyPrinter: local Ollama video generation with a Postgres-backed queue

What MoneyPrinter generates and for whom

MoneyPrinter takes a video topic as input and produces a finished YouTube Short. The README describes it as automating "the creation of YouTube Shorts by providing a video topic", and the package description in pyproject.toml repeats that line verbatim. The target user is someone who wants a repeatable pipeline rather than a manual editing session: script text, voice, background footage and subtitles assembled without opening a timeline editor.

The project is explicitly local-first on the language side. The README states that MoneyPrinter is "Ollama-first: script generation and metadata are fully powered by local Ollama models." That is a deliberate constraint, not an accident. It means no OpenAI key is needed for the writing step, and it also means output quality tracks whatever model you pull. A small quantised model will produce flatter scripts than a larger one, and the repository does not ship a quality baseline to compare against.

This is not a general video editor. It is a narrow generator for one format, vertical short-form, driven by a single topic string.

The API, worker and Postgres queue behind each Short

The most consequential change described in the README is architectural. MoneyPrinter "now uses a DB-backed generation queue (API + worker + Postgres in Docker) for reliable, restart-safe processing." That sentence is the whole design in miniature, and docker-compose.yml shows how it is wired.

Four services are defined. postgres runs postgres:16-alpine on port 5432 with a pg_isready healthcheck, retrying ten times at five-second intervals. frontend serves static files on port 8001 via python3 -m http.server with --directory frontend. backend runs python3 backend/main.py on port 8080 and holds the environment variables that matter: ASSEMBLY_AI_API_KEY, TIKTOK_SESSION_ID, PEXELS_API_KEY, IMAGEMAGICK_BINARY, OLLAMA_BASE_URL, OLLAMA_MODEL and DATABASE_URL. A worker service runs the same image with a different command.

That split is the reason restarts are safe. A generation job is a database row, not an in-memory task, so killing the worker mid-render does not erase the request. The backend depends_on frontend and postgres, and it mounts ./files at /temp plus ./Backend and ./fonts into the container, which tells you where intermediate artefacts land.

One detail worth noting: the backend sets extra_hosts with host.docker.internal:host-gateway so a containerised backend can reach an Ollama instance running on the host, which is why OLLAMA_BASE_URL defaults to http://host.docker.internal:11434 in compose but http://localhost:11434 in .env.example. Getting that wrong is a common silent failure.

Installing MoneyPrinter and generating a first Short

The repository ships an interactive setup script at setup.sh and centralises documentation under docs/, including a quickstart. The Python requirement is stated in pyproject.toml as >=3.11, and the Dockerfile builds from python:3.11-slim-buster, so the two paths agree on the interpreter version.

Ollama has to be running before anything else works, because the README makes it the sole provider for script generation. Start the server and pull the model named in the default configuration.

ollama serve
ollama pull llama3.1:8b

The first command starts the local inference server on its default port. The second downloads the model that OLLAMA_MODEL points at in .env.example. If you skip the pull, the generation step has nothing to call.

Next, copy the environment template and fill in the keys. Pexels supplies background footage and is listed as necessary, not optional.

cp .env.example .env

Open .env and set at minimum PEXELS_API_KEY. Leave IMAGEMAGICK_BINARY empty to auto-detect from PATH, which the README says works on Linux, macOS and Windows. If detection fails, set the path explicitly with escaped backslashes on Windows, as the README's own example shows:

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

For the queued Docker path, bring up the stack. This starts Postgres, the static frontend on 8001, the backend API on 8080 and the worker.

docker compose up

After the containers settle, the frontend is reachable on port 8001 and the API on 8080. Submit a topic there, and the job should appear as a row in Postgres before the worker picks it up. If the worker container exits immediately, the database connection string is the first thing to check.

Where MoneyPrinter fails or is the wrong tool

The dependency list in pyproject.toml pins several packages to exact versions, including moviepy==2.2.1, pillow==9.5.0, flask==3.0.0 and ollama==0.5.1. Exact pins make reproducibility easier but they also mean an upgrade of any one of those libraries has to be tested against the rest. MoviePy 2.x changed its API substantially from 1.x, so anyone holding tutorial code written against an older MoneyPrinter will find it does not transfer.

playsound==1.2.2 is a known friction point. The README devotes a FAQ entry to it, offering a workaround rather than a fix:

uv pip install -U wheel
uv pip install -U playsound

That the project documents a wheel build failure for a core audio dependency is a signal about the age of that package, not about MoneyPrinter's own code.

There is also a governance limitation that matters more than any bug. The README states plainly that "Pull Requests will not be accepted for the time-being." For a project with a plugin-shaped surface, that is a real constraint: fixes and extensions have to live in forks. Combined with a last push on 2026-03-26, which is roughly six months before today, this is a project to adopt as-is rather than one to invest in upstream.

Finally, the local-model requirement is a hardware requirement. Running llama3.1:8b alongside MoviePy rendering and a Postgres container on one machine is a heavier footprint than a cloud API call, and the documentation does not publish minimum specifications.

MoneyPrinter compared with MoneyPrinterTurbo

The related searches around this project are dominated by a different repository, moneyprinterturbo, and the confusion is understandable given the shared name. The approaches differ in a way that matters for deployment.

MoneyPrinterTurbo is a separate project and is not described in this repository's files, so the honest comparison stops at what MoneyPrinter itself declares. MoneyPrinter's README is explicit that it is "fully Ollama-based" and that script generation and metadata are "fully powered by local Ollama models." That is an architectural commitment to local inference: no hosted LLM key appears in .env.example, and the only external writing dependency is the Ollama server you run yourself.

If your constraint is that prompts and scripts must never leave your machine, that design is the reason to pick this project. If your constraint is that you do not want to run or size a local model, the same design is the reason to look elsewhere. The queue architecture is a second axis: the API, worker and Postgres split in docker-compose.yml is more operational surface than a single-process script, and it buys restart safety in return. Anyone comparing the two projects should compare those two decisions, local inference and queued execution, rather than feature lists.

Licence, maintenance and the cost of upgrading

MoneyPrinter is MIT licensed, per the repository metadata, and the README defers to the LICENSE file for the full text. MIT is permissive: it allows commercial use, modification and redistribution provided the copyright notice and permission notice are preserved. That is a summary of the licence's general shape, not legal advice, and anyone embedding this in a product should read the LICENSE file and the licences of the bundled dependencies, several of which carry their own terms.

The operational cost of upgrading is dominated by the pinned dependency set. Because pyproject.toml pins moviepy, pillow, flask and ollama to exact versions, an upgrade is not a matter of bumping one number. Each pin has to move together, and the Dockerfile rebuilds ImageMagick 7.1.0-31 from source with a long list of configure flags, which makes image builds slow and couples the container to that specific ImageMagick tag.

The last push to the default branch was on 2026-03-26. The repository is not archived, but six months without a push, combined with the stated policy of not accepting pull requests, means the practical upgrade path is your own fork. Budget for that before you build a workflow on top of it.

Editorial conclusion

Adopt MoneyPrinter if you already run Ollama locally and want topic-to-Short generation on your own machine, with a queue that survives restarts. Do not adopt it if you need a hosted service, a stable plugin API, or GPU-free operation on a laptop with little RAM, since a local llama3.1:8b pull and MoviePy rendering both want real resources. Before committing, verify three things: that ImageMagick is detected or IMAGEMAGICK_BINARY points at a real binary, that the Postgres container in docker-compose.yml reaches a healthy state, and that the worker container is actually consuming jobs rather than sitting idle.

Frequently asked questions

Official sources

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