Standard Go Project Layout


Standard Go Project Layout



This is a basic layout for Go application projects. It's not an official standard defined by the core Go dev team; however, it is a set of common historical and emerging project layout patterns in the Go ecosystem. Some of these patterns are more popular than others. It also has a number of small enhancements along with several supporting directories common to any large enough real world application.

If you are trying to learn Go or if you are building a PoC or a simple project for yourself this project layout is an overkill. Start with something really simple instead (a single main.gofile andgo.mod is more than enough). As your project grows keep in mind that it'll be important to make sure your code is well structured otherwise you'll end up with a messy code with lots of hidden dependencies and global state. When you have more people working on the project you'll need even more structure. That's when it's important to introduce a common way to manage packages/libraries. When you have an open source project or when you know other projects import the code from your project repository that's when it's important to have private (aka internal) packages and code. Clone the repository, keep what you need and delete everything else! Just because it's there it doesn't mean you have to use it all. None of these patterns are used in every single project. Even the vendor pattern is not universal.

With Go 1.14 Go Modules are finally ready for production. Use Go Modules unless you have a specific reason not to use them and if you do then you don’t need to worry about $GOPATH and where you put your project. The basic go.mod file in the repo assumes your project is hosted on GitHub, but it's not a requirement. The module path can be anything though the first module path component should have a dot in its name (the current version of Go doesn't enforce it anymore, but if you are using slightly older versions don't be surprised if your builds fail without it). See Issues 37554 and 32819 if you want to know more about it.

This project layout is intentionally generic and it doesn't try to impose a specific Go package structure.

This is a community effort. Open an issue if you see a new pattern or if you think one of the existing patterns needs to be updated.

If you need help with naming, formatting and style start by running gofmt and golint. Also make sure to read these Go code style guidelines and recommendations:

See Go Project Layout for additional background information.

More about naming and organizing packages as well as other code structure recommendations:

A Chinese Post about Package-Oriented-Design guidelines and Architecture layer

Go Directories


Main applications for this project.

The directory name for each application should match the name of the executable you want to have (e.g., /cmd/myapp).

Don't put a lot of code in the application directory. If you think the code can be imported and used in other projects, then it should live in the /pkg directory. If the code is not reusable or if you don't want others to reuse it, put that code in the /internal directory. You'll be surprised what others will do, so be explicit about your intentions!

It's common to have a small main function that imports and invokes the code from the /internal and /pkg directories and nothing else.

See the /cmd directory for examples.


Private application and library code. This is the code you don't want others importing in their applications or libraries. Note that this layout pattern is enforced by the Go compiler itself. See the Go 1.4 release notes for more details. Note that you are not limited to the top level internal directory. You can have more than one internal directory at any level of your project tree.

You can optionally add a bit of extra structure to your internal packages to separate your shared and non-shared internal code. It's not required (especially for smaller projects), but it's nice to have visual clues showing the intended package use. Your actual application code can go in the /internal/app directory (e.g., /internal/app/myapp) and the code shared by those apps in the /internal/pkg directory (e.g., /internal/pkg/myprivlib).


Library code that's ok to use by external applications (e.g., /pkg/mypubliclib). Other projects will import these libraries expecting them to work, so think twice before you put something here :-) Note that the internal directory is a better way to ensure your private packages are not importable because it's enforced by Go. The /pkg directory is still a good way to explicitly communicate that the code in that directory is safe for use by others. The I'll take pkg over internal blog post by Travis Jeffery provides a good overview of the pkg and internal directories and when it might make sense to use them.

It's also a way to group Go code in one place when your root directory contains lots of non-Go components and directories making it easier to run various Go tools (as mentioned in these talks: Best Practices for Industrial Programming from GopherCon EU 2018, GopherCon 2018: Kat Zien - How Do You Structure Your Go Apps and GoLab 2018 - Massimiliano Pippi - Project layout patterns in Go).

See the /pkg directory if you want to see which popular Go repos use this project layout pattern. This is a common layout pattern, but it's not universally accepted and some in the Go community don't recommend it.

It's ok not to use it if your app project is really small and where an extra level of nesting doesn't add much value (unless you really want to :-)). Think about it when it's getting big enough and your root directory gets pretty busy (especially if you have a lot of non-Go app components).


Application dependencies (managed manually or by your favorite dependency management tool like the new built-in Go Modules feature). The go mod vendor command will create the /vendor directory for you. Note that you might need to add the -mod=vendor flag to your go build command if you are not using Go 1.14 where it's on by default.

Don't commit your application dependencies if you are building a library.

Note that since 1.13 Go also enabled the module proxy feature (using as their module proxy server by default). Read more about it here to see if it fits all of your requirements and constraints. If it does, then you won't need the vendor directory at all.

Service Application Directories


OpenAPI/Swagger specs, JSON schema files, protocol definition files.

See the /api directory for examples.

Web Application Directories


Web application specific components: static web assets, server side templates and SPAs.

Common Application Directories


Configuration file templates or default configs.

Put your confd or consul-template template files here.


System init (systemd, upstart, sysv) and process manager/supervisor (runit, supervisord) configs.


Scripts to perform various build, install, analysis, etc operations.

These scripts keep the root level Makefile small and simple (e.g.,

See the /scripts directory for examples.


Packaging and Continuous Integration.

Put your cloud (AMI), container (Docker), OS (deb, rpm, pkg) package configurations and scripts in the /build/package directory.

Put your CI (travis, circle, drone) configurations and scripts in the /build/ci directory. Note that some of the CI tools (e.g., Travis CI) are very picky about the location of their config files. Try putting the config files in the /build/ci directory linking them to the location where the CI tools expect them (when possible).


IaaS, PaaS, system and container orchestration deployment configurations and templates (docker-compose, kubernetes/helm, mesos, terraform, bosh). Note that in some repos (especially apps deployed with kubernetes) this directory is called /deploy.


Additional external test apps and test data. Feel free to structure the /test directory anyway you want. For bigger projects it makes sense to have a data subdirectory. For example, you can have /test/data or /test/testdata if you need Go to ignore what's in that directory. Note that Go will also ignore directories or files that begin with "." or "_", so you have more flexibility in terms of how you name your test data directory.

See the /test directory for examples.

Other Directories


Design and user documents (in addition to your godoc generated documentation).

See the /docs directory for examples.


Supporting tools for this project. Note that these tools can import code from the /pkg and /internal directories.

See the /tools directory for examples.


Examples for your applications and/or public libraries.

See the /examples directory for examples.


External helper tools, forked code and other 3rd party utilities (e.g., Swagger UI).


Git hooks.


Other assets to go along with your repository (images, logos, etc).


This is the place to put your project's website data if you are not using GitHub pages.

See the /website directory for examples.

Directories You Shouldn't Have


Some Go projects do have a src folder, but it usually happens when the devs came from the Java world where it's a common pattern. If you can help yourself try not to adopt this Java pattern. You really don't want your Go code or Go projects to look like Java :-)

Don't confuse the project level /src directory with the /src directory Go uses for its workspaces as described in How to Write Go Code. The $GOPATH environment variable points to your (current) workspace (by default it points to $HOME/go on non-windows systems). This workspace includes the top level /pkg, /bin and /src directories. Your actual project ends up being a sub-directory under /src, so if you have the /src directory in your project the project path will look like this: /some/path/to/workspace/src/your_project/src/your_code.go. Note that with Go 1.11 it's possible to have your project outside of your GOPATH, but it still doesn't mean it's a good idea to use this layout pattern.


  • Go Report Card - It will scan your code with gofmt, go vet, gocyclo, golint, ineffassign, license and misspell. Replace with your project reference.

    Go Report Card

  • GoDoc - It will provide online version of your GoDoc generated documentation. Change the link to point to your project.

    Go Doc

  • - is a new destination for Go discovery & docs. You can create a badge using the badge generation tool.


  • Release - It will show the latest release number for your project. Change the github link to point to your project.



A more opinionated project template with sample/reusable configs, scripts and code is a WIP.

  • Missing simple approach to building and vendoring

    Missing simple approach to building and vendoring

    Pulling out my hair to do something as simple (or in go- complex) as using dep, gb and make to perform a simple build of a repo with this structure. Even if its opinionated it would help to show

    • a Makefile including gb (the refs are good but much too complex for a beginner)
    • a way to use dep for installing dependencies as part of the make process
    opened by andig 10
  • Using docker while every service in cmd directory is another image

    Using docker while every service in cmd directory is another image

    Hello, I'm struggling with building each /cmd/* separately, not as a single image, and I'm not able to build it when context directory doesn't have go.mod itself. Have anyone managed to use Docker with this layout?

    opened by gbaranski 6
  • Not clear where to put files containing secrets

    Not clear where to put files containing secrets

    I've a service account file generated by Google which contains (secret) keys. I can't conclude from the current setup where to put these into.

    My first idea was configs. But for me, configs can be public.

    opened by ndabAP 6
  • Golang has the concept of models/services/repo?

    Golang has the concept of models/services/repo?

    Can I use models/services/repositories folder inside /internal? I mean, I know we can use, but theres a golang way of using this? I know this is a concept from other languages such Java (which is mine, and my team background) , but where should we put structs that looks like a model?

    opened by bbwithpointers 3
  • Golang API: Code from other languages ?

    Golang API: Code from other languages ?


    I'm currently developing a RESTful API in Go and I'm using this helpful layout to organize my project. However, I'm more comfortable in placing other language client code (by example, Python) to access this API into the main project in order to keep consistency between version.

    So I got two questions :

    • Is this really a good idea or should I separate the Golang project from its client in other languages ?
    • If this is not a bad idea, in which folder should I place this code ?

    Thank you very much :smiley:

    opened by lerenn 2
  • How to use this layout for a gRPC API Microservice Project?

    How to use this layout for a gRPC API Microservice Project?

    It would be really helpful if you can give an example on how to use this layout for gRPC based microservice systems, since gRPC and Microservices are quiet common now a days.

    opened by cyantarek 2
  • No src folder although the official guide tells to?

    No src folder although the official guide tells to?


    I was wonderin what you think about the official Go documentation, which recommends creating a src folder, whereas you tell us not to.

    Here's the link:

    opened by cwansart 2
  • Guidance could be provided on where to put tests in library directories

    Guidance could be provided on where to put tests in library directories


    Coming from a java background (where we put source code in /src/main/my/package, and tests in src/test/my/package), it's not obvious to me how Gophers typically structure their tests. Looking at istio's source, I see a test sub directory "pkg/test", but I also see tests directly in the pkg/ level: For example:,

    Perhaps a contributor to this repository can provide their opinion on where tests belong in the pkg directory's README?

    opened by mancini0 1
  • Why there is no link to the Italian translations?

    Why there is no link to the Italian translations?

    Hi, I came across this repo and find it really useful. I want to help with the Italian translation but I saw that, even though an Italian translation is present, there is no link in the Is there any reason why?

    opened by jacopobr 0
  • Driver location

    Driver location

    Where would drivers written in Go belong in the project structure?

    The only place which kinda makes sense from what I read might be /third_party maybe have a /third_party/drivers?

    Also where would FUSE file systems belong?

    opened by zeitue 0
  • Duplicated simplified-chinese translated README

    Duplicated simplified-chinese translated README

    Hi, I noticed that there are two README translations for Simplified Chinese, they are and And I checked the difference between them, only a few paragraphs are in different words but in the same meaning.

    I think we can merge them into one file.

    If this is allowed, I would like to make a pull request.

    I noticed this because of the question mark after the relative link. 😆

    opened by vn7n24fzkq 1
An implementation of standard generics APIs in Go.

generics This package shows an implementation outlook of proposed generics APIs import "" Related issues: golang/go#45458 golang

Changkun Ou 26 Mar 3, 2022
Moby Project - a collaborative project for the container ecosystem to assemble container-based systems

The Moby Project Moby is an open-source project created by Docker to enable and accelerate software containerization. It provides a "Lego set" of tool

Moby 64.6k Nov 30, 2022
Placeholder for the future project (lets-go-chat)Placeholder for the future project (lets-go-chat)

Placeholder for the future project (lets-go-chat)Placeholder for the future project (lets-go-chat)

null 0 Jan 10, 2022
A Go project template

Powered by Cookiecutter, Cookiecutter Golang is a framework for jumpstarting production-ready go projects quickly.

Luis Morales 562 Nov 16, 2022
GoLang Library for Browser Capabilities Project

Browser Capabilities GoLang Project PHP has get_browser() function which tells what the user's browser is capable of. You can check original documenta

Maksim N. 43 Sep 27, 2022
:guardsman: A teeny tiny and somewhat opinionated generator for your next golang project

A Yeoman Golang Generator We are very sorry Gophers, but other names for the generator where taken, so we choose go-lang. But we have gocreate as an a

Axel Springer SE 25 Sep 27, 2022
Example programs for the Gio project.

Gio Examples Example programs for the Gio project. Issues File bugs and TODOs through the issue tracker or send an email to ~eliasnaur/[email protected]

Gio 79 Nov 17, 2022
bytecamp 2021 project

Calldiff 背景 复杂项目的日常迭代中,研发同学想了解某个改动的影响点,往往需要深入代码细节才能获得尽可能全的 checklist 。然而,由于项目的复杂性,我们获得的 checklist 又难免会有一些遗漏。 为了减轻研发同学的心智负担,辅助同学们更有效地保证服务稳定性,本项目应运而生。 本

null 3 Oct 4, 2021
This is an example of the cobra project

Devops cmd and mian.go This is an example of the cobra project Execute the following command in the current path to compile the project,you will appea

flyone 5 Sep 6, 2022
feedme project porting in Go language

newsapi-go This project has the intent to provide a valid interface for newsapi ( usage The project is still under mantainance a

Fulvio 5 Oct 28, 2021
This is a simple project for demonstrating Temporal with the Go SDK.

This is a simple project for demonstrating Temporal with the Go SDK.

null 0 Oct 11, 2021
Small proof of concept project to try with Dispatch Incident Management from Netflix.

temporal-dispatch-poc Small POC project to try out the Temporal workflow engine together with Netflix's Dispatch Incident Management System. Supported

Jørgen 1 Nov 12, 2021
Help to release a project which especially has multiple git repositories

This project aims to help to release a project which especially has multiple git repositories. Installation Install it to a Kubernetes cluster. You ca

KubeSphere SIGs 8 Jul 7, 2022
Demo project which implements accumulative loyalty system

Gophermart Demo project which implements accumulative loyalty system POST /api/user/register — user registration; POST /api/user/login — user authenti

null 1 Mar 31, 2022
A sample golang project to demonstrate the integration with rancher pipeline

pipeline-example-go This is a sample golang project to demonstrate the integration with rancher pipeline. Building go build -o ./bin/hello-server Runn

null 0 Oct 30, 2021
The phylosophy behind readyGo is "A Simple configuration should give a working project.".

The phylosophy behind readyGo is "A Simple configuration should give a working project.". readyGo is a command line interface( probably the name of re

Matta Manoghna Venkata Sai Rithvik 0 Oct 30, 2021
UCSD CSE 124 Fall 2021 Project 3 Starter Code

Surfstore This is the starter code for Module 3: Surfstore. Before you get started, make sure you understand the following 2 things about Go. (These w

UCSD CSE 124 Fall 2021 0 May 15, 2022
A simple and sussy project is an implementation of SOMMIP Lab 1 written in Golang

SOMMIP Lab 1 Isac Arthur Table of Contents About The Project Getting Started Prerequisites Installation Supported commands About The Project This very

Arthur 1 Nov 10, 2021
Project containing all scripts and descriptors to deploy Slurpanize in different ways

Slurpanize cloud infrastructure This project is built to install on any hardware or cloud infrastructure the Slurpanize platform. The installation is

null 0 Nov 24, 2021