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 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.2will 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