Skip to main content

Service management (Beta)


The Services view is currently provided as a Beta feature.

As well as its application code, a Divio application 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 application.


Available services depend on the application's cloudspace. For example, S3 media storage is provided on AWS cloudspaces, and MS Blob storage on Azure cloudspaces.

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.

For more information about environment variables, including how to retrieve their values, see How to manage your application's environment variables.

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.


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

new / provisioningpending attachmentattached / pending detachmentdetachedremoved
not functionalfunctionalusable by the applicationfunctionalnot functional

Available services


We provide Postgres and MySQL databases by default; other database systems can be provided on request.

Postgres is our database of choice, and configured by default with all applications.

Databases can use public (shared) or private clusters in the same cloudspace as the web application.

Media object storage

Default file storage in Divio applications is handled by dedicated storage and hosting providers.

Depending on the application's cloudspace, these can be S3 providers such as Amazon Web Services's S3 service or a generic S3 hosting service via another provider, or MS Azure Blob storage.

By default, media files are served by a Content Delivery Network in order to provide better performance.


Elasticsearch is provided as our default search engine, running on public (shared) or private clusters in the same cloudspace as the web application. We support multiple versions of Elasticsearch.


We provide RabbitMQ for messaging.