Moving from Local Code to the Cloud with Quarkus

A Detailed Look and Spring Comparison

Mar 12, 2025

Building cloud-native applications involves not just writing code, but also automating how that code is built, tested, and deployed. Quarkus, a Kubernetes-native Java framework, has been gaining attention for its cloud-first approach. In this revised look, we expand our comparison between Quarkus and Spring Boot by exploring how Quarkus integrates Continuous Integration/Continuous Delivery (CI/CD) and GitHub automation into the development lifecycle. We’ll highlight Quarkus’s GitHub App and GitHub Action extensions, and contrast Quarkus’s out-of-the-box automation advantages with Spring’s traditional tooling. The goal is a balanced view: Quarkus’s strengths will be clear, while acknowledging Spring Boot’s established dominance in enterprise Java.

CI/CD and Workflow Automation with Quarkus

Modern cloud development demands robust CI/CD pipelines and workflow automation. Quarkus simplifies this by baking automation support directly into the framework. For example, Quarkus provides a GitHub App extension that makes it easy to develop GitHub Apps (bots/integrations) in Java with minimal boilerplate (GitHub - quarkiverse/quarkus-github-app: Develop your GitHub Apps in Java with Quarkus.). Think of it as “Probot for Java,” enabling you to react to repository events (pushes, issues, pull requests, etc.) using familiar Quarkus APIs instead of writing JavaScript or YAML scripts. Your GitHub App code can handle events with simple annotated methods, and Quarkus does the heavy lifting of wiring up the GitHub API clients and webhooks for you. In fact, Quarkus GitHub App is so streamlined that a handler for an issue event can be just a few lines of business logic, with Quarkus auto-injecting the context (e.g. an issue payload) and providing ready-to-use GitHub API objects.

Quarkus also offers a GitHub Action extension for implementing CI/CD tasks as code. This lets you write GitHub Actions in Java with very little overhead. Instead of crafting complex YAML files or shell scripts for your CI jobs, you can create a Quarkus project for your custom Action and use the extension’s annotations to define the job steps. Quarkus will package it as a self-contained action. The benefit is twofold: Java developers can stay in their comfort zone, and the Quarkus framework handles all the “plumbing” like parsing inputs, setting outputs, and authenticating to the GitHub API. The Quarkus GitHub Action extension automatically injects all necessary contexts (e.g. event payloads, GitHub REST clients, etc.) into your action methods, so you focus on your business logic and not the ceremony. This drastically reduces boilerplate in automation code. Quarkus even allows sharing code between GitHub Apps and Actions – you could use the same service classes or utilities in both, thanks to Quarkus’s unified extension ecosystem (Quarkus GitHub Action :: Quarkiverse Documentation).

How Does Spring Boot Handle This?

Traditionally, Spring Boot does not include built-in facilities for GitHub workflow automation – you’d rely on external tools. For instance, a Spring-based project would use GitHub Actions by writing YAML workflow files that invoke Maven or Gradle to build/test the app. If you wanted a GitHub App (bot), you might incorporate a third-party GitHub API library and write a Spring Boot service to handle webhooks, but there is no official Spring Boot “GitHub App” starter equivalent to Quarkus’s extension. The result is more manual coding and configuration in Spring’s case, whereas Quarkus provides out-of-the-box extensions to jump-start these capabilities. Spring’s strength has long been in its rich ecosystem, so you can achieve similar automation (for example, using Jenkins or GitLab CI with Spring, or adding the Fabric8 Kubernetes client to generate deployment resources), but these involve additional setup. Quarkus’s approach integrates automation right into the development model, reflecting its philosophy of being cloud-native from the ground up.

Continuous Integration Enhancements in Quarkus

Quarkus’s cloud-first design doesn’t stop at convenience – it also improves CI pipeline efficiency. One key advantage is Quarkus’s ability to compile applications to native binaries ahead-of-time. Both the Quarkus GitHub App and Action extensions support generating native executables with GraalVM or Mandrel. In practical terms, this means your automation code (whether it’s a bot or a CI job) can run as a lightning-fast native binary. When included in a GitHub Actions workflow, a Quarkus native executable starts almost instantly and uses minimal memory, which can significantly speed up CI jobs that spin up ephemeral containers or processes. Spring Boot, on the other hand, traditionally runs on the JVM with larger startup times and memory needs. (Spring has introduced Spring Native and Spring Boot 3 now supports GraalVM native images, but it’s a newer effort requiring additional configuration, whereas Quarkus has offered this capability from day one.)

Moreover, Quarkus streamlines CI by reducing the amount of custom scripting needed. For example, a Quarkus GitHub Action can directly use the GitHub REST API via the built-in Hub4j integration to perform tasks like creating issues or updating statuses. In a pure Spring setup, you might write a separate script or use curl calls in your CI workflow to hit the GitHub API. With Quarkus, those operations are one method call away, fully type-safe and integrated into your Java code. By eliminating layers of scripting and allowing reuse of application logic in your CI tasks, Quarkus makes automation both faster to write and faster to run. Teams have reported that Quarkus-based test suites and build steps execute quickly in CI environments, thanks to Quarkus’s fast startup and live coding features that speed up the “dev-test cycle” even in pipelines.

Deployment and Scaling Advantages

Automating deployment is another area where Quarkus provides tangible benefits. Cloud deployment often requires preparing Kubernetes or OpenShift manifests, Dockerfiles, and other config – tasks that can be tedious and error-prone if done manually. Quarkus minimizes this manual toil by automatically generating deployment resources as part of the build. For example, if you include the Quarkus Kubernetes extension, Quarkus will produce Kubernetes YAML manifests for your application based on sane defaults and your configuration (quarkus-super-heroes/docs/automation.md at main · quarkusio/quarkus-super-heroes · GitHub). It can similarly generate Knative, Minikube, and OpenShift descriptors out-of-the-box. This means when you build your Quarkus app for the cloud, you already have the Kubernetes deployment YAML (services, deployments, etc.) ready to go, without writing them by hand. Quarkus even allows you to customize these by simply adding files to your project (e.g. additional YAML snippets), which it will merge into the generated manifests.

By contrast, a typical Spring Boot project might rely on external tools to handle this step – for instance, using the Eclipse JKube Maven plugin or the Dekorate library to generate Kubernetes manifests, or just maintaining custom deployment.yaml files in source control. Spring doesn’t generate cloud config out-of-the-box as part of its build process. This is a subtle but important distinction: Quarkus encourages automation of cloud deployment config, whereas Spring usually leaves it to the developer or ops team to manage those files or use an additional toolkit. In practice, Quarkus’s built-in automation reduces manual intervention. If you change an environment variable or port in your Quarkus app, the generated Kubernetes manifest will reflect it on the next build, keeping deployment artifacts in sync with the code. In a Spring Boot scenario, one would need to remember to update the k8s YAML or Helm charts accordingly.

Quarkus’s automation also shines when scaling applications. Because Quarkus apps (especially as native binaries) have lower memory and faster startup, they are well-suited for containerized environments where rapid scaling up or down is required. For example, on Kubernetes or serverless platforms, a Quarkus service can cold-start much quicker than a traditional Spring Boot fat jar, which translates to more responsive auto-scaling and less resource usage per instance. This performance edge complements the automation: not only does Quarkus simplify deploying to the cloud, it ensures the deployed services run efficiently, allowing infrastructure to scale with minimal overhead. Spring Boot, running on the JVM, typically has slower cold starts and higher RAM needs, which many companies mitigate by using larger containers or keeping instances warm – options that can increase cloud costs. Quarkus offers a more cloud-optimized runtime, so your automated CI/CD pipeline yields a truly cloud-ready application without extra tuning.

Real-World Example: Quarkus Superheroes Automation

A practical case study of Quarkus’s CI/CD and automation capabilities is the Quarkus Superheroes sample application. This is a full microservices showcase built to demonstrate Quarkus features and best practices. One of its core requirements was to “have fully automated (and documented) CI/CD practices.” (Quarkus Superheroes to the Rescue!) Quarkus made this possible using GitHub Actions and Quarkus’s own extensions. The Superheroes project’s automation is extensively documented, but here’s a summary of what happens whenever code is pushed to the repository:

Continuous Integration: A GitHub Actions workflow kicks off to build and test all services. It runs both the JVM-based tests and native image tests (via GraalVM) to ensure everything passes on both builds. Thanks to Quarkus, the tests spin up quickly and can leverage features like Dev Services (automatically provisioning containers for dependent services like databases during tests) to keep the pipeline config simple.
Container Image Builds: After tests pass, the pipeline automatically builds container images for each microservice. Quarkus’s fast build and its integration with tools like Jib or Docker build plugins allow building both JVM images and native images in parallel. In Quarkus Superheroes, they produce JVM Docker images for multiple architectures (e.g., AMD64 and ARM64) and similarly build native images with Mandrel (a GraalVM distribution) for those architectures. This showcases Quarkus’s emphasis on cloud portability – the app is built once and can run anywhere, with minimal extra effort to target multiple platforms.
Automated Deployment Manifests: Perhaps most impressively, the pipeline then generates all the Kubernetes/OpenShift deployment resources for the application using Quarkus’s extensions. Each service in Quarkus Superheroes uses Quarkus’s Kubernetes and OpenShift extensions to auto-generate the manifests it needs. A custom GitHub Action (powered by Quarkus) collects these generated manifests and commits them to the repo in a dedicated branch. Because the repository has branch protection on main, the automation opens a pull request with the updated deployment files, which is then automatically approved and merged by a bot. This means the environment descriptors (K8s YAML, etc.) are always in sync with the latest code and images, without any human manually editing YAML. In fact, if someone did manually edit one of these files, their changes would be overwritten by the next automated run; the pipeline is the single source of truth for deployment config, eliminating configuration drift.
Cleanup and Additional Steps: The Superheroes CI/CD also automates cleanup of build artifacts and even the creation of multi-architecture image manifests (so that docker pull will fetch the correct arch-specific image). All these steps are orchestrated through Quarkus-powered Actions and standard GitHub Actions, demonstrating a high level of automation achievable with Quarkus.

This real-world implementation underscores how Quarkus’s native integration with CI/CD can dramatically improve efficiency. The team behind Quarkus Superheroes was able to achieve an end-to-end automated pipeline – from code commit to cloud deployment – largely because Quarkus provided the hooks and extensions to do so. Doing an equivalent setup with Spring Boot would require more piecemeal solutions: e.g., using a separate YAML or Helm chart for k8s manifests, writing custom scripts to update those manifests, or leveraging an external CD tool. With Quarkus, much of that functionality comes built-in or via official extensions, making the automation part of the development project itself. It’s a compelling example of Quarkus being a “natural fit” for cloud-first strategies, where infrastructure as code and CI/CD automation are not afterthoughts but core parts of the application.

Quarkus vs Spring Boot: Choosing a Cloud-First Framework

Spring Boot remains a powerhouse in enterprise Java – it’s battle-tested, feature-rich, and benefits from a huge ecosystem of starters and community support. For many years, Spring’s approach (relying on external CI tools, writing deployment descriptors manually or with separate libraries) was the norm, and it worked well. However, as development moves towards a DevOps culture and cloud-native architecture, Quarkus has emerged with solutions that feel like a modern upgrade. Quarkus provides out-of-the-box capabilities for automation and cloud deployment that complement the Java developer’s workflow, whereas with Spring you often stitch together multiple tools to achieve the same end.

In summary, if you have an existing Spring Boot setup, you can absolutely implement CI/CD and deploy to Kubernetes – but you’ll be piecing together GitHub Actions YAML, maybe a Jenkins pipeline, a Docker build, and some Kubernetes YAML or Helm charts, plus perhaps Spring Cloud Kubernetes for runtime config. It’s all doable, but you as the developer/architect coordinate these parts. Quarkus short-circuits a lot of that by making these concerns part of the application’s own configuration and extensions. You get a cohesive Java-centric approach: writing a GitHub bot or custom action is just another Quarkus class, generating a Kubernetes manifest is as simple as adding an extension and a few config properties. Quarkus’s lighter memory footprint and native image option further ensure that your CI jobs and cloud services run efficiently, which can translate to real savings and performance gains.

Spring’s dominance means it still might be the default choice for large enterprises (with many engineers familiar with it and many plugins available), and Spring Boot 3 is also evolving to be more cloud-friendly (including its own native image support and tools like Spring Cloud for Kubernetes). But Quarkus’s head start in developer experience for cloud-native tasks gives it an edge for teams aiming to modernize. It aligns with Kubernetes and serverless platforms from day one, and it encourages convention over configuration for things like CI/CD workflows and deployment. This makes Quarkus a natural fit for modern, cloud-first development strategies, where speed, automation, and minimal operational overhead are top priorities.