Deployments

A deployment is a graph reachable from outside under its own credentials, with its own limits. It is not infrastructure: it is a row that says which graph answers, with which keys, how much, and to whom. One per person, for now.

Two keys

Like Stripe or Intercom, a deployment has two keys:

• The public key (chy_pk_…) lives in a web page. It can only open a conversation, it is rate-limited, and it only works from the origins you list on the deployment. It travels over the browser door, a WebSocket, in the first message.
• The secret (chy_sk_…) is for your servers, over the HTTP door. It is shown once when you create or rotate the deployment; keep it where you keep keys.

Rotating replaces both at once.

Awake and asleep

A deployment is born asleep. The first message wakes it, if fewer than the installation’s ceiling are awake at that moment (otherwise the caller is told to try again in a minute); after the idle minutes you set without anybody talking, it goes back to sleep. Paused is your switch: nobody gets in until you resume.

Visitors are chats

Each visitor gets a session and a chat of yours, bound to the graph, so the graph’s memory strategies apply exactly as they do in the product. The visitor id is minted by the server on the first message and echoed back; the widget keeps it in the browser so the conversation keeps its thread. Those sessions do not show in your chat list. Nobody gets an account for talking to a widget.

The version it runs

By default a deployment runs the tip of its graph: every save you make in the Studio goes live to whoever is chatting right then. The card lets you pin a version instead, and from that moment the door keeps serving that version however much you move the graph — which is what you want once real people are on the other side.

Pick the tip again to unpin it. A graph with no versions yet only offers the tip: commit one in the Studio and it shows up here.

If a pinned version stops being readable — you deleted it — the door does not go quiet: it falls back to the live graph and says so in the log. Not answering is worse than answering with today’s graph.

Limits

Per deployment: conversations answered at once, messages per visitor per hour, messages per day, minutes without anybody before sleeping, and the length of a message. Every conversation runs on your behalf, with your workspace’s models and keys, so what a deployment spends is yours.

Embedding the chat

Two lines, no build step:

<script type="module" src="https://cdn.jsdelivr.net/npm/@chatty-lab/chat@0/src/index.js"></script>
<chatty-chat endpoint="wss://…/ws/deployments/<id>" key="chy_pk_…"></chatty-chat>

The element shows only the answer; add progress to list the graph’s nodes as they run, theme="dark" for dark colours, heading and placeholder for the words. It fires chatty-send and chatty-reply, which bubble out of the shadow root. For your own UI, import { createDeploymentClient } from '@chatty-lab/chat/client'.

The HTTP door

POST https://…/api/deployments/<id>/chat
Authorization: Bearer chy_sk_…
{ "input": "Hello", "visitor": "<id from a previous reply, optional>" }
→ { "visitor": "…", "output": "…", "run_id": "…", "chat_id": "…" }

Schedules and hooks

Below the deployment, What runs on its own holds the schedules and doorbells of any graph in the workspace — pick it in the selector; it does not have to be the one deployed. They live here because a deployment, a schedule and a doorbell are the three ways a graph goes out into the world without someone pressing run.