Creating a Single Landing Page for Camunda 8 Webapps (Similar to Camunda 7) — Possible?

Camunda 8 Topics
1

Hi team,

I’m using Camunda 8.7 with a manual installation via Kubernetes Helm charts, and I’m trying to recreate something similar to what we had in Camunda 7:
A single index page that lists all the available webapps (Operate, Tasklist, Optimize, Zeebe), from which users can navigate via links.

In Camunda 7, we had one index.html that served as a landing page for Cockpit, Tasklist, Admin, etc.
In Camunda 8, each webapp is completely separate and exposed as its own service.

Why I need this

We are running Camunda in a hub–and–spoke model in AWS, and exposing each webapp through AWS VPC Lattice.
The problem: Camunda consumes ~6 endpoints, and Lattice allows only 10 rules per listener.

Lattice rules support:
Path matching
HTTP method
Header matching (API/CLI)

Since we want to expose multiple webapps via a single Lattice listener, we ideally want:

/camunda → landing page
/camunda/operate
/camunda/tasklist
/camunda/optimize
/camunda/zeebe
…

This would drastically reduce the number of listener rules and endpoints.
What we tried
We requested a quota increase from AWS, but AWS did not recommend increasing Lattice rule limits for our use case.

Question

Is it possible to create a single landing page for Camunda 8 webapps, similar to Camunda 7, and route to each application using sub-paths or subdomains?
Has anyone:

Built a custom HTML landing page and reverse-proxyed the webapps behind a single domain/path?
Wrapped Camunda webapps behind NGINX/Traefik/API Gateway to reduce Lattice endpoints?
Combined webapps into a single UI entry point in Kubernetes?
Any architectural suggestions to reduce Lattice rule consumption would be very helpful.

Thanks!

2

Hi @siva_saravanan,

Great question! Yes, it’s absolutely possible to create a unified entry point for Camunda 8 webapps similar to what you had in Camunda 7. The solution involves using Camunda’s combined ingress pattern with a reverse proxy configuration that consolidates all webapps under a single domain with sub-paths.

Solution Overview

You can achieve exactly what you’re looking for by:

  1. Using Camunda’s Combined Ingress Pattern - Configure all webapps under a single host with sub-paths
  2. Adding a Custom Landing Page - Serve a static HTML page at the root path with navigation links
  3. Reverse Proxy Configuration - Route traffic appropriately while maintaining proper headers

Target URL Structure

With the combined ingress setup, you’ll get:

Management Apps:

  • https://camunda.example.com/ → Your custom landing page
  • https://camunda.example.com/identity
  • https://camunda.example.com/modeler
  • https://camunda.example.com/console
  • https://camunda.example.com/connectors

Orchestration Apps & Unified REST API:

  • https://camunda.example.com/orchestration/operate
  • https://camunda.example.com/orchestration/tasklist
  • https://camunda.example.com/orchestration/optimize
  • https://camunda.example.com/orchestration/v2 (unified REST API)

Authentication:

  • https://camunda.example.com/auth (Keycloak)

Zeebe gRPC (requires separate host):

  • grpc://zeebe.camunda.example.com

Helm Configuration

Here’s the key configuration for your Helm values (adapt for Camunda 8.7):

global:
  ingress:
    enabled: true
    className: nginx        # or traefik
    host: "camunda.example.com"
  identity:
    auth:
      publicIssuerUrl: "https://camunda.example.com/auth/realms/camunda-platform"
      optimize:
        redirectUrl: "https://camunda.example.com/optimize"
      webModeler:
        redirectUrl: "https://camunda.example.com/modeler"
      console:
        redirectUrl: "https://camunda.example.com/console"

identity:
  contextPath: "/identity"
  fullURL: "https://camunda.example.com/identity"

optimize:
  contextPath: "/optimize"

orchestration:
  contextPath: "/orchestration"
  ingress:
    grpc:
      enabled: true
      className: nginx      # or traefik
      host: "zeebe.camunda.example.com"

webModeler:
  contextPath: "/modeler"

console:
  contextPath: "/console"

connectors:
  contextPath: "/connectors"

Custom Landing Page

Create a simple HTML landing page and serve it at the root path (/) through your reverse proxy:

<!DOCTYPE html>
<html>
<head>
    <title>Camunda Platform</title>
</head>
<body>
    <h1>Camunda Platform</h1>
    <ul>
        <li><a href="/orchestration/operate">Operate</a></li>
        <li><a href="/orchestration/tasklist">Tasklist</a></li>
        <li><a href="/optimize">Optimize</a></li>
        <li><a href="/modeler">Web Modeler</a></li>
        <li><a href="/console">Console</a></li>
        <li><a href="/identity">Identity</a></li>
    </ul>
</body>
</html>

Reverse Proxy Configuration

Your NGINX/Traefik configuration should:

  1. Route the root path (/) to serve your static landing page
  2. Forward all Camunda paths to the respective services
  3. Set proper headers (X-Forwarded-Proto, Host) for OIDC redirects to work correctly

AWS VPC Lattice Benefits

This approach will significantly reduce your Lattice rule consumption:

  • Before: ~6 separate endpoints (one per webapp)
  • After: 2 endpoints total:
    • https://camunda.example.com/* (all web traffic)
    • grpc://zeebe.camunda.example.com (Zeebe gRPC)

Important Notes

  1. Zeebe gRPC must remain on a separate host due to HTTP/2/gRPC requirements
  2. Header forwarding is crucial - ensure X-Forwarded-Proto and Host headers are correctly set for Identity/OIDC redirects
  3. Version considerations - If you upgrade to Camunda 8.8+, the orchestration cluster changes some paths slightly

Community Examples

Several community members have successfully implemented similar setups using:

  • NGINX reverse proxy configurations
  • Traefik with path-based routing
  • Custom API Gateway implementations

Would you like me to help you with the specific NGINX/Traefik configuration for your setup, or do you need assistance with any particular aspect of this implementation?

References: