Slack channel

The aim of the auto-sleep project is to give the ability for Cloud Foundry users to automatically have their app stopped after a given period of inactivity, and then automatically started when accessed through traffic received on their routes.

You can check the full specifications and the currently supported features in the acceptance tests.

Get a deeper introduction in the Autosleep talk at Cf Summit Santa Clata 2016 ( slides, youtube video recording, and high-res demo )

For now we provide a service broker which instances will:

• automatically bind applications in space (filtering out applications whose name matches a regexp).
• watch every bound application, measure inactivity (based on https logs and redeploy/restart events) and stop the application when an inactivity threshold is reached.
• a service dashboard for users to understand behavior of the service (such as time to sleep or current enrollment status)
• automatic restart on incoming HTTP trafic

Download latest release if you want to give it a try, or build from sources

We manage our roadmap as github issues, following is however an overview of planned short-term work:

• Hardening, optimizations
• Automatic enrollemnt of new spaces and orgs

We suppose that the autosleep service broker is already available in your market place. If you need help on that check how to publish service broker.

Create an autosleep service instance to watch all applications in the space and automatically put them to sleep after default idle duration:

cf cs autosleep default my-autosleep

Autosleep will periodically automatically bind every applications in the space to this service instance (if you want to fine tune which apps gets auto-bound, please use the exclude-from-auto-enrollment parameter to exclude some apps).

Once bound, your application will be watched for inactivity, and automatically stopped by the autosleep service. If you wish to disable this watch, simply unbind your application from the autosleep service instance.

Optionally the autosleep service broker accepts the following parameters during service creation:

• idle-duration
• exclude-from-auto-enrollment
• auto-enrollment
• secret

Only the auto-enrollment field is is mutable, i.e. is accepted on service updates, e.g. cf cs autosleep default my-autosleep -c '{"auto-enrollment": "normal", "secret": "Th1s1zg00dP@$$w0rd"}'

If you need to update other fields (e.g. idle-duration), rather choose to instanciate a new service instance.up

Duration after which bound applications will be considered as inactive. The time format used is [the ISO8601] (https://en.wikipedia.org/wiki/ISO_8601#Durations) duration format.

• Example:'{"idle-duration": "PT1H15M"}' would stop the application after 1 hour and 15 minutes of inactivity.
• Default value : 24H

If you don't want all the application to be automatically bound, you can set this parameter with a regular expression to filter on application names.

• Example:'{"exclude-from-auto-enrollment": ".*"}' wouldn't automatically bind any application in the space. Application would have to be bound manually.
• Default value : none (every app in space will be bound).

By default this parameter is set as standard. If platform teams (admins, org managers, or specific members of the space) don't want all space members to be able to manually permanently unbound apps from the autosleep service themselves, then a forced mode is supported.

In a forced auto-enrollment mode then:

• manually unbound apps will automatically be re-bound again after the inactivity period. Until the then, app teams are free to delete the app if a cleanup is necessary.
• the autosleep service-instance won't be deletable by space members to disable next auto-enrollments

To enable to forced mode, set the auto-enrollment parameter to forced. As this is a protected parameter, you will have also have to provide a secret parameter.

• Example:'{"auto-enrollment": "forced"}'
• Default value : standard

Provide a secret if you wish to set/change a protected parameter. Please save it carefully, has you will be asked to provide the same secret the next time you set/change a protected parameter. As a fallback, you may also use the credential password set at deployment time (see the security.user.password in publish documentation).

• Example:'{"secret": "Th1s1zg00dP@$$w0rd"}'
• Default value : null

If you wish to build the app yourself, go to build documentation.

Once you built the application or if you got it from latest release, go to publish documentation.

Acceptance tests are available in the source code, as robotframework tests. More information here.