Visit your application in the browser again, and you’ll see another log message generated. Press Control+C to stop streaming the logs.

Define a 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: java $JAVA_OPTS -cp target/classes:target/dependency/* Main

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.

The syntax of the Procfile is important - Heroku runs the exact command specified here when it starts a web dyno - and it runs it in a Unix environment.

When running locally under Windows, you may receive an error because the Unix way of passing in environment variables ($JAVA_OPTS) and of concatenating paths (:) is incompatible.

To run your apps locally under Windows:

Create a new file, Procfile.windows

Add a line to indicate how to start the app under Windows: web: java -cp target\classes;"target\dependency\*" Main

When you see instructions to run your app with foreman, append an extra -f Procfile.windows flag to ensure your Windows-specific Procfile is picked up. For example: foreman start web -f Procfile.windows

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.

By default, your app is deployed on a free dyno. Free dynos will sleep after a half hour of inactivity and they can be active (receiving traffic) for no more than 18 hours a day before going to sleep. If a free dyno is sleeping, and it hasn’t exceeded the 18 hours, any web request will wake it. This causes a delay of a few seconds for the first request upon waking. Subsequent requests will perform normally.

To avoid dyno sleeping, you can upgrade to a hobby or professional dyno type as described in the Dyno Types article. For example, if you migrate your app to a professional dyno, you can easily scale it by running a command telling Heroku to execute a specific number of dynos, each running your web process type.

For abuse prevention, scaling the application may require account verification. If your account has not been verified, you will be directed to visit the verification site.

Declare app dependencies

Heroku recognizes an app as Java by the existence of a pom.xml file in the root directory. For your own apps, you can create one by running mvn clean install.

The demo app you deployed already has a pom.xml (see it here). Here’s an excerpt:

The pom.xml file specifies dependencies that should be installed with your application. When an app is deployed, Heroku reads this file and installs the dependencies using the mvn clean install command.

Another file, system.properties, determines the version of Java to use (Heroku supports many different versions). The contents of this file, which is optional, is quite straightforward:

java.runtime.version=1.8

Run mvn clean install in your local directory to install the dependencies, preparing your system for running the app locally. Note that this app requires Java 8, but that you can push your own apps using a different version of Java:

The Maven process will copy the dependencies into your application’s target/dependency directory. This process is called “vendoring”, and it is accomplished by the following plugin configuration in the pom.xml file.

Visiting your application on the /hello route at http://localhost:5000/hello, you should see some great scientific conversions displayed:

E=mc^2: 12 GeV = (2.139194076302506E-26 ± 1.4E-42) kg

Now deploy. Almost every deploy to Heroku follows this same pattern. First, add the modified files to the local git repository:

$ git add .

Now commit the changes to the repository:

$ git commit -m "Demo"

Now deploy, just as you did previously:

$ git push heroku master

Finally, check that everything is working:

$ heroku open

Provision add-ons

Add-ons are third-party cloud services that provide out-of-the-box additional services for your application, from persistence through logging to monitoring and more.

By default, Heroku stores 1500 lines of logs from your application. However, it makes the full log stream available as a service - and several add-on providers have written logging services that provide things such as log persistence, search, and email and SMS alerts when certain conditions are met.

To help with abuse prevention, provisioning an add-on may require account verification. If your account has not been verified, you will be directed to visit the verification site.

The add-on is now deployed and configured for your application. You can list add-ons for your app like so:

$ heroku addons

To see this particular add-on in action, visit your application’s Heroku URL a few times. Each visit will generate more log messages, which should now get routed to the papertrail add-on. Visit the papertrail console to see the log messages:

$ heroku addons:open papertrail

A console will open up, showing the latest log events, and providing you with an interface to search and set up alerts:

Start a one-off dyno

You can run a command, typically scripts and applications that are part of your app, in a one-off dyno using the heroku run command. It can also be used to launch a REPL process attached to your local terminal for experimenting in your app’s environment, or bespoke code that you deployed with your application:

Define config vars

At runtime, config vars are exposed as environment variables to the application. For example, modify src/main/java/Main.java so that the method repeats grabs an energy value from the ENERGY environment variable:

Use a database

The add-on marketplace has a large number of data stores, from Redis and MongoDB providers, to Postgres and MySQL. In this step you will learn about the free Heroku Postgres add-on that is provisioned automatically on all Java app deploys.

A database is an add-on, and so you can find out a little more about the database provisioned for your app using the addons command in the CLI:

This indicates I have a hobby database (free), running Postgres 9.3.3, with a single row of data.

The example app you deployed already has database functionality, which you should be able to reach by visiting your app’s URL and appending /db. For example, if your app was deployed to https://wonderful-app-287.herokuapp.com/ then visit https://wonderful-app-287.herokuapp.com/db.

The code to access the database is straightforward. Here’s the method to insert values into a table called tick:

This ensures that when you access your app using the /db route, a new row will be added to the tick table, and all the rows will then be returned so that they can be rendered in the output.

The DatabaseUrl.extract() method, which is made available via the heroku-jdbc dependency in the pom.xml, retrieves the DATABASE_URL environment variable, set by the database add-on, and establishes a connection.

Deploy your change to Heroku. First commit the changes to git, and then git push heroku master.

Now, when you access your app’s /db route, you will see something like this: