Deploying Scala Apps on Heroku
Last updated April 09, 2020
Table of Contents
This article describes how to take an existing Scala app and deploy it to Heroku.
If you are new to Heroku, you might want to start with the Getting Started with Scala on Heroku tutorial.
Before you begin, make sure you have installed Scala, sbt, and the Heroku CLI. This article assumes that you are starting with an existing Scala app that is set up to build with sbt.
This article does not apply to apps that use the Play framework. Play framework support is described in the Play framework support reference.
The way Heroku recognizes a Scala application is described in Heroku Scala Support.
Your application should already include a
project/build.properties file that defines the sbt.version it is designed to use. It will look something like this:
For more information, see Build behavior.
Verify that the sbt-native-packager plugin is set up correctly
To package your app for deployment, you can use the sbt-native-packager sbt community plugin. If you are using the Play framework version 2.3 or higher, then this plugin will be automatically configured for you.
If you are not using Play framework, you must configure the plugin manually. The
project/plugins.sbt file will specify which version of the sbt-native-packager to use. Add the following to your
addSbtPlugin("com.typesafe.sbt" % "sbt-native-packager" % "1.0.3")
build.sbt enable the plugin you want. For example the
For more detailed information, see the sbt documentation, and the sbt-native-packager documentation.
Specify a JDK
Optionally, you can specify a JDK. For more information, see Specifying a Java version.
A Procfile is a text file in the root directory of your application, that defines process types and explicitly declares what command should be executed to start your app. If you are using the
sbt-native-packager and the
java_application package archetype, you will have a start script in
Procfile will look something like this, except instead of
hello, you’d use the name of your app:
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 command in a web process type must bind to the port number specified in the
PORT environment variable. If it does not, the dyno will not start.
How to keep build artifacts out of git
Prevent build artifacts from going into revision control by creating a
.gitignore file. Here’s a typical
Build your app and run it locally
To build your app locally do this:
$ sbt compile stage $ heroku local web
Your app should now be running on http://localhost:5000/.
Deploy your application to Heroku
After you commit your changes to git, you can deploy your app to Heroku.
$ git add . $ git commit -m "Added a Procfile and packaging." $ heroku login ... $ heroku create Creating warm-frost-1289... done, stack is heroku-18 http://warm-frost-1289.herokuapp.com/ | email@example.com:warm-frost-1289.git Git remote heroku added $ git push heroku master ... -----> Scala app detected
To open the app in your browser, type
Heroku allows you to run one-off dynos - scripts and applications that only need to be executed when needed - using the
heroku run command. The console has your application code available. Use this to launch a REPL process attached to your local terminal for experimenting in your app’s environment:
$ heroku run sbt console Running sbt console attached to terminal... up, run.1 ... scala>
For more information, see Running a Remote sbt Console for a Scala or Play Application.
Major releases of sbt may not be compatible with each other. Most issues will be related to mismatched versions of sbt.