<commit_before>---
title: Go Buildpack
owner: Buildpacks
---

## <a id='supported_versions'></a>Supported Versions ##

Supported Go versions can be found [in the release notes](https://github.com/cloudfoundry/go-buildpack/releases).

## <a id='pushing_apps'></a> Push an App ##

The Go buildpack will be automatically detected in the following circumstances:

- Your app has been packaged with [godep](https://github.com/tools/godep) using `godep save`.
- Your app has a `vendor/` directory and has any files ending with `.go`.
- Your app has a `GOPACKAGENAME` environment variable specified and has any files ending with `.go`.
- Your app has a `glide.yml` file and is using [glide](https://github.com/Masterminds/glide), starting in buildpack version <a href="https://github.com/cloudfoundry/go-buildpack/releases/tag/v1.7.9">1.7.9</a>.
- Your app has a `Gopkg.toml` file and is using [dep](https://github.com/golang/dep), starting in buildpack version <a href="https://github.com/cloudfoundry/go-buildpack/releases/tag/v1.8.9">1.8.9</a>.

If your Cloud Foundry deployment does not have the Go Buildpack installed, or the installed version is out of date, you can use the latest version with the command:

<pre class="terminal">
$ cf push my_app -b https://github.com/cloudfoundry/go-buildpack.git
</pre>

When specifying versions, specify only major/minor versions, such as Go 1.6, rather than Go 1.6.0. This ensures you receive the most recent patches.

### <a id='start_command'></a>Start Command ###

When pushing Go apps, you can specify a start command for the app. You can place the start command in the `Procfile` file in root directory of your app. For example, if the binary generated by your Go project is `my-go-server`, your `Procfile` could contain the following:

```
web: my-go-server
```

For more information about Procfiles, see the [Configuring a Production Server](../prod-server.html) topic.

You can also specify the start command for your app in the `manifest.yml` file in the root directory. For example, your `manifest.yml` could contain the following:

```yaml
---
applications:
  - name: my-app-name
    command: my-go-server
```

If you do not specify a start command in a `Procfile`, in the manifest, or with the `-c` flag for `cf push`, the generated binary will be used as the start command. Example: `my-go-server`

### <a id='with_godep'></a>Push an App with Go Modules ###

In Go v1.11 and later, you can use the `go mod` vendoring tool that comes with Go.
If you are using [go mod](https://github.com/golang/go/wiki/Modules) to package your dependencies, make sure that you have created a valid `go.mod` file in the root directory of your app by running `go mod init`.

The following is an example `go.mod` file:

```
module go-online

require (
	github.com/BurntSushi/toml v0.3.1
	github.com/satori/go.uuid v1.2.0
)
```

#### <a id='gomod_subdirectory_main_package'></a> When Your Main Package is Not in the Project Root ####

A common project pattern is to place main packages in a subdirectory called `cmd` like in the example below:

```bash
$ tree app-package-name
app-package-name
├── cmd
│   ├── cli
│   │   └── main.go
│   └── server
│       └── main.go
├── go.mod
├── go.sum
├── shared.go
├── shared_test.go
└── manifest.yml
```

When you configure your project like this, set the environment variable `GO_INSTALL_PACKAGE_SPEC`
to `$MODULE_NAME/$MAIN_PACKAGE_PATH`.

If the module name for the above `app-package-name` app is `example.com/user/app-package-name`,
the value of `GO_INSTALL_PACKAGE_SPEC` must be `example.com/user/app-package-name/cmd/server`.

If you want to put this in your `manifest.yml`, see the following example:

```yaml
---
applications:
- name: app-package-name
  env:
    GO_INSTALL_PACKAGE_SPEC: example.com/user/app-package-name/cmd/server
```

### <a id='with_godep'></a>Push an App with godep ###
If you are using [godep](https://github.com/tools/godep) to package your dependencies, make sure that you have created a valid `Godeps/Godeps.json` file in the root directory of your app by running `godep save`.

When using godep, you can fix your Go version in `GoVersion` key of the `Godeps/Godeps.json` file.

The following is an example `Godeps/Godeps.json` file:

```json
{
    "ImportPath": "go_app",
    "GoVersion": "go1.6",
    "Deps": []
}
```

### <a id='with_glide'></a>Push an App with Glide ###
If you use [glide](https://github.com/Masterminds/glide) to specify or package your dependencies,
make sure that you have created a valid `glide.yml` file in the root directory of your app by running `glide init`.

To vendor your dependencies before pushing, run `glide install`.
This will generate a `vendor` directory and a `glide.lock` file specifying the latest compatible versions of your dependencies.
You must have a `glide.lock` file when pushing a vendored app. You do not need a `glide.lock` file when deploying a non-vendored app.

The following is an example `glide.yml` file:

```yaml
package: go_app_with_glide
import:
- package: github.com/ZiCog/shiny-thing
  subpackages:
  - foo
```

You can specify Go version in the `manifest.yml` file:

```yaml
---
applications:
  - name: my-app-name
    env:
      GOVERSION: go1.8
```

### <a id='with_dep'></a>Push an App with dep ###

If you use [dep](https://github.com/golang/dep) to specify or package your dependencies,
make sure that you have created a valid `Gopkg.toml` file in the root directory of your app by running `dep init`.

To vendor your dependencies before pushing, run `dep ensure`.
This will generate a `vendor` directory and a `Gopkg.lock` file specifying the latest compatible versions of your dependencies.
You must have a `Gopkg.lock` file when pushing a vendored app. You do not need a `Gopkg.lock` file when deploying a non-vendored app.

The following is an example `Gopkg.toml` file:

```toml
[[constraint]]
  branch = "main"
  name = "github.com/ZiCog/shiny-thing"
```

You can specify Go version in the `manifest.yml` file:

```yaml
---
applications:
  - name: my-app-name
    env:
      GOVERSION: go1.8
```

### <a id='pushing_Apps_without_a_vendoring_tool'></a>Push an App without a vendoring tool ###
You can use Go without a vendoring tool by packaging all local dependencies in the `vendor/` directory,
and by specifying the app package name in the `GOPACKAGENAME` environment variable.

An example `manifest.yml`:

```yaml
---
applications:
  - name: my-app-name
    command: go-online
    env:
      GOPACKAGENAME: example.com/user/app-package-name
```

## <a id='passing_symbol_linker'></a>Pass a Symbol and String to the Linker ##

The Go buildpack supports the Go [linker's](https://golang.org/cmd/link/) ability, `-X symbol value`,
to set the value of a string at link time.
Set the `GO_LINKER_SYMBOL` and `GO_LINKER_VALUE` in the application's configuration  before pushing code.

This can be used to embed the commit SHA or other build-specific data directly
into the compiled executable.

## <a id='c_dependencies'></a>C Dependencies ##

The Go buildpack supports building with C dependencies using [cgo](https://golang.org/cmd/cgo/). You can set config vars to specify cgo flags
to, for example, specify paths for vendored dependencies. As an example, to build [gopgsqldriver](https://github.com/jbarham/gopgsqldriver),
add the config var `CGO_CFLAGS` with the value `-I/app/code/vendor/include/postgresql`
and include the relevant Postgres header files in `vendor/include/postgresql/` in your app.

## <a id='proxy_support'></a> Proxy Support ##

If you need to use a proxy to download dependencies during staging, you can set
the `http_proxy` and/or `https_proxy` environment variables. For more information, see [Using a Proxy](../proxy-usage.html).

## <a id='bosh_trusted_cert'></a>BOSH Configured Custom Trusted Certificate Support ##

Go uses certificates stored in `/etc/ssl/certs`. Your platform operator can configure the platform to [add the custom certificates into the application container](https://docs.cloudfoundry.org/adminguide/trusted-system-certificates.html).
## <a id='help_support'></a>Help and Support ##

Join the #buildpacks channel in our [Slack community](http://slack.cloudfoundry.org/) if you need any further assistance.

For more information about using and extending the Go buildpack in Cloud Foundry, see
the [go-buildpack GitHub repository](https://github.com/cloudfoundry/go-buildpack).
<commit_msg>[#180999868] Replace links to Go sample apps<commit_after>---
title: Go Buildpack
owner: Buildpacks
---

## <a id='supported_versions'></a>Supported Versions ##

Supported Go versions can be found [in the release notes](https://github.com/cloudfoundry/go-buildpack/releases).

## <a id='pushing_apps'></a> Push an App ##

The Go buildpack will be automatically detected in the following circumstances:

- Your app has been packaged with [godep](https://github.com/tools/godep) using `godep save`.
- Your app has a `vendor/` directory and has any files ending with `.go`.
- Your app has a `GOPACKAGENAME` environment variable specified and has any files ending with `.go`.
- Your app has a `glide.yml` file and is using [glide](https://github.com/Masterminds/glide), starting in buildpack version <a href="https://github.com/cloudfoundry/go-buildpack/releases/tag/v1.7.9">1.7.9</a>.
- Your app has a `Gopkg.toml` file and is using [dep](https://github.com/golang/dep), starting in buildpack version <a href="https://github.com/cloudfoundry/go-buildpack/releases/tag/v1.8.9">1.8.9</a>.

If your Cloud Foundry deployment does not have the Go Buildpack installed, or the installed version is out of date, you can use the latest version with the command:

<pre class="terminal">
$ cf push my_app -b https://github.com/cloudfoundry/go-buildpack.git
</pre>

When specifying versions, specify only major/minor versions, such as Go 1.6, rather than Go 1.6.0. This ensures you receive the most recent patches.

### <a id='start_command'></a>Start Command ###

When pushing Go apps, you can specify a start command for the app. You can place the start command in the `Procfile` file in root directory of your app. For example, if the binary generated by your Go project is `my-go-server`, your `Procfile` could contain the following:

```
web: my-go-server
```

For more information about Procfiles, see the [Configuring a Production Server](../prod-server.html) topic.

You can also specify the start command for your app in the `manifest.yml` file in the root directory. For example, your `manifest.yml` could contain the following:

```yaml
---
applications:
  - name: my-app-name
    command: my-go-server
```

If you do not specify a start command in a `Procfile`, in the manifest, or with the `-c` flag for `cf push`, the generated binary will be used as the start command. Example: `my-go-server`

### <a id='with_godep'></a>Push an App with Go Modules ###
As of Go 1.11 you can use the `go mod` vendoring tool that comes with Go.
If you are using [go mod](https://github.com/golang/go/wiki/Modules) to package your dependencies, make sure that you have created a valid `go.mod` file in the root directory of your app by running `go mod init`.

#### <a id='gomod_1.11'></a>Go Sample App

* [Sample Go app](https://github.com/cloudfoundry/go-buildpack/tree/master/fixtures/mod)

An example `go.mod` file:

```
module go-online

require (
	github.com/BurntSushi/toml v0.3.1
	github.com/satori/go.uuid v1.2.0
)
```

#### <a id='gomod_subdirectory_main_package'></a> When Your Main Package is Not in the Project Root ####

A common project pattern is to place main packages in a subdirectory called `cmd` like in the example below:

```bash
$ tree app-package-name
app-package-name
├── cmd
│   ├── cli
│   │   └── main.go
│   └── server
│       └── main.go
├── go.mod
├── go.sum
├── shared.go
├── shared_test.go
└── manifest.yml
```

When you configure your project like this, set the environment variable `GO_INSTALL_PACKAGE_SPEC`
to `$MODULE_NAME/$MAIN_PACKAGE_PATH`.

If the module name for the above `app-package-name` app is `example.com/user/app-package-name`,
the value of `GO_INSTALL_PACKAGE_SPEC` must be `example.com/user/app-package-name/cmd/server`.

If you want to put this in your `manifest.yml`, see the following example:

```yaml
---
applications:
- name: app-package-name
  env:
    GO_INSTALL_PACKAGE_SPEC: example.com/user/app-package-name/cmd/server
```

### <a id='with_godep'></a>Push an App with godep ###
If you are using [godep](https://github.com/tools/godep) to package your dependencies, make sure that you have created a valid `Godeps/Godeps.json` file in the root directory of your app by running `godep save`.

When using godep, you can fix your Go version in `GoVersion` key of the `Godeps/Godeps.json` file.

#### <a id='godeps_1.6'></a>Go Sample App

* [Sample Go app](https://github.com/cloudfoundry/go-buildpack/tree/master/fixtures/godep)

An example `Godeps/Godeps.json`:

```json
{
    "ImportPath": "go_app",
    "GoVersion": "go1.6",
    "Deps": []
}
```

### <a id='with_glide'></a>Push an App with Glide ###
If you use [glide](https://github.com/Masterminds/glide) to specify or package your dependencies,
make sure that you have created a valid `glide.yml` file in the root directory of your app by running `glide init`.

To vendor your dependencies before pushing, run `glide install`.
This will generate a `vendor` directory and a `glide.lock` file specifying the latest compatible versions of your dependencies.
You must have a `glide.lock` file when pushing a vendored app. You do not need a `glide.lock` file when deploying a non-vendored app.

####<a id='glide_app'></a>Glide

* [Sample Go app with Glide](https://github.com/cloudfoundry/go-buildpack/tree/master/fixtures/glide)

An example `glide.yml` file:

```yaml
package: go_app_with_glide
import:
- package: github.com/ZiCog/shiny-thing
  subpackages:
  - foo
```

You can specify Go version in the `manifest.yml` file:

```yaml
---
applications:
  - name: my-app-name
    env:
      GOVERSION: go1.8
```

### <a id='with_dep'></a>Push an App with dep ###
If you use [dep](https://github.com/golang/dep) to specify or package your dependencies,
make sure that you have created a valid `Gopkg.toml` file in the root directory of your app by running `dep init`.

To vendor your dependencies before pushing, run `dep ensure`.
This will generate a `vendor` directory and a `Gopkg.lock` file specifying the latest compatible versions of your dependencies.
You must have a `Gopkg.lock` file when pushing a vendored app. You do not need a `Gopkg.lock` file when deploying a non-vendored app.

####<a id='dep_app'></a>dep

* [Sample Go app with dep](https://github.com/cloudfoundry/go-buildpack/tree/master/fixtures/godep)

An example `Gopkg.toml` file:

```toml
[[constraint]]
  branch = "main"
  name = "github.com/ZiCog/shiny-thing"
```

You can specify Go version in the `manifest.yml` file:

```yaml
---
applications:
  - name: my-app-name
    env:
      GOVERSION: go1.8
```

### <a id='pushing_Apps_without_a_vendoring_tool'></a>Push an App without a vendoring tool ###
You can use Go without a vendoring tool by packaging all local dependencies in the `vendor/` directory,
and by specifying the app package name in the `GOPACKAGENAME` environment variable.

An example `manifest.yml`:

```yaml
---
applications:
  - name: my-app-name
    command: go-online
    env:
      GOPACKAGENAME: example.com/user/app-package-name
```

## <a id='passing_symbol_linker'></a>Pass a Symbol and String to the Linker ##

The Go buildpack supports the Go [linker's](https://golang.org/cmd/link/) ability, `-X symbol value`,
to set the value of a string at link time.
Set the `GO_LINKER_SYMBOL` and `GO_LINKER_VALUE` in the application's configuration  before pushing code.

This can be used to embed the commit SHA or other build-specific data directly
into the compiled executable.

For a sample Go app,
see the [go-buildpack](https://github.com/cloudfoundry/go-buildpack)
repository on GitHub.

## <a id='c_dependencies'></a>C Dependencies ##

The Go buildpack supports building with C dependencies using [cgo](https://golang.org/cmd/cgo/). You can set config vars to specify cgo flags
to, for example, specify paths for vendored dependencies. As an example, to build [gopgsqldriver](https://github.com/jbarham/gopgsqldriver),
add the config var `CGO_CFLAGS` with the value `-I/app/code/vendor/include/postgresql`
and include the relevant Postgres header files in `vendor/include/postgresql/` in your app.

## <a id='proxy_support'></a> Proxy Support ##

If you need to use a proxy to download dependencies during staging, you can set
the `http_proxy` and/or `https_proxy` environment variables. For more information, see [Using a Proxy](../proxy-usage.html).

## <a id='bosh_trusted_cert'></a>BOSH Configured Custom Trusted Certificate Support ##

Go uses certificates stored in `/etc/ssl/certs`. Your platform operator can configure the platform to [add the custom certificates into the application container](https://docs.cloudfoundry.org/adminguide/trusted-system-certificates.html).
## <a id='help_support'></a>Help and Support ##

Join the #buildpacks channel in our [Slack community](http://slack.cloudfoundry.org/) if you need any further assistance.

For more information about using and extending the Go buildpack in Cloud Foundry, see
the [go-buildpack GitHub repository](https://github.com/cloudfoundry/go-buildpack).

{'fraction_non_alphanumeric': 0.11849047946776783, 'fraction_numerical': 0.004473503097040606, 'mean_word_length': 4.269567845270474, 'pattern_counts': {'":': 6, '<': 79, '<?xml version=': 0, '>': 79, 'https://': 37, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4970156', 'n_tokens_mistral': 5620, 'n_tokens_neox': 5427, 'n_words': 2109}