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 creates an application using free dynos with add-ons matching your selected configuration.
We support the following addons:
- Heroku Postgres when using PostgreSQL
- JawsDB when using MySQL or MariaDB
- mLab MongoDB when using MongoDB
- Graphenedb when using Neo4j
- Heroku Redis when using Redis
- MemCachier when using Memcached
- Bonsai Elasticsearch when using Elasticsearch
- Okta when using OAuth2/OIDC (optional)
To deploy your application to Heroku, run this command:
This should package your application in “production” mode, create an Heroku application with a database, upload your code, and start the application.
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
14 later you need to change it in
system.properties in your projects root folder:
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
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
To push to production, type:
heroku deploy:jar target/*.jar
Or when using gradle:
heroku deploy:jar build/libs/*jar
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:
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
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"
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.
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.
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.
`6.6.2will work with all JHipster 6.x versions.
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
Free dynos are limited and should not be used for production deployment, because
- they fall to sleep after 30 minutes idle period
- they have limited dyno hours per month. When these are consumed your dynos won’t run until the next month!
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.