On This Page

Home /App Platform (Preview)

App Platform (Preview) ​

Preview Feature ​

This Preview feature is still being developed. We do not recommend using it in a production environment, because the feature might not be fully tested or optimized for performance, and related documentation could be incomplete.

Please continue to submit feedback through normal Cribl support channels, but assistance might be limited while the feature remains in Preview.

The App Platform (Preview) lets you build and run custom applications embedded directly in Cribl. You use Apps to create tailored workflows, domain-specific UIs, and cross-product experiences that go beyond what Packs and built-in features offer.

The App Platform (Preview) is available only on Cribl.Cloud.

For a consolidated view of execution boundaries, credentials, and API handling (for example for security reviews), see Runtime, architecture, and security.

See the Cribl Apps GitHub repository for public example Apps.

What Is the App Platform (Preview)? ​

The App Platform (Preview) is an extension platform that lets you build Apps on top of Cribl products, using documented APIs and clear packaging standards.

An App is a standalone web application that runs inside the Cribl UI. Specifically:

  • Isolated execution: Cribl renders the core UI shell, while your App runs in an isolated iframe next to the core product screens.
  • Interactive experiences: It has its own UI, persistent state, and settings, backed by the Cribl APIs and KV store.
  • Permission-aware: Access to create, install, and run Apps follows your Organization roles. See Roles, permissions, and governance in the Admin Guide and Runtime, architecture, and security for execution and credential boundaries.

Because Apps are isolated from the core UI and have their own lifecycle, you can install, upgrade, and uninstall them without changing your underlying Cribl deployment.

Why Use Apps? ​

Use Apps when you need to go beyond what Packs and built-in screens can do on their own.

Apps help you:

  • Build streamlined workflows: Guide users through multi-step operations with purpose-built UIs instead of clicking across multiple Cribl pages.

  • Create domain-specific experiences: Tailor interfaces for specific teams or use cases (for example, security operations, compliance, or infrastructure troubleshooting) while still using common Cribl data and APIs.

  • Extend product capabilities: Add functionality that is not exposed in the Cribl UI (or combine existing capabilities in a new way) by calling documented Cribl APIs from your App.

  • Help users get what they need faster: Turn tribal knowledge and ad-hoc runbooks into repeatable experiences that anyone with the right access can follow.

  • Lower the barrier to building: With modern, AI-assisted coding tools, you can describe what you want, scaffold an App, and iterate without deep frontend expertise.

Who Builds Apps? ​

You’re an App builder if you design and ship experiences for others to use. Typical builders include data engineers, platform engineers, security professionals, operations professionals, consultants, partners, and anyone who owns a workflow they want to turn into a guided App.

To author an App you use Create App, Live Preview, and packaging. That workflow requires Workspace Administrator in the Workspace where you work. You do not need Organization-wide Administrator to build or preview Apps. Many teams use a dedicated development Workspace with non-production or synthetic data and grant Workspace Administrator only there, so builders do not require elevated roles in production Workspaces. An Organization Administrator then imports or upgrades the .tgz in staging and production Workspaces when you are ready to deploy. See Multiple App Builders in Your Organization and Roles, permissions, and governance in the Admin Guide.

As an App builder, your typical flow is:

  1. Scaffold and build the App, designing the UI and data interactions.
  2. Test locally and in the embedded iframe using Live Preview.
  3. Package the App bundle using the provided build tools.
  4. Share the package with an administrator for import, or use Deploy from the wizard for the Workspace where you started Create App.

For dev, staging, and production Workspaces and Git-based versioning, see Development and release workflow for customer Apps in the Admin Guide.

See the Quick Start: Build and Install Your First App and the Builder Guide.

Who Uses Apps? ​

You’re an App user if you open and run Apps that someone else created. Anyone with access to a Cribl.Cloud Organization where Apps are installed can open an App they can see in the Apps list.

As an App user, your typical flow is:

  1. Discover the App in the Apps list after an administrator installs it.
  2. Open the App and follow its workflows to complete your tasks.

An administrator installs each App and sets up App Settings and Organization policy when required. If something is missing, disabled, or shows an access message you do not expect, ask your administrator.

See the Admin Guide: Enable and Manage Apps and the User Guide: Access and Use Apps.

Browser Support ​

Apps can run on Chrome, Firefox, Safari, and Microsoft Edge, on their five most-recent versions.

Safari ​

Safari is supported for installed Apps and normal use, with two limitations to plan for:

  • Live Preview is disabled in Safari. The Cribl Leader is served over HTTPS, and Safari blocks the embedded HTTP connection to localhost (or a similar loopback URL) on your machine for security reasons. Use Chrome, Edge, or Firefox for Live Preview, or test by packaging and installing the App instead.
  • Client-side routing: History-based routers such as React Router’s BrowserRouter (and similar APIs in other frameworks) do not work reliably inside the App iframe in Safari. The App Platform requires a full page reload on each in-App navigation. Using MemoryRouter (or an equivalent in-memory router) avoids reloads but does not update the browser URL, so deep linking and bookmarks are not available.

Key Concepts ​

Use these concepts as your mental model for how Apps fit into Cribl and how they behave over time.

Apps vs Packs ​

Packs and Apps both extend Cribl, but in different ways:

  • Packs:

    • Package and share end-to-end data processing configurations.
    • Include Sources, Routes, Pipelines, Destinations, and Knowledge Objects.
    • Help you promote and reuse data flows across environments.

  • Apps:

    • Package interactive experiences: UI, flows, and logic.
    • Call Cribl APIs and work with existing Packs and configurations.
    • Can call third-party HTTP(S) APIs through Cribl’s server-side proxy when your App declares allowed domains and your Organization permits outbound access.
    • Guide users through tasks that would otherwise require jumping across multiple screens.

In practice, you often use both. Packs define the data flows, and Apps provide the guided experiences on top.

App Building Blocks ​

Each App is built from a small set of core building blocks:

  • UI: Your App’s screens, built with your preferred web stack and rendered inside the Cribl iframe.

  • App Settings: The Settings control (gear icon or row menu) opens App Settings, with two tabs: Key-Value Stores for keys and encrypted secrets, and External API Access for how outbound external calls are governed for this App. Outbound access is on by default. proxies.yml and platform rules still apply. See Configure App Settings in the User Guide and External API access in the Admin Guide.

  • KV store: A key-value store for App state, used to persist user selections, workflow progress, and other runtime data. You use KV instead of browser-local storage so state follows the deployment, not the browser. API keys, tokens, and other credentials must be written with KV encryption (encrypted=true). Do not store secrets in plain KV values. See the Builder Guide.

  • Proxy: A server-side path for outbound HTTP(S) calls to hosts outside Cribl. You declare allowed domains, paths, timeouts, and optional credential injection in proxies.yml at the project root. App code uses fetch() with full URLs. Cribl enforces the declaration and applies SSRF protections. See External APIs and proxies.yml in the Builder Guide. Outbound access is on by default for Organizations. Each App must still declare allowed hosts. See External API access in the Admin Guide.

  • License limits and feature gates: Deployment-level controls for whether the App Platform (Preview) is available and how Apps are allowed to run. You can leave the feature disabled until you finish internal checks or policy reviews.

  • Observability hooks: Logs and metrics that help you see how the App behaves, debug failures, and provide useful information to Cribl Support when needed.

App Lifecycle ​

Apps follow a clear lifecycle from development to removal:

  1. Build: You scaffold the App, design the UI and flows, and wire it up to documented Cribl APIs and the KV store.

  2. Package: You create a distributable App bundle that meets packaging and validation rules (manifest, metadata, versioning, proxies.yml, size limits, and so on). See Package, version, and deploy and Install an App for what Cribl enforces during packaging and import.

  3. Upload and install: An administrator uploads the package into a Cribl.Cloud Organization. The App appears in the Apps list once installed.

  4. Configure and run: Administrators configure hosted keys on Key-Value Stores, review External API Access as needed, and set Organization prerequisites. Members open the App and run its workflows inside the embedded experience.

  5. Upgrade: You ship new versions, and administrators install them. Cribl handles how upgrades affect KV data, external API policy, and compatibility.

  6. Uninstall and cleanup: When the App is no longer needed, an administrator uninstalls it. Cribl follows defined cleanup guarantees so behavior is predictable.

After you deploy an App, you can resume local development at any time: make changes, rebuild, and ship a new version. The lifecycle remains the same: build, package, upload, upgrade.

Builder vs User Flows ​

App builders and App users follow different paths through this lifecycle:

  • Builder flow:

    1. Scaffold and build the App.
    2. Test locally and in the embedded iframe.
    3. Package the App bundle.
    4. Share the package with admins or publish it through your chosen channel.

  • User flow:

    1. Discover the App in the Apps list after an administrator installs it.
    2. Open the App and run its workflows as needed.

    Administrators handle installation and App Settings configuration. Users who hit unexpected limits or errors should work with their administrator rather than changing App Settings themselves.

Design your App so both flows are obvious: builders know how to build and ship, and users know how to find and use.

Permissions and Execution Context ​

Organization roles for creating, installing, and running Apps are described in Roles, permissions, and governance in the Admin Guide.

When someone opens an App, design for the viewer’s actual access:

  • If the viewer lacks access for an operation (for example, listing certain Worker Groups), the call fails with a permission error.
  • Detect and handle these cases gracefully by dimming or disabling actions, showing clear “you may not have permission” messages, and offering next steps.

Treat permission variance as the default, not the exception. Design Apps that still provide value in read-only scenarios and fail softly when partial access is acceptable.

Secrets in KV must use encryption. See the KV store section in the Builder Guide.

Platform and External APIs ​

Apps talk to Cribl through the documented OpenAPI surface:

  • You call Cribl APIs via the base URLs and authentication model defined in the OpenAPI specification and API Reference.
  • You use these APIs to work with resources such as Worker Groups, Pipelines, Sources, Destinations, KV, and Settings.
  • You design with backwards compatibility and rate limits in mind, just as you would for any external integration.

Apps can also call external APIs (for example, third-party services), but must follow the same packaging, proxy, and security rules described in the Builder Guide. Use Cribl APIs for anything that touches Cribl data or configuration, and reserve external calls for integrations that truly live outside Cribl.

The App Platform (Preview) runtime does not ship with built-in large language models (LLMs) or other background AI. What runs in Cribl depends on each packaged App: documented Cribl APIs, KV, and any outbound hosts declared in proxies.yml. Agent-assisted coding on your workstation only helps you author the bundle. Execution still follows the sandbox, proxy, and API rules in the Builder Guide.

When an administrator imports a package, Cribl runs a pre-install check and requires Review app’s file contents whenever outbound or flagged content triggers it. That step surfaces declared endpoints and LLM-related outbound calls when present. See Install an App in the Admin Guide.