# LeronX Engine ships seven modules and keeps four of them closed

> The open-source core of a hosted video product: script generation, scene planning, asset matching, voice synthesis, FFmpeg rendering, subtitles and a plugin loader in Python, with cloud rendering, authentication, billing and the desktop app marked proprietary. Three runtime dependencies, ffmpeg as a prerequisite, and a clone URL in the README that does not match the repository it sits in.

**Leron-X/leronx** — LeronX — AI Image & Video Generation Platform

- Repository: https://github.com/Leron-X/leronx
- Stars: 525 · Forks: 77
- Language: Python
- License: MIT
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/leron-x-leronx

## The module table is an honest map of what you cannot have

The clearest thing in the README is a table of eleven modules with a status column, and seven of them are open while four are marked proprietary. The open ones are script generation with storyboard planning, the scene graph with transitions and composition, the text-to-speech abstraction layer, the FFmpeg pipeline with hardware acceleration configuration, subtitle generation with styling and timing, the stock footage API client for Pexels and Pixabay, and the plugin loader and registry. The closed ones are the distributed rendering cluster, Firebase authentication with phone verification, a Stripe and credits system, and an Electron or Tauri desktop application. The overview states the same boundary in prose: this is the engine core and not the full product as a service. So the shape is a company that has open-sourced the media work and kept the parts that touch money and identity. That is a defensible split, and it tells you precisely what a self-hosted deployment is missing before you discover it.

## The install commands point at a repository with a different name

The install section is three commands, and the first one does not work from the repository this README lives in:

```bash
git clone https://github.com/leronx/leronx-engine.git
cd leronx-engine
pip install -e ".[dev]"
```

The repository being replaced is Leron-X/leronx, while the clone URL names a different owner and a different repository name, and the directory you end up in is leronx-engine. The project tree diagram in the README is headed the same way. The PyPI distribution is also named leronx-engine while the package metadata lists the repository as the Leron-X/leronx one, and the issue tracker link at the bottom points at the other name again. None of this says the code is broken, and it is plausible this page was written for the published distribution and pasted into the development repository. But it is the first thing a new user hits, and an editable install is the only install route documented, so anyone following the quick start verbatim ends up somewhere other than where they are reading. Read the name from the repository you have, not from the command block.

## Plugin stages are named two different ways on the same page

The plugin system is described as able to extend any stage of the pipeline, and the two code examples that demonstrate it disagree about what the stages are called. The advanced pipeline example attaches a plugin to a stage called post_render and adds an overlay with an image, a position and an opacity. The plugin development example uses a metaclass to declare metadata, sets a stage of pre_render, and lists the valid values in a comment as script, scenes, voice, render and post. So the same concept appears as post_render in one snippet, pre_render in another, and a five-value enumeration in a comment, with render and post_render and post all plausibly meaning the same thing or meaning three different things. The other documented fields are consistent: a priority integer where a lower value runs first, a process method that receives the video or the context and returns it, and an optional cleanup method. The ordering guarantee from the priority field is the part to rely on; the stage vocabulary is the part to check against the loader in the source before you write anything.

## The benchmark table is a documentation claim across four machines

There is a table of render times, and it is the only performance claim in the repository, so it deserves careful reading rather than repeating. It gives three target lengths, 60, 120 and 300 seconds of video, against four configurations. On an RTX 4090 the figures are 45 seconds, 90 seconds and 4 minutes. On an RTX 3080, 72 seconds, 145 seconds and 6 minutes. On an M2 Max, 58 seconds, 115 seconds and 5 minutes. And on CPU only, 8 minutes, 16 minutes and 40 minutes. Two things follow. The GPU numbers are roughly real-time to two times real-time for short clips, and the CPU column is one to eight times the clip length, which is the number that matters if you were planning to render on a small instance. And the shape of the table tells you the cost is dominated by something that scales with output length rather than setup, since the 300-second column is not six times the 60-second column on any machine. These are documentation claims with no methodology attached: no hardware specification beyond the GPU name, no settings, no codec, and no indication of whether the timings include voice synthesis. Treat them as an order of magnitude.

## Three runtime dependencies, and ffmpeg is a prerequisite rather than one

The dependency list is short enough to read at a glance, which is unusual for a video pipeline and says something about the design. The runtime requirements are three: an HTTP client, a validation library and a terminal output library. Everything the renderer needs from the outside world is therefore a system binary rather than a Python package, which is why the prerequisites list names Python 3.10 or newer and ffmpeg 5.0 or newer side by side. The features section confirms the division: video rendering is described as an FFmpeg-based pipeline with transitions, effects and overlays, and GPU acceleration as CUDA and Metal support for rendering. So ffmpeg is the engine and the Python side orchestrates it. Optional extras cover the rest: a development group with a test runner, an async test plugin, a formatter and a linter, and a GPU group with torch and numpy. Notably absent from the runtime list is any text-to-speech or model client, which suggests those arrive through the plugin-based voice abstraction rather than as hard dependencies.

## Compose serves an API on port 8000 that the source tree does not describe

The Docker section is two lines: bring the stack up in the background, and the API is available on port 8000 locally. There is no route documentation, no server module in the directory listing, and no mention of that port anywhere else on the page. What the listing does show is the engine itself: a package init described as the pipeline orchestrator, a core pipeline class, a script package split into generator, config and storyboard modules, a scenes package split into graph and composition, and a voice package split into the abstraction base, provider implementations and an emotions module. The assets module is described in the table as an API client for stock footage, which is where the HTTP client dependency earns its place. So the port in the Docker section is either a development convenience, a future surface, or a leftover from the hosted product, and the repository does not say. Two example scripts sit alongside the tests, one for a single job and one showing plugins, and those are the honest entry points for evaluating this project.

## Version 1.0.0 classified as beta, on Python 3.10 through 3.12

The packaging metadata is where the release state is stated, and it is worth reconciling with the absence of tags. The distribution is named leronx-engine at version 1.0.0, licensed MIT, requiring Python 3.10 or newer, and classified as development status 4, beta, with classifiers for Python 3.10, 3.11 and 3.12 and topics for video and artificial intelligence. So a 1.0.0 version number and a beta classification coexist, which is common and worth noting but not a problem. The build is setuptools with a wheel requirement, the source lives under a src directory, and the test configuration puts that directory on the path and points at the tests directory, so the package layout is a src layout rather than a flat one. Formatting is pinned through black at a line length of 100 with a target of Python 3.12. The repository has no GitHub releases, a change log file, a security policy, a code of conduct and a contributing guide, and its default branch was last pushed on 1 July 2026.

## Conclusion

Adopt LeronX Engine if you want the media pipeline itself rather than the hosted product around it, since the seven open modules are the interesting part and the four closed ones are the parts you would have to rebuild anyway. The plugin stages and the scene graph are the extension points worth reading before anything else. Do not adopt it expecting the platform, because cloud rendering, authentication, billing and the desktop application are explicitly not in this repository, which means a self-hosted deployment has no user accounts and no credits system. Four things to check first. Which URL you actually clone, because the README's install commands point at a differently named repository and a differently named PyPI distribution. What ffmpeg version you have, since 5.0 or newer is a prerequisite and the renderer is built on it. Whether your plugins will find the stage names you expect, since the documentation uses two different vocabularies for them. And whether the benchmark figures mean anything on your hardware, since they are documentation claims across four machines rather than something you can reproduce from the page.

## FAQ

### What is LeronX Engine?

The open-source core of a hosted video creation platform, containing a modular pipeline that turns text prompts into rendered video: script generation, scene planning, asset management, voice synthesis, FFmpeg rendering, subtitles and a plugin system. It is MIT licensed, Python, requires Python 3.10 or newer and ffmpeg 5.0 or newer, and is classified as beta.

### Which parts of LeronX are not open source?

Four modules are marked proprietary: the distributed cloud rendering cluster, authentication with Firebase and phone verification, the Stripe and credits billing system, and the desktop application built with Electron or Tauri. The seven open modules are script, scenes, voice, render, subtitles, assets and plugins.

### How do I install LeronX Engine?

The documented route is an editable install from a clone, using the dev extra. Note that the clone command and the PyPI distribution are both named leronx-engine while this repository is Leron-X/leronx, so read the repository name from the copy you have rather than from the command block in the README.

### What can plugins hook into in LeronX Engine?

Any stage of the pipeline. A plugin declares a name, a stage, a priority where a lower value runs first, a process method that receives the video or the context and returns it, and an optional cleanup method. The documentation is inconsistent about stage names, showing post_render in one example, pre_render in another and a list of script, scenes, voice, render and post in a comment.

## Sources

- [Issues](https://github.com/Leron-X/leronx/issues)
- [Leron-X/leronx on GitHub](https://github.com/Leron-X/leronx)
- [License: MIT](https://github.com/Leron-X/leronx/blob/main/LICENSE)
- [README](https://github.com/Leron-X/leronx/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/leron-x-leronx