Launch an event-streaming stack

The event-streaming stack stands up a complete event-streaming backbone in one launch. You get a managed Apache Kafka broker and the Kafka UI console already attached to it, so you can publish and subscribe to event streams from your own services and inspect everything from your browser without installing a single CLI.

What the event-streaming stack is, and who it is for

Kafka is a durable, replayable log of events. Producers append records to topics, consumers read them at their own pace, and the broker keeps the log so multiple consumers can read the same stream independently. It is the spine of event-driven systems: order events, clickstreams, change-data-capture feeds, audit trails, and the pipelines that fan those events out to downstream services.

The catch is operability. A Kafka cluster is easy to write to and hard to see into. You end up wiring CLI tools and shell scripts just to answer simple questions: which topics exist, how far behind is a consumer group, is a broker healthy. This stack hands you both halves at once: a managed broker and a console that answers those questions in a browser.

It is for teams who want a real event log without the operations:

• Backend teams adding an event bus between services without standing up and babysitting their own brokers.
• Data teams building streaming pipelines, change-data-capture, or analytics ingestion who need to inspect topics and consumer lag.
• Anyone who wants a Kafka cluster they can see into, with the data staying in their own EU-resident infrastructure rather than a third-party SaaS.

Composition

The stack composes two FoundryDB primitives, wired together at launch:

Resource	What it is	Spec
broker	A managed Apache Kafka 3.9 broker: the durable event log itself. Producers and consumers connect over SASL.	tier-2, 50 GB maxiops storage
console	A hosted Kafka UI application, attached to the broker over its private SDN listener. Browse topics and messages, inspect consumer groups, and watch broker health.	tier-2, 10 GB standard storage

The broker is the system of record for your streams. Kafka UI is a stateless viewer on top of it: it stores nothing of its own and reads the cluster live, so the broker stays a pure data source. Because it attaches over the broker's private listener, the console reaches Kafka across the internal SDN fabric rather than over the public internet.

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)

Prerequisites

• An API token. See Authentication.

Unlike the rag-chatbot stack, the event-streaming stack does not include an inference resource, so you do not need a configured inference provider to launch it.

Export your token for the commands below:

export FOUNDRYDB_TOKEN="your-api-token"

Launch it

Option A: one-click in the console

Open the Stacks catalog in the console, pick Launch an event-streaming stack, review the cost preview, and click Launch. The console runs the same preview, accept, and launch flow described below and shows the live Kafka UI endpoint once the stack reaches Running.

Option B: the API

The launch is a two-step flow: preview the cost first, then send the launch request with the cost you accepted. This guarantees you always see an up-to-date estimate before any billable resource is created.

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"}'

The response breaks the cost down per resource:

{
  "template_name": "event-streaming",
  "currency": "EUR",
  "monthly_total": 84.00,
  "line_items": [
    {
      "symbolic_name": "broker",
      "kind": "database",
      "description": "Kafka tier-2 (2 vCPU, 4 GB) + 50 GB maxiops storage",
      "monthly_cost": 56.00,
      "is_ceiling": false
    },
    {
      "symbolic_name": "console",
      "kind": "app",
      "description": "Kafka UI app tier-2 + 10 GB standard storage",
      "monthly_cost": 28.00,
      "is_ceiling": false
    }
  ],
  "warnings": []
}

monthly_total is the figure you pass to the launch request. The cost preview is computed fresh on every call, so always preview right before launching.

2. Accept and launch

Pass the monthly_total from the preview as accepted_monthly_cost:

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
  }'

The response is 201 Created with the stack in Pending status. Capture its id:

export STACK_ID="the-id-from-the-response"

If accepted_monthly_cost has drifted from the current estimate by more than EUR 0.01, the launch returns 409 Conflict and you re-preview. If it is omitted entirely, the launch returns 400 Bad Request.

3. Poll for status

The stack provisions asynchronously. Poll GET /stacks/{id} until status reaches Running:

curl https://api.foundrydb.com/stacks/$STACK_ID \
  -H "Authorization: Bearer $FOUNDRYDB_TOKEN"

Typical progression is Pending then Provisioning then Wiring then Running. The broker provisions first; the console waits for it, then attaches. Once the stack is Running, the endpoint_url field carries the live Kafka UI URL:

{
  "id": "...",
  "name": "my-event-streaming",
  "status": "Running",
  "endpoint_url": "https://my-event-streaming-console.foundrydb.com",
  "resources": [
    { "symbolic_name": "broker", "kind": "database", "status": "Running", "service_id": "..." },
    { "symbolic_name": "console", "kind": "app", "status": "Running", "service_id": "..." }
  ]
}

First run

Open the console and sign in

Open the endpoint_url in a browser. Kafka UI is gated with a login form so it is not world-open behind its public HTTPS endpoint. The username is admin; retrieve the generated password from the console app resource:

curl https://api.foundrydb.com/stacks/$STACK_ID \
  -H "Authorization: Bearer $FOUNDRYDB_TOKEN" | jq '.resources[] | select(.symbolic_name=="console")'

The app resource exposes its login password through the credential endpoint the same way any FoundryDB app service does. Sign in, and the console shows your cluster already connected, with the broker named after the broker resource.

Browse and create a topic

Once you are in, the console lists the cluster's topics, consumer groups, and brokers in the left navigation. To create a topic, open Topics, click Add a Topic, name it orders, set the partition count (start with 3), and save. The topic appears immediately, with its partitions and replication factor shown.

Produce and consume a message

From the topic's Messages tab you can produce a record directly in the browser: pick the topic, optionally set a key, paste a JSON value, and send. The record lands on a partition and shows up in the message list with its offset, timestamp, and key. This is the fastest way to confirm the cluster is live end to end before you point a real producer at it.

Your application services connect the same way the console does: over SASL. A producer points at the broker's bootstrap endpoint with SCRAM-SHA-256 credentials and starts appending records. See the Kafka database guide for the connection details, credentials, and client configuration your producers and consumers need.

Inspect consumer groups and broker health

As soon as a consumer reads from a topic, it appears under Consumer Groups. The console shows each group's members, the partitions assigned to them, the committed offset per partition, and the lag, that is, how many records the group is behind the head of the log. Lag climbing over time is the canonical signal that a consumer is falling behind, and this is where you watch it.

The Brokers view reports the live state of the cluster: each broker's id, whether it is online, its partition and leader counts, and the controller. This is the at-a-glance health check you would otherwise script together from CLI output.

How the wiring works

The stack engine does not introduce a new provisioning path. It calls the same APIs you would call yourself, in dependency order, and injects the configuration each resource needs.

For the event-streaming stack:

1. The broker resource is provisioned first: a managed Kafka 3.9 broker. The console depends on it, so it does not start until the broker is running.
2. The console resource is provisioned and attached to the broker. During the Wiring phase, the engine injects the broker's bootstrap servers and SASL credentials into Kafka UI as environment variables.
3. Kafka UI connects to the broker's private SDN SASL listener (SASL_PLAINTEXT with SCRAM-SHA-256) and reports healthy once it has joined the cluster.

The console reaches the broker across the internal SDN fabric, not the public internet. That fabric is private and peered, so the plaintext-with-SCRAM listener is the right target; the public listener (SASL over TLS) is reserved for your own external producers and consumers. The bootstrap configuration points at every running broker's private address, 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. The console already knows where the broker is and how to authenticate to it the moment the stack reaches Running.

Cost and EU residency

The event-streaming stack costs the sum of its two resources, shown in your cost preview at launch (a tier-2 Kafka broker plus a tier-2 Kafka UI app). Each child resource is an ordinary service in your account, billed through your normal plan. You can scale either one individually after launch, for example moving the broker to a larger tier or adding storage as your retention grows.

Both resources are EU-resident. The Kafka broker, the Kafka UI console, and the SDN traffic between them all stay within the platform's European footprint. Residency is not a setting you remember to flip; it is where the platform runs.

Teardown

Delete the whole stack with one call:

curl -X DELETE https://api.foundrydb.com/stacks/$STACK_ID \
  -H "Authorization: Bearer $FOUNDRYDB_TOKEN"

Returns 202 Accepted. The reconciler deletes the console first, then the broker, in reverse dependency order. Teardown is atomic and leaves no orphaned broker or app behind. It is irreversible, so export anything you want to keep first.

Next steps

• Stacks Overview: how stacks compose primitives, the catalog, and the lifecycle.
• Launch a Stack: the full preview, launch, retry, and teardown reference.
• Kafka: topics, partitions, SASL clients, scaling, and connecting producers and consumers to the broker under your stack.
• Upgrades: adopt new template versions of the stack in place.