Plombery schedules Python pipelines and shows you the run in a browser

Recurring Python scripts, with a screen instead of a log file

The one line description is a Python task scheduler with a user-friendly web UI, and the About section is more specific about who it is for: if you need to run and monitor recurring python scripts then it's the right tool for you. That is a narrow job and the project does not pretend otherwise. The same section carries a warning that the project is at its beginning, so it can be shaped and improved with feedback, and the Getting Started section simply points you at the official website and a GitHub Codespaces environment with demo pipelines, so you can see the thing running before you install anything. The feature list explains what you get in practice. Task scheduling is based on APScheduler and supports Interval, Cron and Date triggers, which between them cover the three ways people actually schedule work. There is a built-in web interface, with no HTML, JS or CSS coding required. Pipelines and tasks are defined in pure Python, and pipelines can be parametrized via Pydantic, which means the same pipeline can be run with different inputs from the UI or the API. Pipelines can be run manually from the web UI, each run can be debugged by exploring logs and output data, you can monitor pipelines and be alerted if something goes wrong, and the REST API is there for advanced integrations. The whole stack is Python on the back end with a React and TypeScript front end.

The dependency list tells you the architecture

The package metadata is a good map of what the application actually is. The scheduler is apscheduler pinned to 3.11.3, so the trigger semantics are APScheduler's rather than something reinvented. The web layer is FastAPI with uvicorn, which gives the REST API and the web UI the same origin, and python-socketio is there for the live updates the UI needs while a pipeline runs. Data handling is SQLAlchemy with alembic for migrations, so run history and configuration live in a relational database rather than in memory. Authentication is handled by authlib with itsdangerous, and the README says the application is secured via OAuth2, which is a notable choice for a self-hosted tool, because it means you can put it behind an identity provider instead of inventing a password store. Jinja2 renders the pages, click provides the command line entry point, and the package registers a script called plombery pointing at plombery.cli:main. Pydantic and pydantic-settings handle the parameterisation of pipelines and the configuration. Two dependencies are worth singling out. apprise is the alerting layer behind the promise to get alerted if something goes wrong, since it can send notifications through many services, and uuid6 suggests identifiers are generated in a time ordered way, which matters when runs are ordered by creation. The project requires Python 3.10 or newer and below 3.15, and the licence is MIT.

Running it locally: uv, pnpm, then one command

The development setup is documented precisely, and it is a two toolchain project. Plombery uses uv for Python and pnpm for the frontend, and you need Python 3.10 or newer, which uv installs for you if you do not have it, and Node 22.12 or newer. After cloning, uv sync creates the virtual environment and installs the dependencies.

uv sync

The frontend is a React app in frontend/, and the Python package serves its build output, so the frontend has to be built once before the app runs.

cd frontend/
pnpm install
pnpm build

Then you run the example app, which registers a handful of demo pipelines. The --reload flag restarts Plombery whenever a file changes, and --reload-dir adds the Plombery package itself to what is watched, so editing the library restarts the app too.

cd examples/
plombery run --pipelines src --reload --reload-dir ../src

Open http://localhost:8000 and the demo pipelines are there, ready to run. For frontend work you leave that running and start the Vite dev server in another terminal, which hot reloads the interface and talks to the API on port 8000.

cd frontend/
pnpm dev

The two-process arrangement is the one thing to plan for. The Python package serves a built frontend in production, but in development the UI is served by Vite and the API by the Python app, which is a normal split for a React plus FastAPI project and one that you have to remember when a change does not appear.

Tests, docs and the Codespaces shortcut

The testing story is plain pytest, and the README gives both the whole suite and the single test forms.

pytest

pytest tests/test_api.py
pytest tests/test_api.py::test_api_list_pipelines

The documentation site is built with MkDocs and its Material theme, with the source in the docs/ folder and the configuration in mkdocs.yml, and a local dev server is one command away.

mkdocs serve

The dependency groups in the package metadata show what each audience needs. The dev group holds black, coverage, flake8, pytest with asyncio and env plugins, pandas, and watchfiles, and the comment on pandas is worth reading because it explains a design decision: returning a DataFrame from a task is a supported pattern, so the regression test covering it has to actually run. The examples group holds pandas and python-dateutil, and the comment there explains that the demo pipelines in examples/ import them so running the examples needs no environment of its own, and that ssl_certificates.py imports dateutil directly and should say so. The uv configuration sets default-groups to dev and examples, so a plain uv sync gives a contributor everything. The Codespaces path is the fastest way to see the product, since the environment builds the frontend and opens the home page in a browser tab, and changes to the Python code are reflected in the web page immediately.

The two cases the README says you should not use it

Most project READMEs list what a tool does. This one also lists what it is not for, and the list is short enough to quote. You should not use it when you need a lot of scalability and you want to run on a distributed system, and you should not use it when you want a no-code tool or you do not want to use Python. Both exclusions follow from the design rather than from a missing feature. The first is about the deployment model, since this is a FastAPI application with a SQLAlchemy database and a local APScheduler instance, so a job that must survive a machine failure, run in parallel across workers or be scheduled across a cluster is outside what it is built to do. The second is about the definition language, since pipelines are pure Python with Pydantic parameters, and a workflow that a colleague who does not write Python has to change will stay a Python problem. If your jobs are short and idempotent, running on one box, and owned by people who write Python, none of this matters. If either condition fails, the honest answer is that you want a different tool, and the README says so before you install anything.

Where Plombery sits against cron, Airflow and a plain script

The alternatives differ on axis of how much you give up. A plain cron entry and a script is the baseline. You get scheduling for free and you get nothing else: no interface, no run history you can browse, no parameterisation, and when a job fails at 3am the only artifact is whatever your script wrote to disk. Plombery takes cron's job and adds the observation layer, the browser view of a run, the parameterised pipeline and the API, and in exchange it asks you to express the work as a Python pipeline and to run a service. A heavier orchestrator gives you a data pipeline DAG model, a plugin ecosystem and distributed execution, and it asks for a much larger deployment and a bigger conceptual commitment than a handful of scripts need. The middle ground in between is a task queue with a dashboard, which gives you run history and retries but not a place to write a pipeline with parameters in a handful of lines. Plombery sits closer to the lightweight end of that spectrum by design, which is also why the scalability exclusion is in the README. The practical test is whether your jobs are a set of recurring scripts, in which case a scheduler with a UI removes real friction, or a set of dependent data flows, in which case the model here is the wrong shape and you would be reimplementing a DAG engine in Pydantic classes.

Editorial conclusion

Plombery suits a team or an individual who runs recurring Python scripts on one machine and wants a browser view of what ran, what it cost in time and what it produced, rather than reading log files. It is the wrong tool if your jobs need to be distributed across machines, because the README says outright that you should not use it when you need a lot of scalability and want to run on a distributed system, and it is the wrong tool if the person who owns the workflow refuses to write Python, since pipelines are defined in pure Python by design. Before you build on it, look at the examples directory, because a handful of demo pipelines come with the repository, and confirm that your scheduling needs fit the Interval, Cron and Date triggers that APScheduler provides.

Frequently asked questions

Official sources

1. License: MIT
2. lucafaggianelli/plombery on GitHub
3. Project website
4. README
5. Releases