cotyledon
Cotyledon provides a framework for defining long-running services.
Decision gist · record as of 2026-08-14
Yes. Cotyledon is actively maintained, has low install friction, carries no known vulnerabilities, and solves a real problem for services that need multiprocess management without eventlet's overhead. It is well-suited for OpenStack-style telemetry and monitoring workloads, and more broadly for any daemon or long-running service that needs robust worker lifecycle and signal handling. Install it if you are building a service that spawns multiple workers and want clean, predictable process management.AI-flagged interpretation of the facts on this page — verify before relying
Before you install
- Requires Python 3.9 or later; designed for POSIX platforms (Linux) though multiprocessing support extends to non-POSIX systems.
- Low install friction with only two runtime dependencies (setproctitle and typing_extensions).
- Actively maintained with recent commits and a stable release history since 2016; supports current Python versions (3.9–3.13).
License · maintenance · safety
Apache-2.0 (permissive) — Licensed under Apache-2.0 (permissive), allowing commercial and private use with minimal restrictions.
last release 2025-12-23 (234 days) · last repo commit 2026-03-19 · 92 stars
0 known vulnerabilities (OSV.dev, 2026-08-14) · 198,438 downloads/mo, #9,730 on PyPI
Alternatives
Verify before relying
pip install cotyledon
from cotyledon import ServiceManager
class MyService(ServiceManager):
def run(self):
# long-running service logic
pass
if __name__ == '__main__':
service = MyService()
service.run()- Whether the framework supports graceful shutdown semantics beyond signal handling.
- Performance characteristics under high worker counts or rapid spawn/terminate cycles.
- Compatibility with containerized or orchestrated environments (Kubernetes, systemd).
What it is and what it does
Cotyledon is a framework for building long-running services that need to manage multiple worker processes, handle Unix signals cleanly, and reload configuration without restarting. It was created as an alternative to oslo.service for projects that don't want eventlet's greenlet overhead; instead, it uses Python's standard multiprocessing module, ensuring predictable behavior across single-worker and multi-worker deployments. The framework handles worker spawning, supervision, graceful termination, daemon reloading on SIGHUP, rate limiting for worker creation, and sd-notify integration.
You use Cotyledon by subclassing its ServiceManager and defining your service logic. It manages the lifecycle of child processes, ensures only one service manager runs at a time (via a seatbelt mechanism), and provides separate APIs for terminating child processes versus the master process. Unlike frameworks built on eventlet, Cotyledon's code path is identical whether you run one worker or many, and it supports non-POSIX platforms through multiprocessing rather than os.fork alone.
Use it for
- Build a telemetry or monitoring agent that spawns multiple worker processes to collect metrics from distributed systems.
- Create a message queue consumer service that scales horizontally by spawning workers to handle incoming tasks.
- Implement a daemon that reloads configuration on SIGHUP without restarting child processes or losing in-flight work.
- Develop a long-running background job processor that needs clean signal handling and process supervision.
- Run a service in a container or systemd environment where predictable process lifecycle and sd-notify support matter.
Worth the install?
AI-flagged interpretation of the facts on this page. Verify before relying on it.
Yes.
Cotyledon is actively maintained, has low install friction, carries no known vulnerabilities, and solves a real problem for services that need multiprocess management without eventlet's overhead. It is well-suited for OpenStack-style telemetry and monitoring workloads, and more broadly for any daemon or long-running service that needs robust worker lifecycle and signal handling. Install it if you are building a service that spawns multiple workers and want clean, predictable process management.
Install
cotyledon on PyPI
Before you install
Low install friction with only two runtime dependencies (setproctitle and typing_extensions). Actively maintained with recent commits and a stable release history since 2016; supports current Python versions (3.9–3.13).
Requires Python 3.9 or later; designed for POSIX platforms (Linux) though multiprocessing support extends to non-POSIX systems.
License in practice
Licensed under Apache-2.0 (permissive), allowing commercial and private use with minimal restrictions.
Quickstart
pip install cotyledon
from cotyledon import ServiceManager
class MyService(ServiceManager):
def run(self):
# long-running service logic
pass
if __name__ == '__main__':
service = MyService()
service.run()Verify before relying
- Whether the framework supports graceful shutdown semantics beyond signal handling.
- Performance characteristics under high worker counts or rapid spawn/terminate cycles.
- Compatibility with containerized or orchestrated environments (Kubernetes, systemd).
Package facts
| License | Apache-2.0 permissive |
| Python support | Supports the current Python release >=3.9 |
| Install friction | Low. Pure-Python wheel |
| Runtime dependencies | 2 packagessetproctitletyping_extensions |
| Maintenance | Actively maintained 234 days since the last release |
| Last repo commit | |
| First released | |
| Downloads | 198,438 / month, #9,730 on PyPI 30-day window, as of 2026-08-14 |
| Known vulnerabilities | None known OSV.dev, checked 2026-08-14 |
| Classifiers | Intended Audience :: Information TechnologyIntended Audience :: System AdministratorsOperating System :: POSIX :: LinuxProgramming Language :: PythonProgramming Language :: Python :: 3Programming Language :: Python :: 3.10Programming Language :: Python :: 3.11Programming Language :: Python :: 3.12Programming Language :: Python :: 3.13 |
Evidence: cotyledon-2.2.0-py3-none-any.whl
Tags
Let your AI agent find packages like this
Example. Real query, live index.
You found this page by searching. An agent finds it by wishing: SkillFed indexes 14,416 PyPI packages by what they can do, searchable in plain language.
wish › “worker process management”
- cotyledonCotyledon provides a framework for building long-running services…
- uvicorn-workerIntegrates Uvicorn's ASGI server with Gunicorn's process manager,…
- pyfunceble-process-managerProvides a multiprocess task queue framework with worker pools,…
Give your agent the search over MCP, or paste the wish link into any chat.
More Distributed Computing packages
gRPC Python is an HTTP/2-based RPC framework that enables you to define and call remote procedures across network boundaries using protocol buffers for serialization.
Install it if you need RPC communication in a distributed system or are integrating with existing gRPC services.
execnet lets you spawn and communicate with Python interpreters across local processes, remote hosts, and different platforms, using a simple API for task distribution and inter-process messaging.
However, the aging maintenance status (275 days since last release) means you should verify it meets your concurrency and performance needs before committing to a…
Cloudpickle extends Python's standard pickle module to serialize lambda functions, interactively-defined functions and classes, and other constructs that the default pickle cannot handle, making it suitable for cluster computing and remote code execution.
Install it if you need to serialize lambda functions, interactively-defined code, or non-standard Python constructs for cluster computing or distributed execution.
Provides a unified, open()-compatible Python API for streaming large files from remote storage (S3, GCS, Azure, HDFS, SFTP, HTTP) and local filesystems, with transparent compression support.
Install it if you work with large files on cloud storage or remote systems and want to avoid writing boilerplate around multiple SDKs.
Portalocker provides cross-platform file locking with support for exclusive and shared locks, plus Redis-based distributed locks and process-aware PID file locking.
Install it if you need file or process coordination; the optional extras (pywin32, redis) are only required for specific lock types.
Ray is a distributed computing framework that scales Python applications from a single machine to multi-node clusters, providing abstractions for parallel tasks, stateful actors, and shared objects.
See also mozprocess · supervisor · multiprocess · kantoku · pyfunceble-process-manager · dumb-init · python-daemon · uvicorn-worker · celery · circus