Deploying to Heroku

This sub-generator allows deployment of your JHipster application to the Heroku cloud.

Heroku is helping JHipster in two ways:

  • Joe Kutner, from Heroku, is currently maintaining this sub-generator
  • Heroku gives us free credits, allowing us to test generated applications with complex, high-end setups, to guarantee everything works well for our common users

Running the sub-generator

Before running the sub-generator, you must install the Heroku CLI.

You must also create a Heroku account and log in with the CLI by running the following command:

**$ heroku login**
Enter your Heroku credentials.
Email: YOUR_EMAIL
Password (typing will be hidden): YOUR_PASSWORD
Authentication successful.
The Heroku sub-generator will always use free tiers/options. Nevertheless installing addons needs a properly verified Heroku account. Therefore to avoid any unexpected build failures, we would recommend verifying your Heroku account before starting this sub-generator.

The Heroku sub-generator creates an application using free dynos with add-ons matching your selected configuration.

We support the following addons:

To deploy your application to Heroku, run this command:

jhipster heroku

This should package your application in “production” mode, create an Heroku application with a database, upload your code, and start the application.

Note that if your application is a microservice, you will be prompted to provide a registry URL. Scroll down to learn how to do this.
Please be aware that your application must start under 90 seconds, or it will be shutdown. Depending on the platform load, starting under 90 seconds is not guaranteed!

Changing the Java version

You can select the Java version when executing the Heroku sub-generator. By default this will be Java 11. You can find all on Heroku supported Java version in the official documentation.

If you want to change the Java version e.g. from 11 to 14 later you need to change it in system.properties in your projects root folder:

java.runtime.version=14

When you redeploy your application it will use Java 14.

Deploying your application

By default the application will be deployed via git. This means you push your code and Heroku will build and deploy it on their servers. If you can’t or don’t want to push code to someone else’s server you can use the jar option and deploy an executable jar. Heroku also supports deploying a docker image, but the sub-generator does not support this option yet.

Updating your deployed application

Using git option

When deploying via git a new remote has been created called heroku. To deploy new code you need to push the changes to the heroku remote:

git push heroku master

This assumes you have run the generator on the machine you are executing this command from. If you have not, you will need to follow the instructions for creating a Heroku remote.

Using jar option

When you selected to deploy an executable jar you need to create the updated jar and deploy the new file to Heroku.

Preparing a new jar

When your application is already deployed, you can prepare a new deployment with:

./mvnw package -Pprod -DskipTests

Or when using gradle:

./gradlew -Pprod bootJar -x test

Pushing to production
This assumes you have run the generator on the machine you are executing this command from. If you have not, you will need to follow the instructions for installing the Heroku Java CLI.

To push to production, type:

heroku deploy:jar target/*.jar

Or when using gradle:

heroku deploy:jar build/libs/*jar

Deploying Docker to Heroku

You can deploy your app as a Docker container to Heroku too. While this works, there’s no Heroku setup and configuration that happens, so you have to do that manually. This documentation assumes you’ve already run jhipster heroku to deploy your app and therefore leverages the integration and add-on provisioning that this process performs.

NOTE: If you’re using a version of JHipster that’s prior to v6.10.2, you’ll need to add the following to src/main/resources/config/application-heroku.yml:

server:
  port: ${PORT:8080}

Build your Docker image:

./mvnw package -Pprod verify jib:dockerBuild

If you’re using Gradle:

./gradlew -Pprod bootJar jibDockerBuild

You can test it out locally using Docker Compose.

docker-compose -f src/main/docker/app.yml up

Once you’ve confirmed everything works, create a new app on Heroku, and add it as a remote.

heroku apps:create
git remote add docker https://git.heroku.com/<your-new-app>.git

Then run the commands below to deploy your JHipster app as a Docker image. Be sure to replace the <...> placeholders with your Heroku app name. If you don’t know your app name, run heroku apps.

heroku container:login
docker tag space registry.heroku.com/<heroku-app>/web
docker push registry.heroku.com/<heroku-app>/web

For example:

heroku container:login
docker tag space registry.heroku.com/fast-peak-70014/web
docker push registry.heroku.com/fast-peak-70014/web

At this point, you can use the PostgreSQL and Okta add-ons you’ve already configured. Run the following command to get the identifiers of the add-ons from the heroku remote that you first deployed to.

heroku addons --remote heroku

Then you can attach these instances to your new application.

heroku addons:attach <postgresql-addon-name> --remote docker
heroku addons:attach <okta-addon-name> --remote docker

When you use jhipster heroku to deploy your application, it properly configures the database for you. However, when deploying it as a Docker container, none of that happens. Therefore, you need to set a few configuration variables so your Docker container can talk to PostgreSQL. First, run the following command to get the PostgreSQL URL.

heroku config:get DATABASE_URL --remote docker

This command will retrieve a value with the following syntax:

postgres://username:[email protected]

Then, set the database environment variables to match the keys that are in application-heroku.yml:

heroku config:set JDBC_DATABASE_URL=jdbc:postgresql://<address> --remote docker
heroku config:set JDBC_DATABASE_USERNAME=<username> --remote docker
heroku config:set JDBC_DATABASE_PASSWORD=<password> --remote docker

Set the max amount of Java memory to use and specify the Spring profiles.

heroku config:set JAVA_OPTS=-Xmx256m
heroku config:set SPRING_PROFILES_ACTIVE=prod,heroku

Run the command below to open your browser and navigate to your app.

heroku open --remote docker

Copy the URL of your app and log in to your Okta developer account. Go to Applications > Web > General and add the URL to Login and Logout redirect URIs. Make sure the login redirect URI ends with /login/oauth2/code/oidc.

Now you should be able to release your container and start the app.

heroku container:release web --remote docker

You can watch the logs to see if your container started successfully.

heroku logs --tail --remote docker

Now you should be able to open your app, click the sign in link, and authenticate!

heroku open --remote docker

NOTE: You will NOT be able to login to your JHipster app using the admin account the Okta add-on provisions. To make sure you’re not logged in with that account, we suggest you use a new private window to log in.

If you test your Dockerized JHipster app on securityheaders.com, you’ll see it scores an A!

Deploying Microservices

JHipster microservices require a JHipster Registry as described in the Doing microservices with JHipster documentation. You can deploy a registry to Heroku by clicking this button:

Deploy to Heroku

Once the registry is deployed, you can run the jhipster heroku command against your microservice or gateway. The Heroku sub-generator will prompt you for the URL of your registry, which will be in the form https://[appname].herokuapp.com.

A registry running on Heroku has a few limitations, including:

  • The registry will only work with native configuration (and not Git config).
  • The registry service cannot be scaled up to multiple dynos to provide redundancy. You must deploy multiple applications (i.e. click the button more than once). This is because Eureka requires distinct URLs to synchronize in-memory state between instances.

Using security with your JHipster Registry on Heroku

To get the automatically-generated admin password on the JHipster Registry, type:

heroku config:get JHIPSTER_PASSWORD

To use this password, update all of your microservices and your gateway to use the credentials for the registry by running this command:

heroku config:set JHIPSTER_REGISTRY_URL="https://admin:[password]@[appname].herokuapp.com"

Troubleshooting

If your application is stopped by Heroku when your Liquibase changelog is being applied, your database will be marked as “locked” by Liquibase. You will need to manually clean the lock table. On Postgres, you make sure you have a local Postgres client installed and run the following command:

heroku pg:psql -c "update databasechangeloglock set locked=false;"

Heroku has a default boot-timeout limit of 90 seconds. If your app takes longer than this, Heroku will stop the process, which may leave the database in a locked state. If the problem is persistent, try contacting Heroku Support to request a longer boot limit for your app.

Using Neo4j

As Graphene DB does not support Neo4j 4.x you can’t yet deploy reactive applications with Neo4j to Heroku! Beware that the free tier of Graphene DB is quite slow, therefore your application will not feel very snappy.

Using Elasticsearch

The Bonsai used addon with the free sandbox plan does only support the latest Elasticsearch version. This might lead to some incompatibilities depending in the Spring Data and JHipster versions you are using.

If you are willing to use a paid plan you can of course select the used Elasticsearch version. Setting it to e.g. 6.5.4 or 6.6.2 will work with all JHipster 6.x versions.

Using Okta

When you select Okta the sub-generator will create a bash script which creates all groups and roles required by JHipster. When you login with the user and credentials provided during creation you will need to select a new password as the script makes sure to expire the password directly, as it is stored in .yo-rc.json.

The script to provision the Okta addon requires
  • cURL for web request to the Okta API
  • jq for parsing/manipulating JSON data
If it can't find these tools the sub-generator will warn you and you have to execute ./provision-okta-addon.sh manually.

Free dynos

Free dynos are limited and should not be used for production deployment, because

You can upgrade your dyno configuration directly from the Heroku admin ui. If you realize e.g. a database plan is too small for you can select a new plan from the admin ui.

More information