Repository structure

A high-level walk through of the folder structure of our repository.

Tip: Look for a README.md in a folder to learn about its contents.

Files related to our Buildkite configuration. This is where we keep our pipeline definitions, and some scripts that are used in the pipelines. Maintained by the Operations team, but all developers should be mindful of how their changes may impact the pipelines.

Contains GitHub configuration settings. This file contains issue templates, and the CODEOWNERS file. It's important for teams to keep the CODEOWNERS file up-to-date so the right team is pinged for a code owner review on PRs that edit certain files. Note that the CODEOWNERS file only exists on the main branch, and is not backported to other branches in the repo. To aid in making sure the CODEOWNERS file is always up-to-date "packages" in the Kibana repo are required to have an "owner" defined, those owners are then injected into the CODEOWNERS files automatically by the node scripts/generate codeowners command.

Every file in here is auto-generated by the API Docs system and used to render our API documentation. If you edit a public plugin or package API and run node scripts/build_api_docs you will see files changed in this folder. Do not edit the contents of this folder directly!

This contains the base configuration file, kibana.yml. If you want to tweak any settings, create a kibana.dev.yml in here which will get picked up during development, and not checked into GitHub.

This folder contains manually generated Markdown docs that end up hosted in our public documentation site.

These are our tested example plugins which demonstrate how to use our services and platform features. These example plugins should be written with the intention of helping developers understand how to use our services.

We used to write RFCs in md format and keep them in the repository, but we have since moved to Google Docs. We kept the folder around, since some folks still read these old docs. If you are an internal contributor you can visit this document to read about our current RFC process.

Contains our two license header texts, one for the Elastic license and one for the Elastic+SSPL license. All code files inside x-pack should have the Elastic license text at the top, all code files outside x-pack should contain the other. If you have your environment set up to auto-fix on save, eslint should take care of adding it for you. If you don't have it, ci will fail. Can be ignored for the most part, this rarely changes.

Documentation about our OpenAPI bundling workflow and configuration. See Kibana's hosted stateful and serverless docs.

Contains all of our reusable packages. A package is a module that can be consumed by other modules via importing, but it cannot be enabled or disabled like a plugin. We use packages for code that is shared across multiple plugins, or for code that is not specific to a plugin (for example, our i18n code lives in a package since it's used across many plugins, and it's not really plugin-specific code). If you find yourself writing code that is meant to be imported by other modules but doesn't really belong to any specific plugin, it's a good candidate for being extracted into a package.

This is an empty folder in GitHub. It's where third party developers should put their plugin folders. Internal developers can ignore this folder.

Contains a bunch of developer scripts. These are usually very small files with just two lines that kick off a command, the logic of which resides elsewhere (sometimes src/dev, sometimes inside packages). Example:

require('../src/setup_node_env');
require('@kbn/es-archiver').runCli();
		

This folder and the packages folder contain the most code and where developers usually find themselves. I'll touch on a few of the subfolder, the rest can generally be ignored, or are build/ops related code.

This folder contains code that initializes the Kibana runtime and a bit of work to handle authorization for interactive setup mode. Most devs should be able to ignore this code.

This contains the plugin infrastructure, as well as a bunch of fundamental services like Kibana's HTTP server, migrations, saved objects, and some UI utilities (toasts, flyouts, etc.).

This code contains build and development tooling related code.

Contains the Basic-licensed code that is common to all Kibana solutions. The code is organised in modules, that can be either plugins or packages. This document covers how packages differ from plugins.

Contains Basic-licensed plugins that are common to all Kibana solutions. They are organized according to their visibility: They can be shared or private (aka not accessible from solutions).

This contains global typings for dependencies that do not provide their own types, or don't have types available via DefinitelyTyped. This directory is intended to be minimal; types should only be added here as a last resort.

Contains all code and infrastructure that powers our non-basic features that are provided under a more restrictive license. The code is organized in the following subfolders:

Contains all of the non-basic modules that are common to all Kibana solutions. Like the src/platform code, it is organized in modules that can be either plugins or packages, and in turn, these plugins are organized according to their visibility.

Contains all of the code that is specific to each Kibana solution. At the moment, we have a folder for observability, another for security, another for search and another for workplaceai (serverless only).

These folders contain the modules that belong to each solution, and these modules are also categorized as plugins or packages. Unlike the src/platform and the x-pack/platform code, the solution-specific modules are private by definition, aka they cannot be accessed from platform nor from other solutions.

Contains all example plugins that rely on gold+ features.