HEROKU

SHAWN MCCARTHY
Prerequisites

 To deploy the app to Heroku, you’ll need a Heroku account. If you have never
deployed a Node.js application to Heroku before, we recommend going through
the Getting Started with Node.js on Heroku tutorial before you begin.
 https://devcenter.heroku.com/articles/heroku-cli
Heroku CLI

 Homebrew
 To install the Heroku CLI with homebrew:
 $brew install heroku/brew/heroku
 If you get legacy warnings even though you installed the latest homebrew version of heroku, this is happening because the
binary heroku command in your PATH environment variable is not pointing to the version that brew installed.
 First, run which heroku to see what binary heroku is pointing to. If it is not /usr/local/bin/heroku, you need to either delete
the binary it is pointing to, or make /usr/local/bin/ higher up in your PATH environment variable by modifying
your ~/.bashrc file or equivalent.
 Next, run brew link --overwrite heroku to make sure that /usr/local/bin/heroku is pointing to the new CLI. If you continue
to have trouble, run brew doctor which should point out any issues with your system.
 Compatible with 10.7+
 MacOS Installer
 Download and run the MacOS installer.
 Compatible with 10.7+
 Windows
 Download and run the Windows installer 32-bit 64-bit.
Sign-up
Logon

 Once installed, you can use the heroku command from your command shell.
 Log in using the email address and password you used when creating your
Heroku account:
Node

 Before you continue, check that you have the prerequisites installed properly.
Type each command below and make sure it displays the version you have
installed. (Your versions might be different from the example.) If no version is
returned, go back to the introduction of this tutorial and install the prerequisites.
 All of the following local setup will be required to complete the “Declare app
dependencies” and subsequent steps.
 This tutorial will work for any version of Node greater than 4 or so - check that
it’s there
Verify Node, NPM, GIT
Prepare the app

You now have a functioning git repository that contains a simple application as well as a package.json file, which is
used by Node’s dependency manager.
Deploy the app

 Create an app on Heroku, which prepares Heroku to receive your source code.

 When you create an app, a git remote (called heroku) is also created and
associated with your local git repository.
 Heroku generates a random name (in this case still-lowlands-15193) for your app,
or you can pass a parameter to specify your own app name.
Deploy the app
Make sure 1 is running

 The application is now deployed. Ensure that at least one instance of the app is
running:
Visit the Url
View Logs

 Heroku treats logs as streams of time-ordered events aggregated from the output
streams of all your app and Heroku components, providing a single channel for all
of the events.
 View information about your running app using one of the logging commands
, heroku logs --tail
Logs
Procfile

 Use a Procfile, a text file in the root directory of your application, to explicitly
declare what command should be executed to start your app.
 The Procfile in the example app you deployed looks like this:
 web: node index.js
 This declares a single process type, web, and the command needed to run it. The
name web is important here. It declares that this process type will be attached to
the HTTP routing stack of Heroku, and receive web traffic when deployed
 Procfiles can contain additional process types. For example, you might declare
one for a background worker process that processes items off of a queue.
Scale the app

 Right now, your app is running on a single web dyno. Think of a dyno as a
lightweight container that runs the command specified in the Procfile.
 You can check how many dynos are running using the ps command:
App dependencies

 Heroku recognizes an app as Node.js by the existence of a package.json file in the

root directory. For your own apps, you can create one by running npm init --yes.
 The demo app you deployed already has a package.json, and it looks something
like this:
package.json

 The package.json file determines both the version of Node.js that will be used to
run your application on Heroku, as well as the dependencies that should be
installed with your application. When an app is deployed, Heroku reads this file
and installs the appropriate node version together with the dependencies using
the npm install command.
 Run this command in your local directory to install the dependencies, preparing
your system for running the app locally
npm install
Run the app locally

 Now start your application locally using the heroku local command, which was
installed as part of the Heroku CLI:
Config

 Heroku lets you externalise configuration - storing data such as encryption keys or
external resource addresses in config vars.
 heroku local will automatically set up the environment based on the contents of
the .env file in your local directory.
 To set the config var on Heroku, execute the following:
Github
Keep bits out of git

 Prevent build artifacts from going into revision control by creating a .gitignore file
that looks something like this:
New local git for GitHub
Add the Echo
Add Procfile
Create new app in dashboard
Connect to GitHub
Connect to GitHub
Connected
Deployed
Crash and Burn
Add env port
Push changes to git
Test
Best Practices
Only GIT the important bits

 Most apps are composed of both necessary files and generated files. When using a
source control system like git, you should avoid tracking anything that’s generated.
 For example, your node app probably has a node_modules directory for
dependencies, which you should keep out of git.
 As long as each dependency is listed in package.json, anyone can create a working
local copy of your app - including node_modules - by running npm install.
 Tracking generated files leads to unnecessary noise and bloat in your git history.
Worse, since some dependencies are native and must be compiled, checking them
in makes your app less portable because you’ll be providing builds from just a
single, and possibly incorrect, architecture.
 For the same reason, you shouldn’t check in bower_components or the compiled
assets from grunt builds.
git
Test Heroku locally
Environment Variables

 When running your app, you will typically use a set of config vars to capture the
configuration of the app. For example: say your app uses S3 for image storage.
You would want to store the credentials to S3 as config vars. If you’re running
your app locally, you typically want to use a different S3 bucket than if you were
running it in production.
 The .env file lets you capture all the config vars that you need in order to run your
app locally. When you start your app using any of the heroku local commands,
the .env file is read, and each name/value pair is inserted into the environment, to
mimic the action of config vars.
View env
Heroku env
Heroku env
Environment

 Sometimes you may want to use the same config var in both local and Heroku
environments. For each config var that you want to add to your .env file, use the
following command:
 $heroku config:get CONFIG-VAR-NAME -s>>.env
 Do not commit the .env file to source control. It should only be used for local
configuration. Update your .gitignore file to exclude the .env file.
 Keep in mind that your deployed production app may be connecting to different
services than your local development app. For example, your deployed production
app might have a DATABASE_URL config var that references a Heroku Postgres
database, but your local app might have a DATABASE_URL variable in
the .env file that references your local installation of Postgres.
.env(we’ll use dotenv for webstorm)
Environment Variables (.env)