Skip to main content
Everything you do with an app after you’ve read the overview: write it, deploy it, invoke it, watch it, stop it. Install the SDK for your language first.

Create an app

Then define and register an action you want to invoke.

Register actions

Action parameters

Action methods receive two parameters:
  • runtimeContext — contextual information Kernel provides during execution.
  • payload — optional runtime data you provide when invoking the action (max 64 KB). See payload parameter.
Register an action either inline or by defining it first — both are below.

Define then register

This approach is better for larger apps, unit testing, and team collaboration since functions can be tested independently and reused across multiple actions.

Return values

Action methods can return values, which will be included in the invocation’s final response.

Build a browser automation

To implement a browser automation or web agent, instantiate an app and define an action that creates a Kernel browser.
Kernel browsers launch with a default context and page. Make sure to access the existing context and page (contexts()[0] and pages()[0]), rather than trying to create a new one.
Web agent frameworks sometimes require environment variables (e.g. LLM API keys). Set them as environment variables when you deploy.

Deploy your app

There are no configuration files to manage and no CI/CD pipeline to build. Once an app is deployed, you can schedule its actions, run them from other contexts, and run the same action many times in parallel.

From a local directory

Use our CLI from the root directory of your project:
Notes
  • The entrypoint_file_name is the file where you created the app.
  • Include a .gitignore file to exclude dependency folders like node_modules and .venv.

From GitHub

You can deploy a Kernel app directly from a public or private GitHub repository using the Kernel CLI. No need to clone or manually push code.
Notes
  • --path vs --entrypoint: Use --path to specify a subdirectory within the repo (useful for monorepos), and --entrypoint for the path to your app’s entry file relative to that directory (or repo root if no --path is specified).
  • The CLI automatically downloads and extracts the GitHub source code and uploads your app for deployment.
  • For private repositories, provide a --github-token or set the GITHUB_TOKEN environment variable.

Environment variables

You can set environment variables for your app using the --env flag. For example:

Reserved environment variables

Kernel injects a few environment variables into every deployment and its invocations. These names are reserved — if you set them via --env or --env-file, Kernel overrides your value, so setting them has no effect:
  • KERNEL_API_KEY — a per-deployment API key Kernel mints at deploy time (see Deployment API keys). The SDKs read it from the environment by default, so your app authenticates with this key automatically.
  • ENTRYPOINT_RELPATH — set by the platform to locate your entrypoint.
Using a different key for your app’s calls You can’t change KERNEL_API_KEY itself, but you can have your app authenticate with a different key — say a long-lived org- or project-scoped key that outlives any single deployment. Put it in a non-reserved variable and pass it to the client explicitly:
Now the API calls your app makes go out as your key. The deployment key stays in place for Kernel’s own use — running the invocation and reporting its result — so your key only needs permissions for the calls you actually make.

Deployment notes

  • The dependency manifest (package.json for JS/TS, pyproject.toml for Python) must be present in the root directory of your project.
  • For JS/TS apps, set "type": "module" in your package.json.
  • View deployment logs using: kernel deploy logs <deployment_id> --follow
  • If you encounter a 500 error during deployment, verify that your entrypoint file name and extension are correct (e.g., app.py not app or app.js).
  • Kernel assumes the root directory contains at least this file structure:
Once deployed, you can invoke your app from anywhere.

Secrets

There are two ways to get secrets and API keys into your app.

Deployment environment variables

Deploy your app with secrets as environment variables. Your app can then access them at runtime. You can set environment variables in two ways:
  • --env flag: Pass individual key-value pairs directly in the command
  • --env-file flag: Load variables from a .env file
Then access the variables in your app:

Runtime variables

For use cases where different API keys are needed per invocation (such as platforms using end-user keys), pass the secrets at runtime using the payload parameter. Use encryption standards in your app to protect sensitive data.

Invoke an action

Via API

You can invoke your app by making a POST request to Kernel’s API or via the CLI. Both support passing a payload. For automations and agents that take longer than 100 seconds, use async invocations.
Synchronous invocations time out after 100 seconds.

Asynchronous invocations

For long running jobs, use asynchronous invocations to trigger Kernel actions without waiting for the result. You can then stream real-time status updates for the result.
Asynchronous invocations time out after 15 minutes by default but can be configured to last up to 1 hour by setting the optional async_timeout_seconds parameter during invocation.

Via CLI

Invoke an app action immediately via the CLI:

Payload parameter

--payload allows you to invoke the action with specified parameters. This enables your action to receive and handle dynamic inputs at runtime. For example:
Payloads are stringified JSON and have a maximum size of 4.5 MB.
See action parameters for how to read the payload in your action method.

Return values

If your action specifies a return value, the invocation returns its value once it completes. (The Kernel CLI uses asynchronous invocations under the hood)

Monitor an invocation

Once an app is deployed and invoked, monitor it by streaming events for real-time updates or polling for periodic checks.
An invocation ends once its code execution finishes.

Streaming status updates

For real-time status monitoring, use follow to stream invocation events. This provides immediate updates as your invocation progresses and is more efficient than polling.

Example

Here’s an example showing how to handle streaming status updates:
Typescript/Javascript

Polling status updates

Alternatively, you can poll the status endpoint using retrieve to check the invocation status periodically.

Logs

Via API

After you invoke an action, you can stream the invocation’s logs in real time:
Log lines will be truncated to 64KiB. For large payloads write data to external storage and log a reference instead.

Example

Here’s an example showing how to handle streaming logs:
Typescript/Javascript

Via CLI

You can also stream the logs to your terminal via the CLI:
If you don’t specify --follow, the logs will print to the terminal until 3 seconds of inactivity and then stops. You can get logs for a specific invocation by adding:

Stop an invocation

You can terminate a running invocation. This is useful for stopping automations or agents stuck in an infinite loop.
Terminating an invocation also destroys any browsers associated with it.

Via API

You can stop an invocation by setting its status to failed. This will cancel the invocation and mark it as terminated.

Via CLI

Use ctrl-c in the terminal tab where you launched the invocation.