(Quick Reference)

21 Deployment

Version: 6.2.3-SNAPSHOT

21 Deployment

Grails applications can be deployed in a number of ways, each of which has its pros and cons.

21.1 Standalone

"grails run-app"

You should be very familiar with this approach by now, since it is the most common method of running an application during the development phase. An embedded Tomcat server is launched that loads the web application from the development sources, thus allowing it to pick up any changes to application files.

You can run the application in the production environment using:

grails prod run-app

You can run the app using the bootRun Gradle task. The next command uses the Gradle Wrapper.

./gradlew bootRun

You can specify an environment supplying grails.env system property.

./gradlew -Dgrails.env=prod bootRun

Runnable WAR or JAR file

Another way to deploy in Grails 3.0 or above is to use the new support for runnable JAR or WAR files. To create runnable archives, run grails package:

grails package

Alternatively, you could use the assemble Gradle task.

./gradlew assemble

You can then run either the WAR file or the JAR using your Java installation:

java -Dgrails.env=prod -jar build/libs/mywar-0.1.war    (or .jar)

A TAR/ZIP distribution

Note: TAR/ZIP distribution assembly has been removed from Grails 3.1.

"./gradlew bootRun"

You should be very familiar with this approach by now, since it is the most common method of running an application during the development phase. An embedded Tomcat server is launched that loads the web application from the development sources, thus allowing it to pick up any changes to application files.

You can run the application in the production environment using:

./gradlew bootRun -Dgrails.env=prod

You can run the app using the bootRun Gradle task. The next command uses the Gradle Wrapper.

./gradlew bootRun

You can specify an environment supplying grails.env system property.

./gradlew -Dgrails.env=prod bootRun

Runnable WAR or JAR file

Another way to deploy in Grails 3.0 or above is to use the new support for runnable JAR or WAR files. To create runnable archives, run grails package:

grails package

Alternatively, you could use the assemble Gradle task.

./gradlew assemble

You can then run either the WAR file or the JAR using your Java installation:

java -Dgrails.env=prod -jar build/libs/mywar-0.1.war    (or .jar)

A TAR/ZIP distribution

Note: TAR/ZIP distribution assembly has been removed from Grails 3.1.

21.2 Container Deployment (e.g. Tomcat)

Grails apps can be deployed to a Servlet Container or Application Server.

WAR file

A common approach to Grails application deployment in production is to deploy to an existing Servlet container via a WAR file. Containers allow multiple applications to be deployed on the same port with different paths.

Creating a WAR file is as simple as executing the war command:

grails war

This will produce a WAR file that can be deployed to a container, in the build/libs directory.

Note that by default Grails will include an embeddable version of Tomcat inside the WAR file so that it is runnable (see the previous section), this can cause problems if you deploy to a different version of Tomcat. If you don’t intend to use the embedded container then you should either remove the Tomcat dependencies or change the scope to testImplementation prior to deploying to your production container in build.gradle:

testImplementation "org.springframework.boot:spring-boot-starter-tomcat"

Application servers

The Grails framework requires that runtime containers support Servlet 3.0 and above. By default, Grails framework applications are bundled with an embeddable Tomcat and testing is primarily done with Tomcat. Any servlet container meeting the minimum requirements should be able to run Grails framework applications, but some workarounds may be required for container-specific bugs or configurations.

21.3 Deployment Configuration Tasks

Setting up HTTPS and SSL certificates for standalone deployment

To configure an SSL certificate and to listen on an HTTPS port instead of HTTP, add properties like these to application.yml:

server:
    port: 8443                                             # The port to listen on
    ssl:
        enabled: true                                      # Activate HTTPS mode on the server port
        key-store: <the-location-of-your-keystore>         # e.g. /etc/tomcat7/keystore/tomcat.keystore
        key-store-password: <your-key-store-password>      # e.g. changeit
        key-alias: <your-key-alias>                        # e.g. tomcat
        key-password: <usually-the-same-as-your-key-store-password>

These settings control the embedded Tomcat container for a production deployment. Alternatively, the properties can be specified on the command-line. Example: -Dserver.ssl.enabled=true -Dserver.ssl.key-store=/path/to/keystore.

Configuration of both an HTTP and HTTPS connector via application properties is not supported. If you want to have both, then you’ll need to configure one of them programmatically. (More information on how to do this can be found in the how-to guide below.)

There are other relevant settings. Further reference: