Clever Cloud allows you to deploy any Go application. This page explains how to set up your project to run it on our service. You won’t need to change a lot, the requirements will help you configure your applications with some mandatory files to add, and properties to set up.

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 Go application

Mandatory needs

By default, we consider that your repository contains a single application. Be sure that:

  • It listens to the wild network, not only localhost or
  • It listens on port 8080
  • You follow our build/run instructions

In most cases you won’t need to change anything to your application, except host/port and some configuration variables.

Complementary runtime

If you need a runtime environment such as Node.js or tools to build a frontend for example, some are available in our Go instances. You can use them through scripts launched by deployments hooks and Environment variables sometimes allow you to configure them. So if you need a specific version of Node.js, set CC_NODE_VERSION (it could be node (latest), lts/*, 20 or 21.5.0).

Modern Go project structure

There are multiple ways to build/run a Go application, and this has evolved over the years. In its modern form a Go project can be a:

  • Package: one or more .go files you can build or run. main package and main() function are the default entry point
  • Module: one or more packages you can install, defined in a go.mod file (go.sum for checksums)
  • Workspace: one or more modules seamlessly combined, defined in a go.work file

Install any module locally or from a remote repository by passing its URL to the install command. A Makefile is sometimes used to define how to build, run and/or clean a Go project. The lightest form of a Go project is a main.go file to build. The src/ folder was often used for source code, but using the cmd/ folder instead is now a common practice.

If you want to limit from where a package can be imported, place it in a folder named ìnternal/. Access to functions in .go files is defined depending on their name: if it starts with a capital letter it’s a public function, if not it’s a private function.

For a complete project, a common files/folders organization can be:

    • go.work
    • Makefile
      • main.go
      • other-file.go
      • other-package.go
      • go.mod
      • go.sum
      • main.go
      • other-module-file.go
          • internal-package-file.go
  • Go build and deploy on Clever Cloud

    In such a situation, our strategy is to let the user choose how to build/run its application and make the deployment easy anyway. At first, we used the goget method, which is now deprecated. Thus, you can now use gobuild (for packages), gomod (for modules) or makefile. The latter will allow you to define custom build steps and a main executable to start the application.

    If the required Go version declared in the go.mod is superior to the version built in the instance, it will be automatically updated.

    Environment variables

    If you don’t want to add a file to your project, you can set one of these environment variables:

    CC_GO_BUILD_TOOLAvailable values: gomod, gobuild, makefile. Build and install your application. goget still exists but is deprecated.
    CC_GO_BINARYMandatory for a Makefile build, path to the built binary, used to launch your application.
    CC_GO_PKGTell the CC_GO_BUILD_TOOL which file contains the main() function, default main.go.
    CC_GO_RUNDIRRun the application from the specified path, relative to $GOPATH/src/, now deprecated.
    The default GO_PATH is ${HOME}/go_home. The command executed to launch the application is go install $CC_GO_PKG.
    Your project may include vendored dependencies (in the vendor/ folder).


    To build a Go package. CC_GO_PKG can be set to define the main file of your application (default main.go).


    To build a Go module, be sure that the go.mod file is in your git tree and at the root of your application. Your project’s entry point should be in the same folder as the go.mod file and be named main.go. If it isn’t, you have to set CC_GO_PKG=path/to/entrypoint.go.


    To build a Go project with a Makefile. You have to set CC_GO_BINARY with the path to the built binary, used to launch your application. If a Makefile is present with a CC_GO_BINARY set and no go.mod file at the root of your project, the makefile method will automatically be used.

    An example of a Makefile, to use with CC_GO_BINARY=bin/myApp:

    #	To install a specific Go version, you can add:
    #	go install golang.org/dl/gox.xx.x@latest
    #	${HOME}/go_home/bin/gox.xx.x download
    #	Then use `${HOME}/go_home/bin/gox.xx.x` instead of `go`
    	echo "Build the application as ./${BINARY}"
    	go build -o ${BINARY} main.go

    You’ll find a more complex project using a Go Workspace and a Makefile here.

    Using clevercloud/go.json to define Makefile and binary paths is a deprecated method and should no longer be used.

    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 PATH: os.Getenv("MY_VARIABLE").

    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: git-scm.com

    Setting up your remotes

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

      1. git+ssh://git@push.clever-cloud.com/<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

    See also

    Last updated on