Deploy
Packing
Now, your project is ready to be deployed. In this section, you will learn how to package a version of your app to deploy it on a server.
The build Command
Buffalo features a command, build, that will build a full binary of your application including, but not limited to; assets, migrations, templates, etc. If you buy into the “Buffalo Way”, things just work. It’s a wonderful experience. :)
$ buffalo build
Buffalo version
--> cleaning up target dir
--> running node_modules/.bin/webpack
--> packing .../coke/actions/actions-packr.go
--> running go build -v -o bin/coke -ldflags -X main.version=b5dffda -X main.buildTime="2017-03-20T11:05:23-04:00"
--> cleaning up build
----> cleaning up buffalo_build_main.go
----> cleaning up a
----> cleaning up a/a.go
----> cleaning up a/database.go
----> cleaning up buffalo_build_main.go
----> cleaning up ...coke/actions/actions-packr.go
When the build finishes, you have a fresh baked binary in the bin folder. It will also have the compilation time and the git commit SHA burnt in, thus making the binaries “versioned”.
Customize the Build
To get the list of available options, use the help command:
$ buffalo help build
Build the application binary, including bundling of webpack assets
Usage:
buffalo build [flags]
Aliases:
build, b, bill, install
Flags:
--build-flags strings Additional comma-separated build flags to feed to go build
--clean-assets will delete public/assets before calling webpack
--dry-run runs the build 'dry'
--environment string set the environment for the binary (default "development")
-e, --extract-assets extract the assets and put them in a distinct archive
-h, --help help for build
--ldflags string set any ldflags to be passed to the go build
--mod string -mod flag for go build
-o, --output string set the name of the binary
-k, --skip-assets skip running webpack and building assets
--skip-build-deps skip building dependencies
--skip-template-validation skip validating templates
-s, --static build a static binary using --ldflags '-linkmode external -extldflags "-static"'
-t, --tags string compile with specific build tags
-v, --verbose print debugging information
Binary name / location
By default, your application will be built in the bin directory of your project, and the name of the executable will be the name you used to create the project with the new command.
You can change this default name by using the -o or -output flag:
$ buffalo build -o bin/cookies
--> cleaning up target dir
--> running node_modules/.bin/webpack
--> packing .../coke/actions/actions-packr.go
--> running go build -v -o bin/cookies -ldflags -X main.version="2017-04-02T08:32:28+02:00" -X main.buildTime="2017-04-02T08:32:28+02:00"
--> cleaning up build
----> cleaning up buffalo_build_main.go
----> cleaning up a
----> cleaning up a/a.go
----> cleaning up a/database.go
----> cleaning up buffalo_build_main.go
----> cleaning up ...coke/actions/actions-packr.go
In fact, you can change the target directory too:
$ # Put the app in my home directory, as "coke"
$ buffalo build -o ~/coke
--> cleaning up target dir
--> running node_modules/.bin/webpack
--> packing .../coke/actions/actions-packr.go
--> running go build -v -o ~/coke -ldflags -X main.version="2017-04-02T08:32:28+02:00" -X main.buildTime="2017-04-02T08:32:28+02:00"
--> cleaning up build
----> cleaning up buffalo_build_main.go
----> cleaning up a
----> cleaning up a/a.go
----> cleaning up a/database.go
----> cleaning up buffalo_build_main.go
----> cleaning up ...coke/actions/actions-packr.go
Extract Assets in a Zip File
By default, your whole app is packed into a single executable, assets included. In production setups, you may want to serve these assets with a proxy server (like Apache or NGINX), to lower the app load. You may even use a CDN to handle your assets.
Buffalo provides a way to extract compiled app assets into a single archive, using the -e or -extract-assets flag:
$ buffalo build -e
--> cleaning up target dir
--> running node_modules/.bin/webpack
--> build assets archive
--> disable self assets handling
--> running go build -v -o bin/coke -ldflags -X main.version="2017-04-02T08:45:58+02:00" -X main.buildTime="2017-04-02T08:45:58+02:00"
--> cleaning up build
----> cleaning up buffalo_build_main.go
----> cleaning up a
----> cleaning up a/a.go
----> cleaning up a/database.go
----> cleaning up buffalo_build_main.go
----> cleaning up ...coke/actions/actions-packr.go
By default, the assets archive is put in the bin directory, but if you change the executable output directory with the -o flag, the assets will be put in the same directory.
$ ls -la bin
total 36280
drwxr-xr--@ 4 markbates staff 136B Apr 3 10:10 ./
drwxr-xr-x@ 20 markbates staff 680B Apr 3 10:10 ../
-rwxr-xr-x@ 1 markbates staff 17M Apr 3 10:10 coke*
-rw-r--r--@ 1 markbates staff 691K Apr 3 10:10 coke-assets.zip
Advanced Options
Building “Static”/CGO Binaries
Building statically linked binaries that contain CGO, think SQLite3, can be tricky. By using the --static flag with buffalo build, the flags --ldflags '-linkmode external -extldflags "-static"' will be added to the go build command.
Build Tags
When building a Buffalo binary using the buffalo build command, you can pass --tags and --ldflags to the built binary; just as you normally would when using the go build tools.
$ buffalo build --tags="mytag" --ldflags="-X foo.Bar=baz"
Binary Commands
Modes
Binaries, by default, run in development mode, which means all of the sub-commands will run in that mode as well. To change the mode, you must use the GO_ENV environment variable.
$ GO_ENV=production ./coke
Available commands
Once a binary has been built, there are several sub-commands that can be run on that binary:
Default
The default command, if you just run the binary, will start the application.
migrate
The migrate sub-command will run the migrations for the application.
version
The version sub-command will output the version information for the binary, including the name, the git commit SHA used to build the binary, and the time the binary was built.
$ ./coke version
coke version 69b6a8b ("2017-04-03T10:19:46-04:00")
task
The task sub-command runs tasks.
$ ./coke task greet
Hello World!
Next Steps
- Using a Proxy - Integrate your app with a server like NGINX.
- Systemd Service - Run your app as a systemd service.
- Cloud Providers - Deploy your app on a cloud provider.