Service management (Beta)

Note

The Services view is currently provided as a Beta feature.

As well as its application code, a Divio project can include various services that are provided independently, such as a database, media storage, a message queue and so on. These can be added, removed and configured in the Services view of any project.

'Services'

Available services depend on the project’s region. For example, S3 media storage is provided on AWS regions, and MS Blob storage on Azure regions.

See Available services for an outline of services currently provided.

Multiple instances of a service - for example, two Postgres databases - may be used at the same time.

Environment variables

For each environment, each service provisioned will create an environment variable, that can be used to configure the applications that need to use it. Use the Divio CLI to obtain the values, for example:

divio project env-vars --all

See reading environment variables for more.

Service management via the Control Panel

Adding and attaching

Making a service available to an application is a two-stage process:

First, the service must be added to each environment that requires it. A unique prefix should be provided in case other instances of the same service have already been applied.

Next, the environment must be deployed. Deployment provisions the service, and attaches it to the application.

If required, the option exists to provision a service independently of attachment. In this state, the application has not yet been deployed with the environment variables it needs to use the service, but the service itself is functional and usable. In the case of a media storage or database service, for example, this would allow you to populate it in advance of the application’s next deployment.

Detaching and removing

A service may be detached if it is no longer to be used by the application. Like attachment, this requires a deployment to take effect.

If a service is no longer required, it can be removed. An attached service will need to be detached before it can be removed.

Removing a service is a destructive operation. It will permanently delete any data used by that service instance.

Detaching a service is non-destructive. However if the application depends on the service, detaching it may cause a deployment or runtime error.

In the case of a deployment error following a detachment command, the service will not be detached, and the application will continue running in its previous configuration. This safeguards a running application.

States

Services will exist in a number of states across their lifetime:

new provisioning pending attachment attached pending detachment detached removed
not functional functional usable by the application functional not functional