CAF Example Apps

To run an example: start the Launcher », create an account (or just login), type the application name (or use the Find button), choose an instance name, and click Load App.

The hideable left panel switches between instances. Even when an instance is not currently selected, its CA keeps on running in the cloud, creating the illusion of local background processing. We call this cloud-based multi-tasking.

The next time you login, even when using a different device, all your example instances will be there, and you will see their progress while you were away...


Bare bones example described in the Getting Started tutorial.

Shows how a client can invoke a CA method and receive notifications triggered by its CA's autonomous behavior.

Your CA keeps a counter that is periodically incremented, and notifies you whenever its value is a multiple of five.


Uses a CA to cache and hash the contents of a URL. Auto mode keeps monitoring that URL for changes, repeating this operation whenever is needed.

Note that we rely on a proper ETag http header to detect changes. Also, some freebie cloud storage services (such as Dropbox™) will freeze public access if you use Auto mode for too long.


Establishes an ad-hoc social graph to allow a group of friends to monitor each other's mood.

We use a publish/subscribe back-end service (Redis) to propagate mood changes.

Your CA provides you with a permanent presence, and even if you are not on-line, your friends can know your last mood, and mood change announcements will never be lost.


Your CA combines several e-mail (imap) accounts into a unified view, pushing changes to the client when any of them gets a new message.

To try it do NOT use important e-mail accounts, we cannot guarantee at this point that your messages or login credentials will be safe.

We have setup a few dummy accounts: {username: cloudassistant[1..3], password: pleasechange, server:, port: 993}. If they get abused, we will remove them without further notice.


This app simulates the purchasing of a list of items, and even when we introduce random client or server failures, each item will be bought only once.

We use persistent sessions (see CAF Design), to allow an stateless client to know the last item successfully bought before the failure. During recovery we skip items that have already been bought.

An induced server failure will kill the node.js process, affecting not only your CA, but all the CAs hosted by that process; therefore, you will experience random pauses caused by the killing habits of other users.


Showcases Sharing Actors (see CAF Design) by replicating code used by all CAs.

You should first start an instance with name admin. This instance periodically writes into a shared map a random function and its inverse.

Every other instance that you create will read that map and repeatedly apply this function and its inverse.

Our implementation of Sharing Actors guarantees the Atomicity, Isolation, and Fairness properties described in CAF Design. Therefore, even though we do not coordinate function changes, the final result is always the original value (i.e., 42).


Turtles is an app to deploy other apps. After an app has been deployed anybody can get its own instance by just typing its name in the Launcher. App names are always prefixed by your username and the name of your turtles instance (separated by reserved character _).

Internally we use pull to monitor a URL containing a compressed tarball with your app. When it changes we prompt you to upgrade (or deploy) your app. CAF upgrades apps without losing state, and this minimizes disruption for end users.

The structure of the tarball follows npm conventions (top level dir called package) but it should also contain fully resolved dependencies. The script tools/ app_name can create that tarball for you in /tmp. Note that before executing that script you need to run tools/ to configure your environment.

If you want to skip turtles and run your app locally see Local Setup.