This reference summarizes how Apps handles execution boundaries, credentials, outbound traffic, and role separation between authoring and deployment. It complements the procedural guides:

• Build, package, and integrate APIs: Builder Guide.
• Publish an App and pursue certification: Publish an App to the Cribl Marketplace and Certify an App.
• Install checks, KV administration, and governance: Admin Guide.

Where App Code Runs ​

App UI ​

After an administrator installs a package, Cribl delivers the App UI (HTML, JavaScript, and assets) to the member’s browser and renders it inside an isolated iframe. Client-side logic runs in that iframe. The Cribl product shell owns navigation and chrome outside the iframe.

For iframe restrictions (storage, cookies, and similar), see Runtime Model and Sandbox in the Builder Guide.

Backend Functions ​

Apps can also declare backend functions, which Cribl deploys to Cribl-managed compute and runs outside the browser. Cribl invokes only functions declared in the package, including scheduled invocations that POST to the same handler. For the authoring contract, see Backend Functions in the Builder Guide. For deployment status and recovery, see Backend Deployment Status in the Admin Guide.

Live Preview (Development) ​

During Live Preview, the iframe loads your App from a local development server on the builder’s machine (often a loopback URL). The same Cribl session still mediates Cribl API calls and KV access through the platform proxies. Only the static UI bundle is served locally. Browser and OS permissions for local network access apply. See Browser Permissions for Live Preview in the Quick Start.

Cribl APIs and Identity ​

App UI Calls ​

From App UI code, you call Cribl REST endpoints with fetch() using relative URLs. Cribl intercepts those requests, attaches the signed-in member’s authentication context, and enforces authorization.

Product RBAC applies to general Cribl API calls from the App UI. The signed-in member’s Stream, Edge, Search, and Lake roles and Workspace assignments are enforced as they are in the main Cribl UI.

For each installed App, Cribl also enforces the App user grant configured in the sharing UI. That grant controls whether the member may load the App UI, use that App’s KV and proxy paths, and invoke its backend functions. It does not grant blanket access to unrelated Cribl resources.

When the App bundle declares additional in-product API permissions the experience needs (for example in policies.yml), those declarations are part of administrator review at install and upgrade. If the author omits declarations, each call still follows only that signed-in member’s normal product permissions.

Backend Function Calls ​

Backend functions do not impersonate the member who invoked them. Cribl authorizes their API calls with the installed App’s grants from policies.yml, plus access to the App’s own KV and proxy paths. These grants apply to every backend function the App declares, including scheduled invocations.

The handler’s context.caller.userId identifies the invoking member for attribution. It does not give the function that member’s roles or permissions.

For who assigns access and how sharing works, see Share Access to Installed Apps in the Admin Guide. For how App user interacts with product APIs, see App User Grants and Product APIs in the Admin Guide. For error-handling patterns in App code, see Permissions and Access in the Builder Guide.

Credentials and the KV Store ​

• Store API keys, tokens, passwords, and other secrets in the Apps KV store with the query parameter encrypted=true on writes. Encrypted values are write-only from the browser: reads return a redacted placeholder, so secrets are not exposed to App JavaScript or the network in clear text from KV reads.
• Plain (unencrypted) KV values are visible in contexts that can call the KV API for that App. Do not use them for sensitive material. See The KV Store in the Builder Guide.
• Organization Administrators can seed or edit keys from App Settings > Key-Value Stores. Treat that surface as part of your credential lifecycle and least-privilege model.

Outbound HTTP and proxies.yml ​

Calls to external hosts from App UI or backend function code use fetch() with full URLs. Cribl routes them through a server-side proxy that:

• Allows only hosts, paths, and options in the App’s effective configuration: the hosts packaged in proxies.yml plus the hosts an administrator authorized on App Settings > External API Access. App code cannot widen that list.
• Applies SSRF protections and declared timeouts.
• Can inject headers (for example Authorization) from encrypted KV using expressions resolved on the server, so tokens do not need to live in client code. Sensitive headers set only from App code are not a substitute for headers.inject. See External APIs and proxies.yml in the Builder Guide.

Administrators review declared hosts during install or upgrade, and can authorize additional hosts afterward. See Review App Capabilities and External API Access Tab in the Admin Guide.

Third-Party Services and AI ​

Apps does not ship a built-in large language model (LLM) or background AI runtime. If an App calls an external model or SaaS API, that appears as normal proxied outbound HTTP subject to proxies.yml and administrator review. AI-assisted authoring on a developer workstation only produces the bundle. It does not change execution rules in Cribl.

Certified Apps that use AI have additional disclosure and data-handling requirements. See Responsible Use of AI.

Packaging and Install-Time Checks ​

Distributable Apps are .tgz archives with validated layout, size limits, and safe extraction rules (for example blocked symlinks and path traversals). See Install an App and Validation Checks in the Admin Guide.

Roles: Authoring Versus Deployment ​

• Workspace Administrator in a Workspace is sufficient to use Create App, Live Preview, and Deploy from Live Preview in that Workspace. That role is scoped to the Workspace. It is not the same as Organization-wide Administrator.
• Organization Administrator (the Administrator role in the Admin Guide) installs, upgrades, and removes Apps and manages App Settings across the Organization’s policy.

A recommended pattern for enterprises is a dedicated development Workspace where builders are Workspace Administrators. Use separate staging and production Workspaces where an Administrator imports the same versioned package when you promote. See Multiple App Builders in Your Organization and Development and Release Workflow for Customer Apps in the Admin Guide.

Observability ​

Cribl logs structured events for App-originated API and proxy traffic. It writes backend function console output to app-backend.log with the App ID, function name, and invocation ID. Administrators can correlate activity using these identifiers and documented log fields. See Monitoring, Logging, and Auditing in the Admin Guide. For aligning App UI requests with browser Network traffic during pre-production validation, see Observe API and Proxy Traffic During Validation in the Admin Guide.