Deploying to Heroku

To complete this guide, you need:

Heroku is a platform as a service (PaaS) that enables developers to build, run, and operate applications entirely in the cloud. It supports several languages like Java, Ruby, Node.js, Scala, Clojure, Python, PHP, and Go. In addition, it offers a container registry that can be used to deploy prebuilt container images.

Heroku can be used in different ways to run a Quarkus application:

All three approaches need to be aware of the port that Heroku assigns to it to handle traffic. Luckily, there’s a dynamic configuration property for it.

This guide will take as input an application developed in the Getting Started guide.

Make sure you have the getting-started application at hand, or clone the Git repository: git clone https://github.com/quarkusio/quarkus-quickstarts.git, or download an archive. The solution is located in the getting-started directory.

Heroku can react on changes in your repository, run CI and redeploy your application when your code changes. Therefore, we start with a valid repository already.

Also, make sure your Heroku CLI is working:

Heroku picks a random port and assigns it to the container that is eventually running your Quarkus application. That port is available as an environment variable under $PORT. The easiest way to make Quarkus in all deployment scenarios aware of it is using the following configuration:

This reads as: "Listen on $PORT if this is a defined variable, otherwise listen on 8080 as usual." Run the following to add this to your application.properties:

The first variant uses the Quarkus Maven build to create the quarkus-app application structure containing the runnable "fast-jar" as well as all libraries needed inside Heroku’s build infrastructure and then deploying that result, the other one uses a local build process to create an optimized container.

For the first variant, two additional files are needed in your application’s root directory:

Quarkus needs JDK 17, so we specify that first:

We will deploy a web application so we need to configure the type web in the Heroku Procfile like this:

Your application should already be runnable via heroku local web.

Let’s create an application in your account and deploy that repository to it:

The application will have a generated name and the terminal should output that. heroku open opens your default browser to access your new application.

To access the REST endpoint via curl, run:

Of course, you can use the Heroku CLI to connect this repo to your GitHub account, too, but this is out of scope for this guide.

The advantage of pushing a whole container is that we are in complete control over its content and maybe even choose to deploy a container with a native executable running on GraalVM.

First, login to Heroku’s container registry:

We need to add an extension to our project to build container images via the Quarkus Maven plugin:

The image we are going to build needs to be named accordingly to work with Heroku’s registry and deployment. We get the generated name via heroku info and pass it on to the (local) build:

You can now push the image and release it.

You can and should check the logs to see if your application is now indeed running from the container:

The biggest advantage we take when deploying our app as a container is to deploy a container with the natively compiled application. Why? Because Heroku will stop or sleep the application when there’s no incoming traffic. A native application will wake up much faster from its sleep.

The process is pretty much the same. We opt in to compiling a native image inside a local container, so that we don’t have to deal with installing GraalVM locally:

After that, push and release again using Docker or Podman (see above) and check the logs.