Where to Use Pypen¶
Pypen is intentionally generic: anything that you can run with
python something.py (or any shell command) is fair game.
These are the workloads the project was designed around.
Telegram / Discord / Matrix Bots¶
Long-running bots are the headline use-case. You typically want:
- Per-bot env vars (one token per project)
- Different Python versions for different bot frameworks
- Periodic restarts to drop stale connections
- A dashboard that shows what's alive
Pypen does all of that with one TOML entry per bot.
Scrapers & Data Pipelines¶
Scrapers benefit from idle restarts (something silently
stalled? bounce it), redeploy = "true" (refresh deps
that change often), and the bundled ffmpeg /
aria2 binaries.
Small Web Apps & APIs¶
Quart / FastAPI / Flask apps run perfectly well as workers. Use Pypen to host several side-projects on a single $5 VPS instead of paying for one dyno each.
Self-hosting Open-source Projects¶
Point Pypen at any GitHub Python project, give it a
run_command, and you get a managed deployment. The project
doesn't need to know anything about Pypen.
Classrooms, Homelabs, Hackathons¶
A teacher can run dozens of student projects on one server, each in its
own venv, isolated from the others. A homelab user can replace
tmux + nohup + crontab hacks with a single
file. A hackathon team can iterate on a deployed branch with
pull_commits = "true".
What Pypen Is Not For¶
- Replacing
initas PID 1 on a host. Usesystemd. - Container orchestration across many hosts. Use Kubernetes / Nomad.
- Sandboxing untrusted code. Workers share the container's kernel and filesystem.
- Heavy multi-tenant SaaS. Pypen is single-tenant by design.