Stay organized with collections
Save and categorize content based on your preferences.
You can use any linux/amd64-compatible package with instances running in the
App Engine flexible environment. These instructions assume you are using the go get command to
get the packages directly from supported repositories, such as GitHub,
Bitbucket, LaunchPad, and others.
Starting in Go version 1.22 and later:
You can't use go get outside of a module in the legacy GOPATH
mode (GO111MODULE=off). For more information, see Tools.
Go recommends that you use a go.mod file for managing dependencies. To install
dependencies during deployment, include a go.mod file in the same folder as
the app.yaml file. For more information about Go versions, and managing
dependencies for vendor directories, see GOPATH and Modules.
Declare and manage dependencies
Go applications are organized into packages that mirror the directory structure
of your source files. When you use an import statement, the relative paths in
the import are interpreted. Valid import paths are fully-qualified
paths that are relative to the src subdirectory of all the directories that
are specified in your GOPATH.
For example, consider an example app where you define the following:
GOPATH module:
exportGOPATH=/home/fred/go.
src1-1.go file:
import"foo/bar"
The gcloud CLI looks for the foo/bar package in the
/home/fred/go/src/foo/bar location when you run or deploy the app.
If you include your package sources in GOPATH, you must be careful not to
place your source code within your app's directory where the app.yaml
file is located. If that happens, subtle problems can occur because a package
might get loaded twice, once for the path relative to a service's directory, and
once again for the fully-qualified path. To avoid problems, the gcloud CLI
will scan both your app's directory and GOPATH, and then report an error
if a conflict is detected.
For best results, we recommend the following:
Create a separate directory in your app's directory for each service.
Each service's directory should contain the service's app.yaml file and one
or more .go files.
Don't include any subdirectories in a service's directory.
Your GOPATH should specify a directory that is outside your app's
directory and contain all the dependencies that your app imports.
Download required packages
You can use the go get command to download packages. For example, to download
packagename from the GitHub my_repo:
gogetgithub.com/my_repo/packagename
Deploy to App Engine
To deploy your application to App Engine, you must deploy
the libraries that are required by your app along with your application code.
For complete details, see
Testing and deploying your application.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-25 UTC."],[[["\u003cp\u003eApp Engine flexible environment supports any linux/amd64-compatible package, typically acquired using the \u003ccode\u003ego get\u003c/code\u003e command from repositories like GitHub and Bitbucket.\u003c/p\u003e\n"],["\u003cp\u003eGo version 1.22 and later restricts the use of \u003ccode\u003ego get\u003c/code\u003e outside of a module in the legacy \u003ccode\u003eGOPATH\u003c/code\u003e mode, with \u003ccode\u003eGO111MODULE\u003c/code\u003e set to \u003ccode\u003eoff\u003c/code\u003e.\u003c/p\u003e\n"],["\u003cp\u003eGo recommends using a \u003ccode\u003ego.mod\u003c/code\u003e file to manage dependencies, and it should be included in the same folder as the \u003ccode\u003eapp.yaml\u003c/code\u003e file for deployment dependency installation.\u003c/p\u003e\n"],["\u003cp\u003eTo avoid conflicts, source code should be kept separate from the app's directory where the \u003ccode\u003eapp.yaml\u003c/code\u003e file resides, with the \u003ccode\u003eGOPATH\u003c/code\u003e specifying an external directory for dependencies.\u003c/p\u003e\n"],["\u003cp\u003eTo deploy to app engine, all required libraries must be deployed along side the application code.\u003c/p\u003e\n"]]],[],null,["# Specify dependencies\n\nYou can use any linux/amd64-compatible package with instances running in the\nApp Engine flexible environment. These instructions assume you are using the `go get` command to\nget the packages directly from supported repositories, such as GitHub,\nBitbucket, LaunchPad, and others.\n\nStarting in Go version 1.22 and later:\n\n- You can't use `go get` outside of a module in the legacy `GOPATH`\n mode (`GO111MODULE`=`off`). For more information, see [Tools](https://tip.golang.org/doc/go1.22#:%7E:text=enables%20this%20feature.-,Tools,-Go%20command).\n\n- Go recommends that you use a `go.mod` file for managing dependencies. To install\n dependencies during deployment, include a `go.mod` file in the same folder as\n the `app.yaml` file. For more information about Go versions, and managing\n dependencies for vendor directories, see [GOPATH and Modules](https://pkg.go.dev/cmd/go#hdr-GOPATH_and_Modules).\n\nDeclare and manage dependencies\n-------------------------------\n\nGo applications are organized into packages that mirror the directory structure\nof your source files. When you use an import statement, the relative paths in\nthe import are interpreted. Valid import paths are fully-qualified\npaths that are relative to the `src` subdirectory of all the directories that\nare specified in your `GOPATH`.\n\nFor example, consider an example app where you define the following:\n\n- `GOPATH` module:\n\n export GOPATH=/home/fred/go.\n\n- `src1-1.go` file:\n\n import \"foo/bar\"\n\n- The gcloud CLI looks for the `foo/bar` package in the\n `/home/fred/go/src/foo/bar` location when you run or deploy the app.\n\nIf you include your package sources in `GOPATH`, you must be careful not to\nplace your source code within your app's directory where the `app.yaml`\nfile is located. If that happens, subtle problems can occur because a package\nmight get loaded twice, once for the path relative to a service's directory, and\nonce again for the fully-qualified path. To avoid problems, the gcloud CLI\nwill scan both your app's directory and `GOPATH`, and then report an error\nif a conflict is detected.\n\nFor best results, we recommend the following:\n\n- Create a separate directory in your app's directory for each service.\n- Each service's directory should contain the service's `app.yaml` file and one or more `.go` files.\n- Don't include any subdirectories in a service's directory.\n- Your `GOPATH` should specify a directory that is outside your app's directory and contain all the dependencies that your app imports.\n\nDownload required packages\n--------------------------\n\nYou can use the `go get` command to download packages. For example, to download\n`packagename` from the GitHub `my_repo`: \n\n go get github.com/my_repo/packagename\n\nDeploy to App Engine\n--------------------\n\nTo deploy your application to App Engine, you must deploy\nthe libraries that are required by your app along with your application code.\nFor complete details, see\n[Testing and deploying your application](/appengine/docs/flexible/testing-and-deploying-your-app#deploy)."]]
