An App is a standalone web application that you create in Cribl and that runs right inside the Cribl UI. It takes a workflow that normally means too many clicks, a doc nobody reads, or a process only one person understands, and turns it into a focused tool anyone with the right access can open and use. Think configuring something, reviewing something, troubleshooting something, or moving through a repeatable process with less guesswork.
For the full product details, start with the official Apps docs.
Quick reality check before you get too excited
Apps are a Preview feature, and they run on Cribl.Cloud only today. Preview means the feature is still being built and is not recommended for production use yet. It is a great time to experiment, share ideas, and shape where this goes. It is not the time to bet a critical production workflow on it.
Everything below reflects how Apps work right now. Since Preview features move fast, the docs are always the tiebreaker.
How an App actually works
You do not need to be a frontend engineer to think about Apps, but it helps to know the moving parts so your expectations are set correctly.
It runs in its own space. Cribl renders the core UI shell, and your App runs in an isolated iframe next to the normal product screens. It has its own UI, its own persistent state, and its own settings. Because it is isolated, admins can install, upgrade, and uninstall it without touching your underlying Cribl deployment.
It talks to Cribl through documented APIs. An App works with real Cribl resources like Worker Groups, Pipelines, Sources, Destinations, and KV, using the same documented API surface you would use for any integration.
Permissions still apply, and they stack. Being able to open an App is separate from being able to do the thing the App does. If a user lacks access for an underlying operation, that call fails with a permission error, even if they can see and open the App. Good Apps expect this. They dim or disable actions the viewer cannot perform and show a clear message instead of breaking. Treat permission variance as the default, not the edge case.
External calls are declared, not assumed. An App can call third-party APIs, but only through Cribl's server-side proxy, and only for hosts the App declares in proxies.yml. Outbound access is on by default for an Organization, but each App still has to name the domains it needs. If it is not declared, it does not go out.
Secrets go in the KV store, encrypted. Apps persist state in a key-value store so it follows the deployment, not the browser. API keys, tokens, and other credentials must be written with KV encryption. Never drop a secret into a plain KV value.
Only Workspace Administrators can create Apps. Admins also handle install, upgrade, and uninstall. Anyone with access to an Organization where Apps are installed can open and use one from the Apps list.
One more thing worth saying plainly: the runtime ships with no built-in LLMs or background AI. Whatever an App does depends entirely on what that specific App declares and calls. AI-assisted coding tools can help you build an App faster, but they do not run inside Cribl on their own.
When should you think "this could be an App"?
Start with workflow pain. A good App idea usually sounds like one of these:
- "We do this all the time, but it takes too many steps."
- "Only one or two people really know how to do this correctly."
- "This process lives in a doc, but people still get stuck."
- "This Pack would be easier to use if it had a guided front end."
- "Users have to check several places before they know what to do next."
- "We keep answering the same setup or troubleshooting questions."
- "This team needs a simpler view for their specific use case."
That is the sweet spot. Apps are not about building something shiny. They are about making useful Cribl workflows easier to follow, easier to repeat, and easier to share.
Apps and Packs are different
A simple way to hold it in your head:
Packs package configuration. Apps package experiences.
Use a Pack when you want to share reusable Cribl configuration: Sources, Routes, Pipelines, Destinations, and Knowledge Objects that move and shape data.
Use an App when you want to guide a user through a task, build a custom interface, or turn a process into something easier to use.
Often the answer is both. A Pack provides the reusable data-processing pieces, and an App provides the guided experience on top. In practice, Packs define the data flows and Apps make them usable.
App-shaped ideas
A few examples to get you thinking.
Pack Setup Companion. Walks users through configuring a Pack, explains the required settings, and helps them confirm they are ready to use it.
Pipeline Review Helper. A checklist-style App that helps a team review a Pipeline before promoting changes.
Destination Readiness Checker. Helps users confirm a Destination is ready before they start sending data to it.
Investigation Helper. A guided workflow for security users that keeps notes, queries, links, and findings in one place.
Admin Health View. A focused view that pulls common checks and important environment details into one screen for admins.
Runbook Assistant. Turns a repeated process from a doc, a Slack thread, or someone's head into a guided experience anyone can follow.
A quick test for App ideas
Fill in this sentence:
This App would help [type of user] do [specific task] without [current pain].
Examples:
- This App would help admins validate a Destination without checking five different screens.
- This App would help new users configure a Pack without needing someone to walk them through every step.
- This App would help security users collect investigation notes without copying details into a separate doc.
If you can fill that in clearly, you probably have the start of a good App idea.
Questions to help you find an idea
Run these with your own team:
- What workflow takes too many clicks today?
- What task do users regularly get wrong?
- What process requires tribal knowledge?
- What setup flow could use more guidance?
- What Pack needs a better front door?
- What troubleshooting flow should be repeatable?
- What information do users need in one place?
- What team-specific workflow could be simplified?
- What task do you wish someone could finish without asking you for help?
- What internal tool do you wish existed inside Cribl?
You do not need a polished idea to start. Half-formed workflow pain is usually where the best App ideas begin.
Where to go next
Community GitHub. This is where we post community apps. Grab an example, fork it, or use it as a starting point for your own: github.com/Cribl-Community.
Official Apps docs. Product details, technical requirements, and guidance for creators, admins, and users: docs.cribl.io/apps.
- Quick Start: build and install your first App
- Creator Guide: building blocks and packaging
- Admin Guide: roles, install, and external API access
- User Guide: discovering and using Apps
Apps Knowledge Base space. Community-friendly examples, idea prompts, practical guidance, and lessons learned: knowledge.cribl.io/apps-99.
#apps Slack channel. Ask questions, share ideas, and talk through app-shaped workflows with the community.
Bring your ideas
Have an idea? Bring it to the #apps Slack channel. It does not need to be perfect, and it does not need to be fully scoped. It can start as simply as:
"This workflow is annoying. Could this be an App?"
That is enough to get the conversation started.