Examples¶
The fastest way to learn what a Starkite script looks like is to read one that already works. This page catalogs runnable .star scripts from the starkite repository, grouped by the domain they exercise — core automation, Kubernetes, AI agents, and the sandbox. Each entry links to source you can clone and run as-is with kite run <path>, then adapt to your own task. Start with the card that matches what you are trying to do.
-
Core modules
System info, SSH health checks, HTTP servers and clients — the base automation modules.
-
Kubernetes
Deployments, rolling updates, controllers, webhooks, and full app stacks.
-
AI
Agent loops and MCP integration with the
aiandmcpmodules. -
Sandbox
OS-level isolation with
--sandbox(Linux).
Core modules¶
Begin where every script begins: the base modules for talking to the local system, a remote host over SSH, and the network. These examples range from a one-line hello world to a full HTTP server with middleware, so you can pick the one closest to your task and build outward.
| Example | Description |
|---|---|
| hello.star | Hello world |
| sysinfo.star | System information gathering |
| remote-check.star | Remote server health checks via SSH |
| http-server/ | REST APIs, webhooks, middleware |
When you want the concepts behind these rather than the finished scripts, read the Core Modules guides.
Kubernetes¶
Once you are comfortable with the base modules, the k8s module turns those same patterns toward a cluster. The examples below run the full range of cluster work — a single deployment, a zero-downtime rolling update, a reconcile loop, an admission webhook, a complete multi-tier stack — so you can match one to the shape of your own operation.
| Example | Description |
|---|---|
| deploy-k8s | Basic Kubernetes deployment |
| quick-deploy | One-line deployments |
| rolling-update | Zero-downtime rolling updates |
| app-stack | Full application stack |
| namespace-stack | Namespace provisioning |
| multi-env | Multi-environment deployments |
| microservices | Microservices deployment |
| redis-cluster | Redis cluster with Helm |
| wordpress-stack | WordPress + MySQL stack |
| cronjobs | Kubernetes CronJobs |
| cluster-health | Cluster health monitoring |
| debug-pod | Debug pod for troubleshooting |
| controller/ | Controller reconcile loops |
| webhook/ | Validating and mutating admission webhooks |
For the concepts these scripts rest on — connecting to a cluster, applying manifests, watching resources — see the Kubernetes guides.
AI¶
The ai and mcp modules let a script drive a model the same way it drives a cluster. These examples live under aikite/examples/agent/ and walk the common agent shapes — a run-to-completion loop, a human-in-the-loop REPL, history management for long sessions, and wrapping an external tool server over MCP.
| Example | Description |
|---|---|
| autonomous_fix.star | Autonomous run-to-completion agent |
| interactive_assistant.star | User-in-the-loop REPL agent |
| history_management.star | History summarization for long runs |
| mcp_integration.star | Wrapping an MCP server's tools |
To understand the agent and MCP patterns these scripts assemble, read the AI Support guides.
Sandbox¶
When you run code you do not fully trust, the examples above gain a second layer: --sandbox confines the script to OS-level isolation on Linux. These three show that layer in action — a network fetch under the default profile, offline compute over the working directory, and the sandbox composed with a permission profile for defense in depth.
| Example | Description |
|---|---|
| netaccess-http-fetch.star | HTTPS fetch under the default profile |
| opaque-compute.star | Offline compute over $CWD |
| defense-in-depth.star | Compose --sandbox=opaque with --permissions=allow-fs |
The sandbox is Linux-only. For the isolation model and the available profiles, see the Sandbox guide.