KockpitLooking inside
★ 2 GitHub
Engineering Platform

Instrumentation for what your services actually do.

Kockpit is an engineering platform for Spring Boot systems: it audits every call in and out, flips features and configuration without a redeploy, and gives you one console to watch it all happen — backed by OpenSearch and shippable to your own filesystem, Azure, or AWS.

View source on GitHub → Quick start
Audit trail
ACTIVE
HTTP, batch and key-value events
Feature flags
HOT-SWAP
No redeploy required
Dynamic config
LIVE
Change values at runtime
Instances health
HEARTBEAT
Which instances are alive
Advisory

Starting with kockpit 2.0.0, the platform targets Spring Boot 4 only (Spring Framework 7, Jakarta EE 11, Spring AI 2.x) and requires Java 21 minimum for both build and runtime — including projects consuming kockpit-rules-maven-plugin. Teams still on Spring Boot 3.x should stay on the kockpit 1.x line.

What it is

One platform, built out of modules you can take individually.

Kockpit isn't a monolith bolted onto your services. Your applications embed a few Spring Boot starters; a backend, a stream and a web console run beside them. Pick a module to see what it is made of.

Kockpit Audit

kockpit-audit/

The libraries your applications embed to record what they do: incoming and outgoing calls, HTTP exchanges and key-value events, for APIs and batch jobs alike. Audits are published as messages and end up indexed in OpenSearch, searchable from the console.

  • kockpit-audit-annotation@Audited and AuditCommandLineRunner, to audit methods and batch jobs.
  • kockpit-audit-api · -api-impl · -sdkThe audit model, the API that builds and publishes audits, and its Spring Boot auto-configuration.
  • kockpit-obfuscationMasks sensitive fields in JSON and XML payloads before they are stored.
  • kockpit-audit-rulesAudits each rule and flow run by the Kockpit rule engine.
  • kockpit-audit-openapiTags each audit with the OpenAPI operation id of the call.
  • kockpit-features-auditAudits the HTTP exchanges of RestTemplate, RestClient and WebClient, with Kafka and Event Hub starters.

Note: kockpit-audit-web is deprecated; use kockpit-features-audit instead.

Kockpit Features

kockpit-features/

Runtime features your applications pick up from a starter, and that the console drives through the backend. Each feature comes in two halves: an application side, embedded in your service, and a backend side, which serves it to the console.

  • kockpit-features-featureflippingFeature flags you turn on and off from the console, without a redeploy.
  • kockpit-features-dynaconfigConfiguration values you change at runtime.
  • kockpit-features-cacheCache statistics per application; clear a cache or reset its statistics from the console.
  • kockpit-features-heartbeatApplications report that they are alive, so the console knows what is running where.
  • kockpit-features-manifestApplication manifests stored on the filesystem, S3 or Azure Storage, and served to the console.
  • kockpit-features-auditHTTP exchange auditing; see Audit.

Kockpit Rules

kockpit-rules/

A rule engine with its own DSL. Rules are defined once, generated from a JSON file at build time, and executed and audited at run time.

  • kockpit-rules-starterThe Spring Boot starter: rule definitions, executor and registry.
  • kockpit-rules-maven-pluginGenerates the rules DSL from a JSON input file during the build.
  • kockpit-rules-designerA React/Vite app to design rules visually.
  • kockpit-rules-app-sampleA runnable application using the starter and the plugin.

Versions: the 2.x starter and plugin need Spring Boot 4 and Java 21; stay on 1.x for Spring Boot 3.

Kockpit Core

kockpit-core/

The plumbing every other module sits on: a publish/consume messaging abstraction between your applications and the Kockpit backend, with one implementation per storage. Changing storage means changing a dependency, not your code.

  • kockpit-core-communicationThe Publisher / Consumer message API.
  • kockpit-core-communication-filesystemMessages on a local or shared folder, for development and single-node setups.
  • kockpit-core-communication-s3Messages on AWS S3.
  • kockpit-core-communication-storageaccountMessages on an Azure Storage account.
  • kockpit-core-communication-pollingPolls the storage for new messages.
  • kockpit-core-sdkService definitions and message listeners the features build on.

Kockpit Backend

kockpit-core-applications/kockpit-backend-application/

The Spring Boot application behind the console. It assembles the backend services and the backend side of every feature, and ships as one Docker image per storage.

  • kockpit-backend-service-searchAudit search on OpenSearch, including AWS-signed requests.
  • kockpit-backend-service-dashboardAudit statistics per application: volumes, status distribution and trends over time.
  • kockpit-backend-authentication-basicThe signed-in user and their Cognito groups.
  • Imageskockpit-backend-application-filesystem, -aws, -azure and -azure-eventhub.

Kockpit Stream

kockpit-core-applications/

The audit stream carries audits from your services into OpenSearch as they arrive, rather than in a batch job. See how it reads each source.

  • kockpit-audit-streamReads audits from Kafka, Event Hubs or Kinesis (with or without enhanced fan-out) and indexes them into OpenSearch; on AWS, archives them to S3 first.
  • kockpit-kinesis-s3-applicationNot for audits: bridges feature messages published on Kinesis to the S3 layout the backend reads.
  • Imageskockpit-audit-stream-application-kafka, -aws and -aws-efo; kockpit-kinesis-s3-application.

Kockpit Console

kockpit-core-applications/kockpit-console/

A React web console over the backend API: one place to search audits, open them end to end, and operate the features running in your applications. See its pages and what it looks like.

  • AuditsSearch, saved filters and a detail view per audit.
  • Feature flipping · Dynamic configurationChange flags and values at runtime.
  • CachesCache statistics, clear and reset per application.
  • Home · Instances healthA dashboard of audit statistics, and the heartbeats of every instance.

Kockpit AI

kockpit-ai/

An MCP server built on Spring AI that exposes audit search to AI agents, so an assistant can ask what your systems have been doing without a custom integration.

  • kockpit-ai-mcp-serverThe MCP server, searching audits on OpenSearch.
  • kockpit-ai-mcp-server-awsThe same server for Amazon OpenSearch Service, with signed requests.

Samples: kockpit-samples/kockpit-sample-all wires the audit and feature starters into one runnable application; the Azure, filesystem and Kubernetes stacks run it.

How it helps

What you get on the console.

Each page of the web console, backed by the Kockpit backend API. Every page works on one domain and environment at a time, picked from the console's header. Pick a page to see what you can do there.

Home

/home

The landing page: a dashboard built from the audits of the selected domain and environment.

  • OverviewTotal requests, success rate (2xx), error rate (4xx and 5xx) and average response time.
  • Time rangeFrom the last hour to the last 30 days.
  • Per applicationRequest distribution and HTTP status codes by application.
  • Over timeRequest volume over time, per application.

Audit details

/audits/:id

One audit opened end to end, with a tab per view. See every view, with screenshots.

  • OverviewApplication, version, host, domain and environment; audit, request and trace ids; start, end and duration.
  • Request / ResponseThe payloads that came in and went out.
  • HTTP exchangesThe outgoing HTTP calls the service made while handling it.
  • RulesThe rules and flows that ran, as a map or a timeline.
  • Key-valuesThe key-value events recorded along the way.
  • JSONThe raw audit document.

Feature flipping

/feature-flipping/:service

Turn features on and off in running services: no build, no redeploy, no restart window to coordinate. See the screenshot.

  • Flags per serviceEach service declared in a manifest has its own list of flags.
  • RepublishForce-publish every flag to the service's instances again.
  • HistoryRecent changes, with who made them and when.

Dynamic configuration

/dyna-config/:service

Change configuration values of live applications the same way: at runtime, without shipping a new artifact. See the screenshot.

  • Values per serviceEach service's configuration keys and their current values.
  • Edit in placeChange a value, then confirm or cancel.
  • RepublishForce-publish the whole configuration to the service's instances again.

Caches

/cache

The caches of each service, as reported by the services themselves.

  • StatisticsCaches, total gets, total hits and hit rate.
  • ClearPublish a reset message, so every instance empties the cache.
  • Reset statisticsStart the counters again from zero.
  • RefreshReload the latest statistics from the backend.

Instances health

/health

Every instance of your services sends a heartbeat; this page shows how recent each one is.

  • HealthyLast heartbeat less than 3 minutes ago.
  • WarningLast heartbeat 3 to 5 minutes ago.
  • CriticalLast heartbeat more than 5 minutes ago.
  • Health rateThe share of healthy instances.

Manifests & settings

/manifest · /settings

Manifests declare your domains, environments and services; the console builds its menus from them. Settings keep your own preferences, in the browser.

  • ManifestsSee the services each manifest declares, upload a new manifest (JSON) or download one.
  • FavoriteA favorite domain and environment, loaded by default when you come back.
  • Page size · Auto-refreshDefault page size of the audit search, auto-refresh rate of the health page.
  • TruncationHow long a configuration value can be before it is truncated.
The console

What it actually looks like.

The Kockpit web console — audit search, dynamic configuration, and feature flipping, all driven by the same manifest.

kockpit / local — Audits (kockpit-manifest-local.json)
Kockpit console Audits screen with the saved filter "kockpit-samples-all, en erreur" applied, listing the sample application's failed POST and DELETE calls with their app ID, request ID, method, path, duration and 400 or 500 status

Full-text and field search across audit events — request ID, path, method, status, or any custom field — plus saved filters declared in the manifest, here the sample application's failed calls. Each team or platform gets its own manifest file, browsable from the same console without standing up a separate deployment.

kockpit / local — Dyna Config
Kockpit console Dyna Config screen showing three configured keys, their sync status, and inline edit controls

Dynamic configuration keys with live sync status — configured, synced, or pending a save — editable inline without shipping a new build.

kockpit / local — Feature Flipping
Kockpit console Feature Flipping screen for the Kockpit Sample Application, showing its compression.enabled feature key switched on, with Properties and History tabs

Feature keys with on/off toggles and optional expiry dates, plus a history tab for tracking who changed what and when — flipped live, without a redeploy.

Inside an audit

Every call, opened up end to end.

Open any audit from the list to see everything the service recorded about that one request: the inbound exchange, every outgoing call it made, the business rules it ran, and the values indexed for search. The screens below follow a single POST /api/orders from the sample application.

kockpit / local — Audits / Details
Audit Details tab for a POST /sample-app/api/orders request: a summary bar with method, path, 201 Created status, 412 ms duration and user, cards for the Request & Response, 4 outgoing HTTP calls, 2 rule flows with 1 rule in error and 11 indexed values, then identifiers, timing with retention, application and environment

Details

The one-screen summary of the request, and the way into every other view.

  • Request at a glance: method, path, status, duration and the calling user.
  • In this audit: what was recorded, with counts, and rules or calls in error flagged before you open them.
  • Identifiers and timing: audit and trace IDs to copy, start and end, and how long the audit is kept.
  • Where it ran: application, version, artifact, domain, environment and host.
kockpit / local — Audits / Request & Response
Request & Response tab: the inbound POST /sample-app/api/orders with its headers, the Authorization header hidden behind a show toggle, the JSON order body, and the 201 Created response with its headers and JSON payload

Request & Response

The inbound exchange exactly as the service received and answered it.

  • Side-by-side request and response, with status, user and origin.
  • Headers listed and counted, sensitive ones hidden until you choose to show them.
  • Bodies pretty-printed and syntax-highlighted, with size, line wrapping and copy.
kockpit / local — Audits / HTTP Exchange
HTTP Exchange tab: 4 outgoing calls to catalog, customers, loyalty and payments services on a timeline, the loyalty call flagged as 404 Not Found, and the payment POST expanded with its request headers and body and its 201 Created response

HTTP Exchange

Every outgoing call the service made while handling the request.

  • Waterfall timeline: when each call started and how long it took, within the request.
  • Failures stand out: failed calls are outlined, marked with an icon and counted in the header.
  • Expand any call for its URL, query parameters, headers, body and response payload.
  • Filter calls by method, URL or status.
kockpit / local — Audits / Rules
Rules tab, Map view: the OrderValidation and PricingAndPayment flows with their rules as blocks, the failing ApplyLoyaltyDiscount rule selected and shown with its steps, the failed LoadLoyaltyCard step, the error message and the execution trace

Rules

What the Kockpit rule engine decided for this request, flow by flow.

  • Flows, rules and steps (predicates and actions), each with its status and duration.
  • Map, Timeline and Flow views of the same execution.
  • Failing rules highlighted, with the failed step, the error message and its details.
  • Execution trace of each rule, ready to copy.
kockpit / local — Audits / Key & Value
Key & Value tab: 11 indexed keys such as requestUri, httpMethod, httpStatus, duration, principal, customerId and orderId, each with its TEXT or INT type and value

Key & Value

The business values the service attached to the audit, indexed for search.

  • Typed values (text or integer), so ranges and exact matches both work.
  • Searchable from the audit list: find every request for an order, a customer or a status.
  • Filter and copy keys and values.
kockpit / local — Audits / Json
Json tab: the raw 15.3 KB audit document as a collapsible tree, with Tree and Text modes, a search box, and Expand, Collapse, Copy and Download actions

Json

The raw audit document, for anything the other views don't show.

  • Tree or text, with the document size.
  • Search keys and values, expand or collapse everything.
  • Copy or download the audit to share or attach to a ticket.
Architecture

Two channels, on the infrastructure you already run.

Your services talk to Kockpit on two channels. Audits go through a stream into OpenSearch, where the backend searches them. Features (flags, configuration, caches, heartbeats) go both ways as messages on a shared storage. The backend ships in one image per storage; pick one to see how it is wired.

Filesystem

kockpit-backend-application-filesystem

Everything on one machine or one shared volume: the right default for development, on-premises and single-node setups.

Audits Your services Kafka Audit stream OpenSearch Backend Console
Features Your services Folder / volume Backend Console
  • Storagekockpit-core-communication-filesystem for feature messages, manifests read from the same folder.
  • Audit streamkockpit-audit-stream-application-kafka, from Kafka into OpenSearch.
  • Maven profilefilesystem, active by default.
  • Try itThe Kafka and Kubernetes quick starts.

Azure

kockpit-backend-application-azure

Feature messages and manifests on an Azure Storage account; audits on Kafka.

Audits Your services Kafka Audit stream OpenSearch Backend Console
Features Your services Azure Storage Backend Console
  • Storagekockpit-core-communication-storageaccount for feature messages, manifests on the same account.
  • Audit streamkockpit-audit-stream-application-kafka, from Kafka into OpenSearch.
  • Backend's own auditsSent to Kafka, through kockpit-features-audit-starters-kafka.
  • Maven profileazure.
  • Try itThe Azure quick start, with Azurite emulating the storage.

Azure Event Hubs

kockpit-backend-application-azure-eventhub

The Azure backend, with its audits sent through the native Event Hubs client instead of Kafka.

Audits Your services Event Hubs Audit stream OpenSearch Backend Console
Features Your services Azure Storage Backend Console
  • Storagekockpit-core-communication-storageaccount, as for Azure.
  • Backend's own auditsSent to Event Hubs, through kockpit-features-audit-starters-eventhub.
  • Audit streamThe Kafka image with the eventhub Spring profile, on Event Hubs' Kafka endpoint.
  • Maven profileazure-eventhub.

AWS

kockpit-backend-application-aws

Feature messages and manifests on S3, audits on Kinesis, and Amazon OpenSearch Service with signed requests. The audit stream archives every batch of audits to S3 before indexing it.

Audits Your services Kinesis Audit stream OpenSearch Backend Console
Archive Audit stream S3 archive OpenSearch
Features Your services S3 Backend Console
  • Storagekockpit-core-communication-s3 for feature messages, manifests on S3.
  • Legacy messageskockpit-core-communication-legacy keeps applications on the older S3 message format working.
  • Audit streamkockpit-audit-stream-application-aws, or -aws-efo for Kinesis enhanced fan-out.
  • ArchiveBatches of audits on the audits-<env> bucket; each indexed audit points to its S3 object.
  • Kinesis to S3kockpit-kinesis-s3-application bridges feature messages published on Kinesis to the S3 layout the backend reads.
  • Backend's own auditsSent to Kinesis, through kockpit-audit-notification-kinesis.
  • OpenSearchRequests signed by kockpit-aws-opensearch-request-signing.
  • Maven profileaws.
  • Try itThe AWS quick start: LocalStack, with the apps run from your IDE.
Stream processing

Audits arrive as a stream, not a batch job you run later.

The audit stream reads audits off your broker and indexes them into OpenSearch as they arrive, in batches. One application, built per source; pick a source to see how it reads.

Kafka

kockpit-audit-stream-application-kafka

Your services publish their audits on a Kafka topic; the audit stream consumes it and indexes every batch into OpenSearch.

Audits Your services Kafka topic Audit stream OpenSearch Backend
  • SourceThe audits topic by default (kockpit.audit.stream.kafka.topics).
  • ScalingA consumer group named after the application: run more instances to share the partitions.
  • Starterskockpit-audit-stream-starter-kafka and -starter-opensearch.
  • Maven profilekafka, active by default.
  • Try itThe Kafka, Azure and Kubernetes quick starts.

Azure Event Hubs

kockpit-audit-stream-application-kafka

Event Hubs exposes a Kafka endpoint, so the Kafka image reads it as is: the eventhub Spring profile only switches the Kafka client to SASL_SSL.

Audits Your services Event Hubs Audit stream OpenSearch Backend
  • ImageThe Kafka image, with SPRING_PROFILES_ACTIVE=eventhub.
  • ConnectionBOOTSTRAP_SERVERS on the namespace's Kafka endpoint, and the SASL login (with the connection string) in SASL_JAAS_CONFIG.
  • ProducersServices can publish through Kafka, or through the native client (kockpit-features-audit-starters-eventhub).

Kinesis

kockpit-audit-stream-application-aws

The AWS build reads a Kinesis stream and, before indexing, archives every batch of audits to S3: each indexed audit keeps a pointer to its S3 object.

Audits Your services Kinesis stream Audit stream S3 archive OpenSearch Backend
  • SourceKINESIS_STREAM_NAME; shards are shared between instances through leases in DynamoDB.
  • ArchiveBatches of audits on the audits-<env> bucket; the index keeps each audit's S3 URI, offset and size.
  • Already offloadedAudits a producer has already written to S3 are indexed as they are, with their own S3 key.
  • OpenSearchAmazon OpenSearch Service, with signed requests.
  • Maven profileaws.
  • Try itThe AWS quick start, with LocalStack.

Kinesis enhanced fan-out

kockpit-audit-stream-application-aws-efo

The same AWS build, registered as an enhanced fan-out consumer: Kinesis pushes the records to it, with throughput of its own instead of sharing the stream's read limit with other consumers.

Audits Your services Kinesis EFO Audit stream S3 archive OpenSearch Backend
  • ConsumerRegistered as KINESIS_CONSUMER_NAME, the application name by default.
  • Archive and indexAs for Kinesis: S3 first, then OpenSearch with the S3 pointer.
  • Starterskockpit-audit-stream-starter-kinesis-efo and -starter-opensearch-s3.
  • Maven profileaws-efo.

Indexing, for every source

kockpit-audit-stream-starter-opensearch
  • Daily indicesOne index per domain, environment and retention, rotated every day: <domain>-<index>-<env>-ttl<N>d-<date>-00001.
  • RetentionEach audit carries a TTL in days (5 by default); an ISM policy deletes its index once it is older than that.
  • Read alias<domain>-<index>-<env>-read spans every index of an environment: that is what the backend searches.
  • Write aliasesOne per retention, moved to the new index each day. Writes require the alias, so a missing one fails and is retried instead of creating a stray index.
Quick start

Get a console running in minutes.

Each provider has a ready-made Docker Compose stack in the repository's docker/ folder, and a Helm chart deploys the same stack on Kubernetes. Images come from ghcr.io/mahieddine-ichir/kockpit with their latest tag.

Prerequisites: Docker with Compose v2.20+ (the stacks use include), about 4 GB of memory for Docker, and a clone of the repository: git clone https://github.com/mahieddine-ichir/kockpit.git && cd kockpit. The stacks share container names and ports, so run one at a time.

Kafka stack

docker/kafka/docker-compose-full.yml starts Kafka, OpenSearch and OpenSearch Dashboards, plus the audit stream, the backend (filesystem storage) and the console. The backend reads manifests and audit payloads from the repository's data/ folder, or from KOCKPIT_DATA_DIR if you set it.

1
Give the backend a manifest
The console lists the services declared in manifests. Copy the sample one into the data folder. 
mkdir -p data/manifests && cp docker/manifests/*.json data/manifests/
2
Start the stack
Images are pulled again on every up, so you always run the latest build. 
cd docker/kafka
docker compose -f docker-compose-full.yml up -d
3
Load the sample audits (optional)
1000 anonymised audits, dated September 2025: widen the console's time range to see them. 
docker exec -w /init-data opensearch bash init-data.sh
4
Open the console
Go to http://localhost:3000. Audits your own services send to the audits topic on localhost:29092 show up as the stream indexes them.
Console
http://localhost:3000
Backend API
http://localhost:8080/api
Audit stream
http://localhost:8081
OpenSearch
http://localhost:9200
Dashboards
http://localhost:5601
Kafka
localhost:29092 (host) · kafka:9092 (containers)

Stop: docker compose -f docker-compose-full.yml down from docker/kafka. Infrastructure only, to run the apps from your IDE: docker compose up -d in the same folder.

Azure stack

docker/azure/docker-compose-full.yml starts Azurite (the Azure Storage emulator), Kafka, OpenSearch and Dashboards, plus the audit stream, the backend (Azure Storage), the console and a sample application. No Azure account is needed: the blob containers are created in Azurite and the sample manifest is uploaded on startup.

1
Start the stack
cd docker/azure
docker compose -f docker-compose-full.yml up -d
2
Generate audits with the sample app
Each call is audited and sent to Kafka within 5 seconds. createMessage and the DELETE fail on purpose part of the time, to give you some errors to look at. 
curl http://localhost:8082/sample-app/api/sayHello/kockpit
curl http://localhost:8082/sample-app/api/facts
curl -X POST http://localhost:8082/sample-app/api/createMessage \
  -H 'Content-Type: application/json' -d '{"message":"hello"}'
curl -X DELETE http://localhost:8082/sample-app/api/sayHello
3
Load the sample audits (optional)
The Azure backend searches the audit-data index, so pass its name. 
docker exec -w /init-data -e INDEX_NAME=audit-data opensearch bash init-data.sh
4
Open the console
Go to http://localhost:3000 and pick the kockpit / local manifest. Its saved filters show the sample app's successful and failed calls.
Console
http://localhost:3000
Backend API
http://localhost:8080/api
Sample app
http://localhost:8082/sample-app
Audit stream
http://localhost:8081
Azurite blob
http://localhost:10000/devstoreaccount1
OpenSearch · Dashboards
:9200 · :5601

Real storage account: cp .env.azure .env in docker/azure, fill in the STORAGE_* and MANIFESTS_STORAGE_* values, then start the stack the same way.
Manifests: the files in docker/manifests are uploaded on every up and overwrite the copies in Azurite, so edit them there rather than from the console.
Stop: docker compose -f docker-compose-full.yml down (add -v to also delete the Azurite and OpenSearch data).

AWS stack

docker/aws/docker-compose.yml starts LocalStack and OpenSearch. On startup, LocalStack's init scripts create the S3 buckets (with the sample manifest), SQS queues, SNS topics, Kinesis streams and DynamoDB tables. This stack provides the AWS infrastructure only: the Kockpit applications are run from your IDE against it.

1
Start LocalStack and OpenSearch
If your LocalStack version requires one, export LOCALSTACK_AUTH_TOKEN first. 
cd docker/aws
docker compose up -d
2
Check the resources
The LocalStack gateway listens on localhost:4566, region eu-west-1. 
docker exec localstack_console_services awslocal s3 ls
docker exec localstack_console_services awslocal kinesis list-streams
3
Run the Kockpit apps against it
Build the AWS flavours with the aws Maven profile and run the backend and the audit stream from your IDE, pointing them at http://localhost:4566 and http://localhost:9200.
LocalStack gateway
http://localhost:4566
OpenSearch
http://localhost:9200
Dashboards
http://localhost:5601

Stop: docker compose down from docker/aws.

Kubernetes (Helm)

The deployments/kubernetes/kockpit chart deploys the Kafka stack on a single-node cluster: Kafka, OpenSearch, the audit stream, the backend (filesystem storage), the console and the sample application. It needs kubectl, Helm 3 or later and about 6 GB of memory for the cluster.

1
Create a local cluster
With kind here; minikube or Docker Desktop's Kubernetes work too. 
kind create cluster --name kockpit
2
Install the chart
The Java applications take a minute or two to become ready. 
helm install kockpit deployments/kubernetes/kockpit --namespace kockpit --create-namespace
kubectl -n kockpit get pods -w
3
Open the console and generate audits
Forward the console and the sample app, then call the sample app as in the Azure stack. 
kubectl -n kockpit port-forward svc/kockpit-console 3000:80 &
kubectl -n kockpit port-forward svc/kockpit-sample-app 8082:8082 &
curl http://localhost:8082/sample-app/api/sayHello/kockpit
Console (port-forward)
http://localhost:3000
Sample app (port-forward)
http://localhost:8082/sample-app
In-cluster backend
kockpit-backend:8080
In-cluster Kafka · OpenSearch
kockpit-kafka:9092 · kockpit-opensearch:9200

Values: use your own Kafka or OpenSearch with kafka.enabled=false / opensearch.enabled=false, enable Dashboards with dashboards.enabled=true or an ingress with ingress.enabled=true. See the chart's README.md for all of them.
Manifests: the chart's files/manifests are copied into the backend's storage on every start, overwriting the stored copies.
Uninstall: helm uninstall kockpit -n kockpit, then kind delete cluster --name kockpit.

Resources

Go deeper.

Source code

↗

The full kockpit suite — audit, rules, backends, console, and samples — under the Apache-2.0 license.

github.com/mahieddine-ichir/kockpit

Documentation

↗

Module composition, configuration properties, and environment variables for every package.

README.md · replace with your docs site

Team

↗

The people building kockpit, and the commit history behind each module.

contributors · replace with your team page