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:

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

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:

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:

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:

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

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:

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:

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:

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, replace spring-boot-starter-tomcat with spring-boot-starter-tomcat-runtime in build.gradle:

The -runtime variant was introduced in Spring Boot 4. It contributes only the integration classes Spring Boot needs to start in an external Servlet container, without bundling the embedded Tomcat distribution into the WAR.

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

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.

There are other relevant settings. Further reference:

Apply the Spring Boot AOT plugin alongside the Grails plugins:

This adds a processAot task, which bootJar then runs as part of the build. Nothing about a normal bootRun or bootJar changes until the application is started with AOT enabled:

An application started this way logs Starting AOT-processed Application rather than Starting Application.

processAot builds the bean definitions the packaged application will use, so it runs in the environment those definitions are meant for. The Grails Gradle plugin sets grails.env to production on the task; nothing needs to be configured for it.

It matters because an application declares different beans in different environments. Under development the URL mappings holder is a proxy whose type cannot be determined without creating it, and generation fails naming a bean unrelated to anything in the application:

Reload-mode beans have no meaning in a packaged artifact, so generating in production is correct as well as necessary. To generate for a different environment, set the property on the task yourself:

An AOT-processed application registers the same beans as a normal one. The difference is the annotation-processing infrastructure it no longer needs, since the work those components do has already been done:

Application beans, plugin beans and auto-configuration beans are all present as usual.

Beans contributed from a plugin’s beanRegistrar() are not generated. Spring marks them as registrar-owned and skips them, and they are registered again at runtime when Grails applies the plugin registrars. They behave correctly, but the plugin scan that produces them still runs on every start, so they do not benefit from generation.

Writing bean definitions that hold live objects will fail generation. A definition is a recipe rather than an instance, and there is no general way to generate code that reconstructs an arbitrary object, so a constructor argument or property value holding one cannot be processed:

Reference another bean by name instead, or express the collaborator as a nested bean definition, and the generator can emit both.

Abstract bean definitions — templates that exist only to be inherited through bean.parent — are excluded from generation, because Spring has no representation for them in generated code. Definitions that inherit from one are unaffected: they are generated from their merged definition, with the inherited values already folded in.

AOT processing on its own does not make an application ready for a native image. A native image additionally requires reachability metadata covering the resources and reflection an application performs at runtime.

The cache is produced by running the application, so it is off unless asked for. Say which pages matter:

That adds two tasks. extractAotCacheApplication unpacks the executable jar into build/aot-cache/application, and trainAotCache runs what it unpacked, asks for each path, stops it, and leaves the cache beside the extracted application:

The application is unpacked first because a cache is read against the layout it was trained on. An executable jar loads its dependencies through a nested-jar classloader; the extracted form loads them as ordinary jars on the classpath, and only the second is a layout a cache can be reused against.

build/aot-cache is what is deployed: the extracted application, and beside it the cache and what it was trained from.

It does not matter which directory it is started from. Moving the whole of aot-cache elsewhere is fine too — a container image that unpacks it under /opt is the usual case — as long as the cache and application/ move together and keep their timestamps, which the cache checks the archive against. Copying only the jar out of application/ does not work, and not because of the cache: the extracted layout reaches its dependencies through lib/ beside it.

A JVM given a cache it cannot use does not fail. It reports why, ignores the cache, and starts as it would have anyway — so an invalid cache costs the startup time it was meant to save, silently, and without any other symptom.

Adding -XX:AOTMode=on turns that into a failure to start, which is worth doing wherever the cache is the reason the deployment meets its startup time. A cache that has been invalidated then stops the process rather than quietly making it slower:

A cache makes the next start fast at whatever the training run did. Training a run that only refreshes the context records the framework starting, and that alone is most of what the startup time is — so most of the benefit is there before any path is named.

Asking for paths adds a little to that and a good deal more to the first request. Each path asked for during training profiles the code that answers it — URL mapping, the controller, GSP rendering, the data access behind it — so the first real request finds that work done rather than doing it itself.

So paths is worth setting for the pages that matter on a cold start: the ones a load balancer hits first, and the ones a user sees first. An application whose startup time is all that matters can leave it empty and still get most of the benefit.

A path that answers with an error still profiles the code that produced the error, which is code the application runs too, so nothing here fails the build. The run is a recording, not a test.

It follows that the application has to be able to start in the environment it is trained in, which is production by default — the environment the cache is for. A datasource that only exists in development is not there during training, and the run fails with whatever the application says when it cannot reach its database:

The build fails rather than carrying on, because a cache that was never written is indistinguishable at deployment time from one that was.

Where the defaults are not right, the rest of the run is configurable:

jvmArguments is given to the training run and has to be given to every run that reads the cache. A cache records what it saw; a run configured differently from the training run is a different application as far as the cache is concerned, and its cache will be declined.

Because those arguments have to be reproduced at deployment time, they are recorded in aot-cache.properties, which ships beside the cache. Keep credentials out of them and pass them to the training run another way.

A cache is read only by the JDK build that wrote it, against the archive it was trained on, with the arguments it was trained with. Any of those changing invalidates it, and the only symptom is that startup is no longer fast.

Training runs on the project’s Java toolchain where it declares one, so the JDK recorded here is the one the application is compiled for rather than whichever one happened to run Gradle.

So the training run writes aot-cache.properties beside the cache, recording what it was made from:

A deployment can compare those values against the JVM it is about to start and the jar it is about to run, and decide whether it has a cache that applies or one that will be quietly ignored. Because the cache is tied to an exact JDK build, a CI pipeline that produces the cache must publish it alongside the JDK it was produced with, and a base image upgrade invalidates every cache built against the previous one.

Measured on a Grails application with GORM for Hibernate, security and asset pipeline, best of three starts on the same machine and JDK:

The shape of that is the point. Spring’s AOT processing on its own moves less than might be expected, because deciding what the beans are was never most of the cost — loading and linking the classes was, and that is what the cache removes, cutting startup by more than half. Naming the paths takes a further tenth off startup and a third off the first requests.

An AOT cache and a native image solve the same problem differently and are not combined: a native image has no cache to read because it has already done all of this at build time. The cache is what an application gets when it stays on the JVM — including applications a native image cannot yet build, which is most of those using Hibernate.