Quarkus Hosting

Why run Quarkus here?

• We use Quarkus ourselves: our management platform Barista runs on Quarkus in production. We deal with the same framework updates, extension compatibility, and deployment patterns you do.
• Fixed monthly pricing: no AWS bandwidth surprises or NAT gateway charges. One invoice, same number every month.
• Dutch datacenters: three locations, data stays in the EU. ISO 27001-aligned processes, certification in progress.
• Direct access to engineers: when your app is misbehaving at 9pm, you talk to the people who run the cluster, not a helpdesk.

Two ways to run your app

Your Quarkus app is a container, a JAR, or a native binary. We have a place for all three.

	Pods	CaffeineStacks
What you get	A namespace on our managed Kubernetes cluster	A dedicated VM with full root access
You deploy with	kubectl, Helm, or CI/CD	Docker Compose, Ansible, or CI/CD
We handle	Cluster, ingress, TLS, monitoring, scaling	OS, firewall, backups, monitoring, SSL
Starting at	€100/month	€250/month
Best for	Teams comfortable with kubectl and YAML	Teams that want a server they can SSH into

Both options run on the same infrastructure: three Dutch datacenters, private backbone, ISO 27001 certified. The difference is how you interact with it.

Quarkus in containers: what matters

Quarkus was designed for containers from the start. That gives you advantages over traditional Java frameworks, but there are still things to get right.

JVM mode vs native

Most Quarkus apps run fine in JVM mode. You get fast startup (typically 1-3 seconds), reasonable memory usage, and the full Java ecosystem. Native compilation with GraalVM cuts startup to milliseconds and memory to a fraction, but adds build complexity and limits reflection-heavy libraries. We support both. If you're unsure, start with JVM mode and go native when you need it.

Memory

A typical Quarkus app in JVM mode uses 100-200 MB of heap. That's significantly less than Spring Boot for equivalent functionality. In native mode, total RSS can drop below 50 MB. This means you can fit more services on smaller pods, or run a Cortado (4 GB) tier where a Spring Boot app might need an Espresso (8 GB).

Health checks

The quarkus-smallrye-health extension gives you /q/health/live and /q/health/ready out of the box. These map directly to Kubernetes liveness and readiness probes. Quarkus starts fast enough that you can set aggressive initial delays.

livenessProbe:
  httpGet:
    path: /q/health/live
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 10
readinessProbe:
  httpGet:
    path: /q/health/ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5

Dev Services

Quarkus Dev Services automatically spin up databases, Kafka brokers, and other dependencies during development. This doesn't affect production, but it means your team can develop locally without matching the production stack exactly. When you deploy to our infrastructure, the real services are already configured and waiting.

Database

Most Quarkus apps use Hibernate ORM with Panache or Reactive SQL Clients. On Pods, you can create a PostgreSQL instance in your namespace using the CloudNativePG operator. Write a manifest, apply it, and you have a managed database with automated backups and failover.

On CaffeineStacks, we set up a dedicated PostgreSQL instance on your VM or on a separate database VM (Cortado, €50/month). We handle backups, updates, and monitoring.

Either way, your application.properties just points to a JDBC URL. No code changes.

Monitoring

The quarkus-micrometer-registry-prometheus extension exposes metrics that we scrape into Prometheus automatically. You get Grafana dashboards with:

• JVM metrics: heap usage, GC frequency and pause times, thread count
• HTTP metrics: request rate, response times, error rates per endpoint
• Custom metrics: anything you expose via Micrometer shows up automatically
• Alerts: configurable thresholds to Slack, email, or webhook

No agents to install, no configuration needed. Add the extension, and monitoring works out of the box.

Deployment

Build your container image in CI, push to a registry, deploy to your namespace or VM. Quarkus has built-in container image support:

- name: Build and push
  run: |
    ./mvnw package -Dquarkus.container-image.build=true \
      -Dquarkus.container-image.push=true \
      -Dquarkus.container-image.image=registry/my-app:${{ github.sha }}

- name: Deploy
  run: |
    kubectl set image deployment/my-app \
      my-app=registry/my-app:${{ github.sha }}

We help you set up the pipeline during onboarding. If you already have one, we plug into it.

Which option fits your app?

Your situation	Our recommendation
One Quarkus app, comfortable with kubectl	Pods Cortado (€100/month) or Espresso (€150/month) if you need a database
Quarkus app with PostgreSQL, want someone to manage the server	CaffeineStacks Espresso (€250/month) + Cortado database (€50/month)
Multiple Quarkus services, microservices architecture	Managed Clusters from €1500/month with dedicated staging and production

What we don't do

We manage infrastructure, not your application code. We won't debug your CDI configuration or write your Dockerfile. But we will tell you when your app is leaking memory, when your connection pool is exhausted, or when your health endpoint is flapping. And if you need hands-on Java expertise, our consulting team can help.