capataz: OTP-like supervision trees in Haskell

[ concurrency, control, library, mit ] [ Propose Tags ]

capataz enhances the reliability of your concurrent applications by offering supervision of green threads that run in your application.

Advantages over standard library:

  • Links related long-living processes together under a common capataz supervisor, with restart/shutdown order

  • Set restart strategies (Permanent, Transient, Temporary) on IO sub-routines on a granular level

  • Set restart strategies on a pool of long-living worker threads (AllForOne, OneForOne)

  • Complete telemetry on the sub-routine lifecycle of your application (start, error, restarts, shutdown)

[Skip to Readme]




Maintainer's Corner

For package maintainers and hackage trustees


  • No Candidates
Versions [RSS],,,,,,
Change log
Dependencies async (>= && <2.2), base (>= && <4.11), bytestring (>= && <0.11), data-default (>= && <0.8), protolude (>=0.2 && <0.3), safe-exceptions (>= && <0.2), stm (>= && <2.5), teardown (>= && <0.4), text (>= && <1.3), time (>= && <1.9), unordered-containers (>= && <0.3), uuid (>=1.3.13 && <1.4), vector (>= && <0.13) [details]
License MIT
Copyright © 2018 Roman Gonzalez
Author Roman Gonzalez
Category Control, Concurrency
Home page
Bug tracker
Source repo head: git clone
Uploaded by RomanGonzalez at 2018-01-02T05:22:39Z
Distributions LTSHaskell:, NixOS:
Downloads 3703 total (28 in the last 30 days)
Rating (no votes yet) [estimated by Bayesian average]
Your Rating
  • λ
  • λ
  • λ
Status Docs available [build log]
Last success reported on 2018-01-02 [all 1 reports]

Readme for capataz-

[back to package description]


Our greatest glory is not in never failing, but in rising every time we fail.– Confucius

Table Of Contents

Raison d'etre

As time progresses, I've come to love developing concurrent applications in Haskell, its API (STM, MVars, etc.) and light threading RTS bring a lot to the table. There is another technology that is more famous than Haskell in regards to concurrency, and that is Erlang, more specifically its OTP library.

If you wonder why that is, you may need to look into the OTP library design, actors systems (in general) provide an architecture that enables applications to be tolerant to failure through the enforcement of communication via message passing and by making use of a critical infrastructure piece called a Supervisor.

After trying to replicate Erlang's behavior on Haskell applications by using the distributed-process library (a clone of OTP), and after implementing several (disposable) iterations of actor systems in Haskell, I've settled with just this library, one that provides a simple Supervisor API.

This library is intended to be a drop-in replacement to forkIO invocations throughout your codebase, the difference being, you'll need to do a bit more of setup specifying supervision rules, and also pass along a reference of a capataz descriptor to every thread fork.

Why not distributed-process?

distributed-process is an impressive library, and brings many great utilities if you need to develop applications that are reliable. However, it is a heavyweight solution that will enforce serious changes to your application. It also optimizes its implementation around the distributed part of its name. This library is intended to provide some benefits of distributed-process , without the baggage.

Why not a complete actor system?

Actor systems are very pervasive, they impose specific design constraints on your application which can be rather expensive. This library attempts to bring some of the reliability benefits of actor systems without the "change all your application to work with actors" part of the equation.

That said, this library can serve as a basis for a more prominent library that provides an opinionated Inter-Process communication scheme. If you happen to attempt at doing exactly that, please let me know, I would love to learn about such initiatives.

Why not async?

async is a fabulous library that allows Applicative composition of small asynchronous sub-routines into bigger ones and link errors between them. Given this, async fits the bill perfectly for small operations that happen concurrently, not necessarily for long living threads. This library attempts not to replace async's forte, but rather provides ways to make threads reliable in situations where the usage of async or forkIO would give you the same outcome.


Documentation can be found here


Hackage Stackage LTS Stackage Nightly

Make sure you include the following entry on your cabal file's dependecies section.

  build-depends: capataz

Or on your package.yaml

- capataz


Build Status Github Hackage Dependencies

Follow the developer guidelines

In next release

  • Add support for supervising supervisors
  • Ensure unit tests always finish on all concurrent scenarios (dejafu experiment)