Nobody Teaches You How to Build Kibana Plugins. So I Packaged Everything I Know

Source: Dev.to

The Problem Nobody Talks About

Try Googling “how to build a Kibana external plugin.”

Go ahead. I’ll wait.

You’ll find:

• Elastic’s official docs (sparse)
• A deprecated Yeoman generator from 2018
• A handful of Stack Overflow posts from people who gave up

That’s basically it.

When I started building Kibana plugins at UNIBERG, my main learning resource was… reading Kibana’s source code: the actual Kibana repo, 200 k+ files. I searched for patterns, hoping the internal plugin I was looking at was doing things the “right” way and not some legacy hack that hadn’t been cleaned up yet.

There’s no tutorial, no course, no “Kibana Plugin Development for Dummies.” You just figure it out.

Which is fine — I actually enjoy that kind of thing. But after 6 + years of figuring it out, I had a lot of knowledge sitting in my head (and scattered across about 40 different notes.md files) that could save someone months of pain.

Why a Claude Code Plugin?

I’d been using Claude Code for a while. One day I looked at the plugin docs and realized the structure was oddly similar to what I already knew from Kibana plugins:

• Manifest file
• Directory structure
• Configuration

…except way simpler. Claude Code plugins are basically:

• A JSON manifest
• Some markdown files for commands/skills/agents

No compiled code. No build step.

My first thought: “I could put my entire Kibana knowledge base into a skill file and Claude would just… know it.”

My second thought: “That can’t actually work.”

It did.

---

What I Actually Built

Started on a Saturday afternoon. Figured it’d take a couple of hours.

It took two full days, plus another week of adding stuff because I kept thinking “oh, and this pattern too.”

The plugin has

• 10 slash commands – e.g.

  • /scaffold – generates a full plugin skeleton (server + public + types + manifest)
  • /route – creates server routes with proper @kbn/config-schema validation
  • /component – generates EUI‑based React components
  • /security – sets up RBAC
  • …and a few more

• 6 specialized agents – an architect that reviews your plugin structure, a security auditor that checks for auth bypass and data leaks, a migration assistant for version upgrades, etc.

• 1 massive skill file – ~400 lines of concentrated Kibana‑plugin knowledge: plugin lifecycle, route patterns, ES client usage, EUI components, auth middleware, testing patterns, common pitfalls.

The skill file is the part I’m most proud of (and also the part that took the longest because I kept going “wait, I forgot about saved‑object migrations” and adding another section).

The Stuff That Was Hard to Get Right

Route authentication patterns

This sounds boring. It is boring. But if you get it wrong, you leak user data across tenants. I’ve seen it happen. I’ve caused it to happen.

The plugin bakes security checks into every generated route by default, because I learned the hard way that “I’ll add auth later” means “I’ll discover the auth bug in production.”

Every route the /route command generates starts with:

const user = security.authc.getCurrentUser(request);
if (!user) return response.forbidden();

Boring, but I have scars from the time it wasn’t there.

EUI component patterns

Elastic UI has maybe 80 + components. Some are well‑documented, some aren’t, and some have props that don’t do what you’d think. I spent a full day once debugging why an EuiBasicTable wasn’t rendering pagination correctly — turned out I was passing totalItemCount as a string instead of a number. TypeScript didn’t catch it because the prop type was any.

The /component command generates components that already handle the edge cases I’ve hit:

• Dark‑mode compatibility
• Responsive layouts
• Loading states
• Error boundaries

Stuff I used to forget and then fix in production.

Elasticsearch client integration

The Kibana ES client isn’t the same as the regular @elastic/elasticsearch client. It’s wrapped, has different error types, handles auth differently, and changes between Kibana minor versions in ways that aren’t always documented.

I wrote a service‑layer pattern into the skill that handles:

• Type coercion
• Error mapping
• Defensive defaults for every ES response

It’s about 200 lines of code I never want to look at again, but every plugin I build copies it.

The Part Where I Question Everything

Here’s what’s weird about open‑sourcing your expertise: someone could install this plugin and skip years of learning.

• The auth patterns I figured out through a security audit that almost gave me a heart attack? They’re in there.
• The EUI dark‑mode bug that cost me a full Wednesday? Handled automatically.
• The Elasticsearch response‑transformation layer I wrote at 2 AM because production data had timestamps in three different formats? Built into the skill.

Am I devaluing my own experience by giving it away?

Maybe. Probably not. The plugin can scaffold code and teach patterns, but it can’t debug your specific production issue at 11 PM on a Thursday. It can’t look at your data model and say “this won’t scale past 100 k records.” It can’t sit in a meeting and explain to a product manager why multi‑tenancy takes three weeks, not three days.

Tools don’t replace experience. They just make the boring parts faster.

What Actually Happens When You Use It

Here’s a real example. You type:

/scaffold

Claude asks what you’re building. You say “user management plugin with RBAC.”

Two minutes later you have:

• Plugin manifest with correct Kibana version targeting
• Server‑side setup with route registration
• Public‑side app mounting with React
• TypeScript types for your domain
• Basic EUI page layout with navigation
• Security configuration with feature privileges
• A working kibana.jsonc

Before this plugin, that setup took me about 4 hours. I’d still forget something — usually the kibana.jsonc configuration, because that file is easy to get wrong and hard to debug when you do.

Things That Are Still Missing

I’ll be honest about what’s not in there yet:

• State management patterns – I have opinions (use React context + custom hooks, not Redux) but haven’t formalized them into commands yet.
• Logging and monitoring – Important for production plugins; I keep putting it off because it isn’t the fun part.
• Inter‑plugin dependencies – Kibana’s dependency‑injection system is powerful but confusing. I’ve been working with it for years and still double‑check the docs every time.
• Real‑time data patterns – WebSocket‑style updates through Kibana. I’ve done it, but the patterns aren’t clean enough to template yet.

The Open‑Source Anxiety

Publishing it was uncomfortable.

Not because of the code — the code is fine. But because it’s basically my brain in a markdown file. Every pattern is something I learned through mistakes. Every anti‑pattern check in the security agent is a bug I caused or caught.

• What if someone finds something wrong?
• What if a pattern that works in my use case breaks in theirs?
• What if an Elastic engineer looks at it and says “that’s not how we do it internally”?

Then… they’ll open an issue, and I’ll fix it or learn something new.

That’s kind of the point.

How to Actually Use It

If you’re building Kibana plugins (or thinking about it):

/plugin marketplace add ch-bas/kibana-plugin-helper
/plugin install kibana-plugin-helper@kibana-plugin-helper

Then try /scaffold and see what happens.

If you’re not building Kibana plugins — honestly, most people aren’t — this post is really about something else: packaging your hard‑won knowledge into something others can use.

Whatever your niche, you have patterns and lessons that could save someone else months. The format doesn’t matter (a plugin, a blog post, a markdown file in a GitHub repo). The point is getting it out of your head and into a place where it helps.

I just happened to pick a Claude Code plugin because the structure was familiar and I’m a developer, so of course I over‑engineered it.

What I’d Like to Know

• If you’re doing Kibana plugin development: What’s the thing you wish someone had told you on day 1? I might add it.
• If you’ve open‑sourced your expertise before: Did it help your career or hurt it? I’m genuinely curious.
• If you’ve used Claude Code plugins: Are people actually discovering them through marketplaces, or is it still mostly word‑of‑mouth?

Drop your answers — I read everything.

GitHub:
License: MIT (do whatever you want with it)

Tags: Kibana ElasticStack OpenSource ClaudeCode WebDevelopment React