Go
Overview
Clever Cloud allows you to deploy any Go application. This page explains how to set up your project to run it on our service.
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
- Make sure you have clever-tools installed locally or follow our CLI getting started guide.
- In your code folder, do
clever create --type <type> <app-name> --region <zone> --org <org>where :typeis the type of technology you rely onapp-namethe name you want for your application,zonedeployment zone (parfor Paris andmtlfor Montreal)orgthe organisation 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
- Go to the Clever Cloud console, and find the app you want to fine tune under it’s organisation.
- Find the Environment variables menu and select it.
- In this menu, you will see a form with VARIABLE_NAME and variable value fields.
- Fill them with the desired values then select Add.
- Don’t forget to “Update Changes” at the end of the menu.
With the Clever Tools CLI
- Make sure you have clever-tools installed locally. Refer to our CLI getting started.
- 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 configuration
Be sure that your application:
- Listens on
0.0.0.0, not onlylocalhostor127.0.0.1 - Listens on port
8080 - Contains a valid build configuration (see below)
Complementary runtime
Go instances include additional runtime environments such as Node.js that you can use through scripts launched by deployment hooks. Some of these runtimes can be configured through environment variables. For example, to use a specific version of Node.js, set CC_NODE_VERSION (it could be node (latest), lts/*, 24 or 24.13.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
.gofiles you canbuildorrun. Themainpackage andmain()function are the default entry point - Module: one or more packages you can
install, defined in ago.modfile (go.sumfor checksums) - Workspace: one or more modules seamlessly combined, defined in a
go.workfile
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 internal/. Access to functions in .go files is defined depending on their name: if it starts with a capital letter it’s a public (exported) function, if not it’s a private (unexported) function.
For a complete project, a common files/folders organisation 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
Clever Cloud supports multiple ways to build and run a Go application. The build tool is determined by the CC_GO_BUILD_TOOL environment variable or by auto-detection. Available methods are gomod (for modules), gobuild (for packages), or makefile (for custom build steps). The goget method still exists but is deprecated.
Note
If the Go version declared in your go.mod file is newer than the one installed on the instance, the Go toolchain downloads the required version automatically.
Environment variables
| Name | Description |
|---|---|
CC_GO_BUILD_TOOL | Available values: gomod, gobuild, makefile. Determines how to build and install your application. goget still exists but is deprecated. |
CC_GO_BINARY | Required when using the makefile build tool. Path to the built binary, used to launch your application. |
CC_GO_PKG | Package path passed to go install. Overrides auto-detection from go.mod. Default is main.go when no go.mod is present. |
CC_GO_RUNDIR | Run the application from the specified path, relative to $GOPATH/src/. Deprecated. |
The default GOPATH is ${HOME}/go_home. The build command is go install <package> for all non-Makefile methods. If a vendor/ directory is present, it is included in the build cache.
The resulting binary is placed at $GOPATH/bin/<name>, where <name> is the basename of the package path without the .go extension. For example, CC_GO_PKG=cmd/server.go produces a binary named server.
gomod
Builds a Go module. Requires a go.mod file at the root of your application. The module name is read from go.mod and passed to go install. If you need to build a different package within the module, set CC_GO_PKG to override it.
gobuild
Builds a Go package using go install. Set CC_GO_PKG to define the package path (default main.go). The application is moved to $GOPATH/src/ before building.
makefile
Builds a Go project with a Makefile. Set CC_GO_BINARY with the path to the built binary, used to launch your application. The Makefile method is automatically selected when all these conditions are met: CC_GO_BINARY is set, a Makefile exists, and no go.mod file is present. If a Makefile is present without CC_GO_BINARY, a warning is logged and the Makefile is not used.
An example of a Makefile, to use with CC_GO_BINARY=bin/myApp:
BINARY=bin/myApp
build:
# 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
Warning
Using clevercloud/go.json to define Makefile and binary paths is a deprecated method and should no longer be used.
Custom run command
By default, the built binary is executed directly. Set CC_RUN_COMMAND to override this behavior and run a custom command instead of the binary. When defined, the binary is still built but CC_RUN_COMMAND is executed at start.
Troubleshooting builds
Set CC_TROUBLESHOOT=true to enable verbose build output (-x flag) and the race detector (-race flag) during compilation. This applies to gomod and gobuild methods.
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 environment variable you need.
To access environment variables from your code, use 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
The “Information” page of your app gives you your Git deployment URL, it looks like this:
git+ssh://git@push.clever-cloud.com/<your_app_id>.git- Copy it in your clipboard
Locally, under your code folder, type in
git initto set up a new git repository or skip this step if you already have oneAdd the deploy URL with
git remote add <name> <your-git-deployment-url>Add your files via
git add <files path>and commit them viagit commit -m <your commit message>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:
CC_HEALTH_CHECK_PATH=/my/awesome/pathOr
CC_HEALTH_CHECK_PATH_0=/my/awesome/path
CC_HEALTH_CHECK_PATH_1=/my/other/pathThe 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 /.
Example
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
Did this documentation help you ?