Push to Production

Register another GitHub App

There is a good chance you will continue to develop your GitHub App to add features and fix issues. A good practice is to register a new GitHub App specific to production instead of reusing the one you created for development.

To do so, please follow the instructions in Register a GitHub App again.

Deploy your application

As a jar

You can build your application as a jar using the following command:

quarkus build

The application can be easily deployed to a Kubernetes or OpenShift cluster using the Kubernetes/OpenShift extensions.

Or you can simply build a container using the Container image extensions.

As a native executable

One of the great benefits of Quarkus is that you can easily build a native executable from your Java applications. Native executables offer faster boot and lower memory footprint.

GitHub Apps are good candidates for native executables (but deploying as a jar is also perfectly valid).

Your GitHub App is no exception and you can build a native executable using GraalVM with:

quarkus build --native

Building a native executable takes a while and is both CPU and memory intensive.

You can then start the native executable with:

./target/my-github-app-1.0.0-SNAPSHOT-runner

For more information about building native executables, see Building a native executable on the Quarkus website.

This particular guide also covers deploying native applications as containers.

Configure your GitHub App for production

There are some specific requirements for production:

  • The webhook URL points to the root of your deployed GitHub App.

  • Your GitHub App must be publicly available.

  • You have to define a webhook secret.

Do not use the Smee.io service for your production GitHub App.

Use it only for testing purposes.

Keep your secrets secret

Be careful to not expose your private key or your webhook secret in any sort as your GitHub App is publicly available.