Phoenix Static Buildpack
Purpose
This buildpack is meant to be used with the Heroku Buildpack for Elixir. When deploying Phoenix apps to Heroku, static assets will need to be compiled. This buildpack sees to it that static assets are compiled and that a corresponding asset manifest is generated.
Features
- Easily customizable to your build needs with its
compile
hook! - Works much like the Heroku Buildpack for Elixir!
- Easy configuration with
phoenix_static_buildpack.config
file - Automatically sets
DATABASE_URL
- If your app doesn't have a Procfile, default web task
mix phoenix.server
will be run - Can configure versions for Node and NPM
- Auto-installs Bower deps if
bower.json
is in your app's root path - Caches Node, NPM modules and Bower components
Usage
# Create a Heroku instance for your project
heroku apps:create my_heroku_app
# Set and add the buildpacks for your Heroku app
heroku buildpacks:set https://github.com/HashNuke/heroku-buildpack-elixir
heroku buildpacks:add https://github.com/gjaldon/heroku-buildpack-phoenix-static
# Deploy
git push heroku master
Serve with Sass assets
If your project serves Sass assets, you need the sass binary for sass-brunch
via ruby buildpack.
Create a Gemfile
to include the sass
gem:
source 'https://rubygems.org'
ruby '2.3.1'
gem 'sass'
Then run generate the Gemfile.lock
:
bundle install
Finally, add the ruby buildpack.
# Add the ruby buildpack to your Heroku app
heroku buildpacks:add https://github.com/heroku/heroku-buildpack-ruby
Configuration
Create a phoenix_static_buildpack.config
file in your app's root dir if you want to override the defaults. The file's syntax is bash.
If you don't specify a config option, then the default option from the buildpack's phoenix_static_buildpack.config
file will be used.
Here's a full config file with all available options:
# Clean out cache contents from previous deploys
clean_cache=false
# We can change the filename for the compile script with this option
compile="compile"
# Add the config vars you want to be exported here
config_vars_to_export=(DATABASE_URL)
# We can set the version of Node to use for the app here
node_version=5.3.0
# We can set the version of NPM to use for the app here
npm_version=2.10.1
# We can set the path to phoenix app. E.g. apps/phoenix_app when in umbrella.
phoenix_relative_path=.
# Remove node and node_modules directory to keep slug size down if it is not needed.
remove_node=false
# We can change path that npm dependencies are in relation to phoenix app. E.g. assets for phoenix 1.3 support.
assets_path=.
# We can change phoenix mix namespace tasks. E.g. phx for phoenix 1.3 support.
phoenix_ex=phoenix
Compile
By default, Phoenix uses brunch
and recommends you to use mix phoenix.digest
in production. For that, we have a default compile
shell script which gets run after building dependencies and
just before finalizing the build. The compile
file looks like this:
info "Building Phoenix static assets"
cd assets
brunch build --production
cd ..
mix phx.digest
To customize your app's compile hook, just add a compile
file to your app's root directory.
compile
is just a shell script, so you can use any valid bash
code. Keep in mind you'll have
access to your node_modules
and mix
. This means that if you're using a Node build tool other than brunch
, you can just do something like:
# app_root/compile
gulp build:dist
mix phoenix.digest
The above compile
overrides the default one. :)
FAQ
- When to use?
- This buildpack is only necessary when you need to compile static assets during deploys. You will not need this buildpack if you are using Phoenix only as a REST API.
- Do I need
heroku-buildpack-nodejs
with this?
- No, this buildpack installs Node for you. How it differs from the NodeJS buildpack
is that it adds
mix
to the PATH so you can runmix
commands likemix phoenix.digest
.