Skip to main content

Launch an event-streaming stack: managed Kafka with a browser console

· 5 min read
FoundryDB Team
Engineering @ FoundryDB

Kafka is easy to write to and hard to see into. Standing up a broker is the start of the work, not the end: then you wire CLI tools and shell scripts together just to answer the basics. Which topics exist. How far behind is that consumer group. Is the broker even healthy. The event log you wanted was always one more afternoon of tooling away.

The Launch an event-streaming stack collapses that into one button. You get a managed Apache Kafka cluster with a browser console attached to it, EU-resident, in minutes, with nothing to wire by hand.

Event-streaming stack composition & launch
RUNNING Stack wired · Kafka UI console live
Stack Templateevent-streaminglaunch ⇉Kafka brokerSASL :9094Kafka UISASL ← brokerserve →Console UItopics · groups · health
Template · launchKafka brokerKafka UI (console)wiring (SASL listener bound)

What you launch

Pick Launch an event-streaming stack from the catalog and the platform stands up two things and connects them:

  • A managed Kafka broker. A managed Apache Kafka 3.9 broker that is the durable, replayable home for your event streams. Producers append records to topics, consumers read at their own pace, and the broker keeps the log. Your services connect over SASL.
  • Kafka UI, attached to it. Kafka UI is an open-source web console for Kafka. It reads the cluster live and gives you a browser view of every topic, message, and consumer group, plus broker health, with nothing to install.

The console already knows the broker's bootstrap address and credentials. They are injected during launch, so by the time the stack reaches Running there is nothing left to configure. You open the URL, sign in, and you are looking at your cluster.

See into your event log

The point of the console is to answer the questions a bare broker makes hard.

Topics and messages. Browse every topic, its partitions, and its replication factor. Open a topic and read its messages with their keys, offsets, and timestamps. You can even produce a record straight from the browser to confirm the cluster is live end to end before you point a real producer at it.

Consumer lag. As soon as a consumer reads from a topic, its group appears with the committed offset per partition and the lag, that is, how far behind the head of the log it is. Lag climbing over time is the canonical sign a consumer is falling behind, and this is where you watch it instead of scripting it together.

Broker health. The brokers view reports each broker's id, online state, partition and leader counts, and the controller, at a glance.

Your application services connect the same way the console does, over SASL with SCRAM-SHA-256 credentials. Point a producer at the broker's bootstrap endpoint and start appending records. The console is for the humans; your code talks to the same broker directly.

Wired over a private listener

The console does not reach the broker over the public internet. During the launch, the engine attaches it to the broker's private SDN SASL listener and injects the bootstrap servers and credentials. The console connects across the internal, peered SDN fabric, while the public listener stays reserved for your own external producers and consumers. The bootstrap configuration points at every running broker, so the console keeps working if the primary moves during a failover.

There is no broker address to copy, no SASL credential to paste into a settings panel, and no firewall rule to open by hand.

Trust, built into the launch

Like every stack, the event-streaming launch carries the platform guarantees in the flow itself.

A hard cost preview before you launch. You see exactly what the stack costs, the broker plus the console, broken down per resource, before anything is provisioned. You accept a number, then the launch runs.

Atomic rollback. A stack is two resources coming up together. If either step fails, the whole launch rolls back cleanly. You end up with the finished cluster or with nothing, never with an orphaned broker quietly costing you money.

EU data residency. The Kafka broker, the Kafka UI console, and the SDN traffic between them all stay within the platform's European footprint. Residency is where the platform runs, not a setting you remember to flip.

Launch one

# 1. Preview the cost
curl -X POST https://api.foundrydb.com/stacks/preview \
-H "Authorization: Bearer $FOUNDRYDB_TOKEN" \
-H "Content-Type: application/json" \
-d '{"template_name": "event-streaming"}'

# 2. Accept the previewed total and launch
curl -X POST https://api.foundrydb.com/stacks \
-H "Authorization: Bearer $FOUNDRYDB_TOKEN" \
-H "Content-Type: application/json" \
-d '{"name": "my-event-streaming", "template_name": "event-streaming", "accepted_monthly_cost": 84.00}'

Poll the stack until it is Running, open the endpoint_url, sign in, and you are watching your cluster. Or do the whole thing from the Stacks catalog in the console with one click.

For the full walkthrough, including console login, creating a topic, producing and consuming a message, reading consumer lag and broker health, and tearing the stack down atomically, read the Launch an event-streaming stack tutorial.

Stop scripting visibility into a bare Kafka cluster. Launch the broker and the console together, in Europe, today.