Building a managed integration platform with Camel Quarkus on Kubernetes — looking for architecture guidance

[saynain]

Hi everyone,

I'm relatively new to both Quarkus and Apache Camel. I am exploring Camel Quarkus as the foundation for a productized, managed integration platform that we can offer to customers as an open-source alternative for process integration.

The idea is that we own and operate the platform (Kubernetes cluster, message broker, database, CI/CD, monitoring, etc.) and the customer develops and deploys their integration routes.

I've been going through the documentation and examples, but most resources focus on individual Camel Quarkus applications rather than building a complete platform with many integrations running together. I'd love to hear from anyone who has experience running Camel Quarkus at scale or has built something similar.

1. Platform architecture — what does a complete setup look like?

For a production-grade integration platform, we're looking at these components alongside Camel Quarkus:

• Message broker: Kafka for async messaging and event-driven integrations
• Database: PostgreSQL (via CloudNativePG operator) for integration state, transaction logs, etc.
• Observability: Grafana stack (metrics, logs, traces), Hawtio for Camel-specific route monitoring
• Container registry: Harbor for image storage and promotion across environments
• CI/CD: GitHub Actions with self-hosted runners
• Ingress/routing: Traefik ingress or gateway api for external traffic into the cluster

Is this a reasonable component stack for a Camel Quarkus platform? Are there components we're missing or things you'd do differently? How do others handle operations tooling — is there a good way to get visibility into message flows, dead letters, and reprocessing, or does that require custom tooling?

2. Single application vs. many applications — scaling integrations

This is where we're most uncertain. Since Quarkus compiles everything at build time, we see two approaches:

A) Monorepo / single application: All integration routes live in one codebase, built into one image, deployed as one application (with replicas for availability). Simple to operate, but a bad route can affect all others, and every change requires rebuilding the entire application.

B) Multi-repo / one application per integration: Each integration is its own Camel Quarkus application with its own repo, image, and Kubernetes deployment. Full runtime isolation, independent deployments, but significantly more infrastructure to manage — especially at 100+ integrations.

If going with option B:

• How do you manage shared configuration (Kafka/PostgreSQL connection info) across many pods? ConfigMaps/Secrets, or is there a Quarkus-native approach?
• How do you keep dependency versions in sync?
• How do you handle CI/CD at scale? Reusable GitHub Actions workflows in a central platform repo?
• What's a realistic memory footprint per pod for a simple Camel route (HTTP → transform → SFTP/Kafka) running on JVM?

3. Multi-environment promotion

Our customers typically need dev, test, and production environments. In our model we're thinking image promotion through Harbor (build once, promote the image across environments) rather than rebuilding per environment. Any experience with this pattern using Quarkus?

Any experience reports, recommendations, or "we tried this and it didn't work" stories would be incredibly valuable. Thanks in advance!