Python is a programming language that lets you work more quickly and integrate your systems more efficiently.

Python 2.7, 3.7, 3.8, 3.9, 3.10 and 3.11 are available on Clever Cloud. You can use Git to deploy your application.

Create an application on Clever Cloud

With the web console

Refer to Quickstart for more details on application creation via the console.

With the Clever Tools CLI

  1. Make sure you have clever-tools installed locally or follow our CLI getting started guide.
  2. In your code folder, do clever create --type <type> <app-name> --region <zone> --org <org> where :
    1. type is the type of technology you rely on
    2. app-name the name you want for your application,
    3. zone deployment zone (par for Paris and mtl for Montreal)
    4. org the organization ID the application will be created under.

Refer to clever create for more details on application creation with Clever Tools.

Setting up environment variables on Clever Cloud

With the Clever Cloud console

  1. Go to the Clever Cloud console, and find the app you want to fine tune under it’s organization.
  2. Find the Environment variables menu and select it.
  3. In this menu, you will see a form with VARIABLE_NAME and variable value fields.
  4. Fill them with the desired values then select Add.
  5. Don’t forget to “Update Changes” at the end of the menu.

With the Clever Tools CLI

  1. Make sure you have clever-tools installed locally. Refer to our CLI getting started.
  2. In your code folder, do clever env set <variable-name> <variable-value>

Refer to environment variables reference for more details on available environment variables on Clever Cloud.

You can of course create custom ones with the interface we just demonstrated, they will be available for your application.

Configure your Python application

General configuration

Python apps can be launched in a variety of ways. You can specify how to start your application (for instance which module to run) by setting environment variables.

To select which module you want to start, use the CC_PYTHON_MODULE environment variable.


The module (without .py) must be importable, i.e. be in PYTHONPATH. Basically, you should just point to a WSGI capable object.

For example with Flask, it’s gonna be the name of your main server file, followed by your Flask object: server:app for instance if you have a file at the root of your project with a Flask app object inside.

You can also use CC_RUN_COMMAND to launch Python application your way. In such case, it must listen on port 9000.

Choose Python version

The default version of python on Clever Cloud is 2.7. If you want to use python 3.x instead, create an environment variable CC_PYTHON_VERSION equal to either 3 (which will default to the most up-to-date version), 3.7, 3.8, 3.9, 3.10 or 3.11.

Note: the version is a number, do not use quotes. values allowed are 2, 2.7, 3, 3.7, 3.8, 3.9, 3.10, 3.11.

Choose Pip version

The default version of pip on Clever Cloud is 19. If you want to use pip 9 instead, create an environment variable like CC_PIP_VERSION=9.

Select the python backend

Currently, we support daphne, gunicorn, uvicorn and uwsgi for Python backends. If not specified, the default backend is uwsgi.

To select one, set the CC_PYTHON_BACKEND environment variable with either daphne, gunicorn, uvicorn or uwsgi.

Please contact the support if you need another backend.


If you do not have a requirements.txt file to commit you can obtain it via the command pip freeze > requirements.txt (or pip3 freeze > requirements.txt if you use Python 3.x) at the root of your project folder in your terminal.

For example to install PostgreSQL and don’t want to use the pip freeze command above you have to create a file requirements.txt at the root of your application folder:

psycopg2>=2.7 --no-binary psycopg2

Note: We recommend using psycopg2>=2.7 --no-binary psycopg2 to avoid wsgi issues.

You can define a custom requirements.txt file with the environnement variable CC_PIP_REQUIREMENTS_FILE for example: CC_PIP_REQUIREMENTS_FILE=config/production.txt.

Cached dependencies

Enabling dependencies caching

You can enable dependencies caching by adding the CC_CACHE_DEPENDENCIES=true environment variable in your application. It is enabled by default only for rust and haskell applications.

Disabling dependencies caching

You can disable dependencies caching completely by removing the CC_CACHE_DEPENDENCIES environment variable from the Clever Cloud console, in the Environment variables menu of your application.

Or by setting it to CC_CACHE_DEPENDENCIES=false

To fully remove cached dependencies, you have to rebuild your application from scratch.

You can select “rebuild and restart” from the Clever Cloud console or launch clever restart --without-cache with the Clever Tools CLI.


We support execution of a single goal. Usually, this would be to execute custom tasks after the installation of dependencies.

The goal will be launched after the dependencies from requirements.txt have been installed.

To execute a goal, you can define the environment variable PYTHON_SETUP_PY_GOAL="<your goal>".

Environment injection

Clever Cloud injects environment variables from your application settings as mentioned in setting up environment variables and is also injecting in your application production environment, those from your linked add-ons.

Custom build configurations

On Clever Cloud you can define some build configuration: like the app folder to deploy or the path to validate your application deployment is ready To do that follow the documentation here and add the environement variable you need.

To access environment variables from your code, just get them from the environment with:

import os

Manage your static files

To enable Nginx to serve your static resources, you have to set two environment variables.

STATIC_FILES_PATH: should point to a directory where your static files are stored.

STATIC_URL_PREFIX: the URL path under which you want to serve static files (e.g. /public).

Also, you are able to use a Filesystem Bucket to store your static files. Please refer to the File System Buckets section.

Note: the path of your folder must be absolute regarding the root of your application.

Note: setting the STATIC_URL_PREFIX to / will cause the deployment failure.

Static files example

Here is how to serve static files, the test.png being the static file you want to serve:

├── <app_root>
│   ├──
│   ├── static
│   │   └── test.png
│   └── requirements.txt

Using the environment variables STATIC_FILES_PATH=static/ and STATIC_URL_PREFIX=/public the test.png file will be accessed under: https://<domain.tld>/public/test.png.

uWSGI, Gunicorn and Nginx configuration

uWSGI, gunicorn and nginx settings can be configured by setting environment variables:


  • HARAKIRI: timeout (in seconds) after which an unresponding process is killed. (Default: 180)
  • WSGI_BUFFER_SIZE: maximal size (in bytes) for the headers of a request. (Default: 4096)
  • WSGI_POST_BUFFERING: buffer size (in bytes) for uploads. (Default: 4096)
  • WSGI_WORKERS: number of workers. (Default: depends on the scaler)
  • WSGI_THREADS: number of threads per worker. (Default: depends on the scaler)
uWSGI asynchronous/non-blocking modes

To enable uWSGI asynchronous mode, you can use these two environment variables:


  • GUNICORN_WORKER_CLASS: type of worker to use. Default to sync. Available workers
  • CC_GUNICORN_TIMEOUT: gunicorn timeout. Defaults to 30


  • NGINX_READ_TIMEOUT: a bit like HARAKIRI, the response timeout in seconds. (Default: 300)
  • ENABLE_GZIP_COMPRESSION: “on|yes|true” gzip-compress the output of uwsgi.
  • GZIP_TYPES: the mime types to gzip. Defaults to text/* application/json application/xml application/javascript image/svg+xml.
Basic authentication

If you need basic authentication, you can enable it using environment variables. You will need to set CC_HTTP_BASIC_AUTH variable to your own login:password pair. If you need to allow access to multiple users, you can create additional environment CC_HTTP_BASIC_AUTH_n (where n is a number) variables.

Nginx optional configuration with clevercloud/http.json

Nginx settings can be configured further in clevercloud/http.json. All its fields are optional.

  • languages: configure a default language and redirections
  • error_pages: configure custom files for error pages
  • force_https: automatically redirect HTTP traffic to HTTPS
  • aliases: set up redirections
  • charset: force a specific charset
    "languages": {
        "default": {"rewrite": "en"},
        "fr": {"rewrite": "en"}
    "error_pages": {
        "404": "path/to/page"
    "force_https": true,
    "aliases": {
        "/path": "redirection"
    "charset": "latin-1"

Using the Gevent loop engine

Whether you use uwsgi or gunicorn, you can enable the Gevent loop engine.

To do so, add the CC_PYTHON_USE_GEVENT environment variable to your application, with the true value.

Monitor your application with New Relic

You can use New Relic to monitor your application on Clever Cloud.

Please refer to our New Relic documentation to configure it for your application.

Celery apps

Note: Please note that Celery support is not available yet for gunicorn.

We also support celery apps out of the box. To deploy a celery app, use the CC_PYTHON_CELERY_MODULE environment variable:

Celery needs to be defined as a dependency in your requirements.txt. Otherwise the deployment will be aborted if Celery support is enabled.

You can also activate beat with CC_PYTHON_CELERY_USE_BEAT=true and provide a given log dir for celery with CC_PYTHON_CELERY_LOGFILE="/path/to/logdir".

The CC_PYTHON_CELERY_LOGFILE path is relative to the application’s path.

There is a bug in versions <4.2 of Celery. You need to add the CELERY_TIMEZONE = 'UTC' environment variable. The bug is documented here:

Git Deployment on Clever Cloud

You need Git on your computer to deploy via this tool. Here is the official website of Git to get more information:

Setting up your remotes

  1. The “Information” page of your app gives you your Git deployment URL, it looks like this:

    1. git+ssh://<your_app_id>.git
    2. Copy it in your clipboard
  2. Locally, under your code folder, type in git init to set up a new git repository or skip this step if you already have one

  3. Add the deploy URL with git remote add <name> <your-git-deployment-url>

  4. Add your files via git add <files path> and commit them via git commit -m <your commit message>

  5. Now push your application on Clever Cloud with git push <name> master

Refer to git deployments for more details.

Linking a database or any other add-on to your application

By linking an application to an add-on, the application has the add-on environment variables in its own environment by default.

On add-on creation

Many add-ons do exist on Clever Cloud: refer to the full list and check add-ons dedicated pages for full instructions.

During add-on creation, an Applications screen appears, with a list of your applications. You can toggle the button to Link and click next. If you finish the process of add-on creation, the application is automatically linked to it.

Add-on already exists

In the Clever Cloud console, under the Service Dependencies menu of your application, you can use the Link add-ons dropdown menu to select the name of the add-on you want to link and use the add button to finish the process.

You can also link another application from the same page in the Clever Cloud console, using the Link applications dropdown menu.

More configuration

Need more configuration? To run a script at the end of your deployment? To add your private SSH key to access private dependencies?

Go check the Common configuration page.

You may want to have an advanced usage of your application, in which case we recommend you to read the Administrate documentation section.

If you can’t find something or have a specific need like using a non supported version of a particular software, please reach out to the support.

Enable health check during deployment

The healthcheck allows you to limit downtimes. Indeed, you can provide Clever Cloud with paths to check. If these paths return something other than 200, the deployment will fail.

Add one (or several) environment variable as such:




The deployment process checks all paths. All of them must reply with a 200 OK response code.

By default, when no environment variable (for ex: APP_HOME) is defined, the monitoring checks your repository root path /.


Using the path listed above, below are the expected logs:

Response from GET /my/awesome/path is 200
Response from GET /my/other/path is 500
Health check failed:
- GET /my/other/path returned 500.
If the deployment fails after this message, please update your configuration and redeploy.

In this example, the first path is OK, but the second one failed. This gives you a hint on what failed in your application.

Best practice for healthcheck endpoints

To make the most of a healthcheck endpoint, have it check your critical dependencies. For example:

  • execute SELECT 1 + 1; on your database
  • retrieve a specific Cellar file
  • ping a specific IP through a VPN
Last updated on