Get started
The quickest useful introduction to Cheetah is one complete exchange: start a small server, connect a client, ask that client to perform a named action, and inspect the returned result. That path crosses the same responsibility boundaries used by a larger system, without first requiring Redis, several services, or a browser extension.
This section uses the maintained console-client example because it is deterministic and easy to inspect. The client action returns information rather than changing an external system. Once the exchange is clear, the same model can be applied to a browser, cooperative web page, or custom client.
What you will prove
The first connected action exercises more than socket connectivity:
- one host creates the application, WebSocket, and returned-data roles from a coherent in-memory component set;
- a console runtime authenticates, declares its stable client identity, and becomes present;
- application code addresses that client and submits a named command;
- the current client instance receives the command and selects a registered handler;
- the handler returns a terminal result through authenticated HTTP ingestion;
- correlation wakes the waiting application code, while history retains the full response;
- both client and server shut down and release their listeners.
That is intentionally a small deployment, not a simplified protocol. Delivery, execution, return, correlation, and history retain their separate meanings even though all server roles share one process.
The path through this section
Prepare the source checkout explains the supported prerequisites and the repository bootstrap. It distinguishes core setup from the larger example products so you can install only what this proof needs.
Run a connected action executes the maintained proof and shows how to interpret its output. It also gives boundary-by-boundary troubleshooting rather than treating every failure as a generic connection problem.
Grow from the first proof explains what can remain stable as you replace the example action, add a browser, separate server roles, introduce persistence, or serve several users.
What the example does not claim
The first run uses localhost, explicit insecure-development transport, a fixed development credential, and in-memory state. It proves the functional path. It is not evidence that TLS, identity integration, durable storage, multi-process coordination, monitoring, backups, or incident response have been configured.
This distinction is useful. A small example should expose the real application model without quietly presenting development settings as a production recipe.
Keep the source and deployment boundaries visible
Cheetah is a framework embedded in a product. The repository includes libraries, client packages, UI components, optional facilities, and runnable example products. The bootstrap prepares those artifacts; it does not create a hosted Cheetah account or start a universal control plane.
When you build your own application, product code still owns business authorization, domain state, target selection, and reconciliation of uncertain external effects. Cheetah owns the coordination contracts underneath those choices.