Skip to main content


Beta Feature

Services are currently in beta and may be subject to change. We welcome your feedback. You can enable Beta features in your account settings.

A Divio application can include various independent services, such as a database, media storage, a message queue, and so on, in addition to its application code. These can be added, removed, and configured in the Services view of any application.


The available services depend on the application's cloud space. For example, S3 media storage is provided on AWS cloud spaces, and MS Blob storage is provided on Azure cloud spaces. See Available services for an outline of services currently offered.

Multiple instances of a service — for example, two Postgres databases — may be used simultaneously.

Environment variables

Each service provisioned for each environment will create an environment variable that can be used to configure the applications that need to be used.

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

Service management

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 yet to be 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, this allows you to populate it before the application's next deployment.

Detaching and removing

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

If a service is no longer required, it can be removed. However, an attached service must first 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 process safeguards a running application.


Services will exist in several 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

Dedicated storage and hosting providers handle default file storage in Divio applications.

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, our versatile default search engine, is provided and runs on public (shared) or private clusters in the same cloudspace as the web application. We support multiple versions of Elasticsearch, giving you the flexibility you need.


RabbitMQ, a robust and mature messaging and streaming broker, is easily deployable on cloud environments, on-premises, and even on your local machine. We offer RabbitMQ for messaging upon request, ensuring its reliability for your communication needs.