Skip to content
Documentation
Deploy
Applications
Linux

Linux application runtime

Overview

Clever Cloud platform provides a multi-runtime environment, including many tools to deploy and run your applications. The Linux runtime is a versatile solution to build and deploy any kind of application. The Mise package manager helps you to install and manage any supported dependencies Clever Cloud doesn’t provide by default such as Dart, Gleam, Zig for example.

Linux is a new runtime

Help us to improve it by reporting any issue or suggestion on the Clever Cloud Community

Create your Linux application

To create a new Linux application, use the Clever Cloud Console or Clever Tools:

clever create --type linux

Configure your Linux application

Mandatory needs

Linux runtime requires a run command (through CC_RUN_COMMAND, a Mise run task, or a Makefile run: target) and a working web application listening on 0.0.0.0:8080.

Build and run commands

Build and run commands are resolved in this priority order:

  1. CC_BUILD_COMMAND and CC_RUN_COMMAND environment variables
  2. Mise build and run tasks (from mise.toml or File Tasks)
  3. Makefile build: and run: targets (searches GNUmakefile, Makefile, makefile or the file defined in CC_MAKEFILE)

Each level fills in only the commands not already defined by a higher priority source. For example, you can define CC_BUILD_COMMAND and let Mise or a Makefile provide the run command.

Clever Task and Multi-runtime approach

Linux runtime is perfect fit to run on-demand workloads on Clever Cloud: configure an application as Tasks from the Information panel in the Console or with Clever Tools:

clever create --type linux --task "your-task-command --and arguments"
clever deploy # or clever restart if there is no code change

Expand your toolbox with Mise package manager

Install tools with Mise package manager

Mise is available on all Clever Cloud runtimes to install and manage tools and dependencies. Add a mise.toml file at the root of your project and all defined tools are installed at the specified version before the build phase. To place this file in a subdirectory, set the CC_MISE_FILE_PATH environment variable to its relative path (e.g. config/mise.toml). You can also use Mise to define environment variables and tasks in a declarative way.

To disable Mise tool installation, set CC_DISABLE_MISE environment variable to true.

Mise configuration examples

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 don’t return a 2xx response code, the deployment fails.

Add one (or several) environment variable as such:

CC_HEALTH_CHECK_PATH=/my/awesome/path

Or

CC_HEALTH_CHECK_PATH_0=/my/awesome/path
CC_HEALTH_CHECK_PATH_1=/my/other/path

The deployment process checks all paths. All of them must reply with a 2xx response code, such as 200 OK or 204 No Content. Clever Cloud retries with an increasing delay before it marks the deployment as failed, so an application that needs some time to start isn’t rejected on the first attempt.

When no health check path is configured, Clever Cloud requests the root path / and accepts any response code from 200 to 499: a 404 or a 401 means your application is up and answering. For Java applications, the deploy.pingPaths of the clevercloud/*.json file also count as configured paths.

Before any HTTP request, Clever Cloud checks that a service listens on the public port, 8080, on a public interface. Depending on your configuration, it’s your application, the port Docker maps from CC_DOCKER_EXPOSED_HTTP_PORT, or the first Request Flow middleware. A service on this port bound only to localhost or 127.0.0.1 makes the deployment fail with Your application is listening on localhost instead of publicly: listen on 0.0.0.0 instead.

On runtimes supporting Request Flow, when middleware runs in front of your application, Clever Cloud also checks that each middleware port and your application port are listening. With CC_REQUEST_FLOW="block", Clever Cloud only checks the service answering on the public port, not your application.

Example

With the preceding paths, here are the logs of a failing health check:

Checking public port (8080) is listening as expected
Response from GET /my/awesome/path is 200 (within expected range 200...300)
Response from GET /my/other/path is 500, expected 200...300
Error while checking /my/awesome/path, /my/other/path

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

Request Flow: Varnish, Redirection.io, OAuth2 Proxy, custom proxy

Request Flow automatically chains reverse proxies between port 8080 (public) and your application, allocating middleware ports automatically. Some services are detected from your configuration, while others must be listed explicitly in CC_REQUEST_FLOW:

  • Otoroshi Challenge: set OTOROSHI_CHALLENGE_SECRET
  • Varnish: add a clevercloud/varnish.vcl file or set CC_VARNISH_FILE
  • Redirection.io: set CC_REDIRECTIONIO_PROJECT_KEY
  • OAuth2 Proxy: set CC_REQUEST_FLOW=oauth2-proxy and its OAUTH2_PROXY_* settings

Multiple services can run simultaneously. Setting CC_REQUEST_FLOW replaces automatic detection, so list every service you need in order (e.g. oauth2-proxy,varnish). To add a custom middleware, include custom in the chain and define CC_REQUEST_FLOW_CUSTOM with @@LISTEN_PORT@@ and @@FORWARD_PORT@@ placeholders. To block public access, set CC_REQUEST_FLOW=block.

If your application manages its own HTTP server, configure it to listen on port 9000 instead of 8080 when at least one middleware is active. Clever Cloud handles this automatically for runtimes with a managed web server.

Last updated on
HaskellMeteor.js