Docs / Quickstart

Quickstart

Zero to your first audited action in about five minutes. You'll install the runner on a Linux host, watch it connect, run linux.uptime — gated by policy, recorded in the audit trail — and then point your LLM at the same catalog.

1 · Create your account

Sign up at /sign_up. Free covers 3 runners and 1 user — no credit card.

2 · Install the runner

In the dashboard, click Connect a runner. emisar shows a one-line command carrying a single-use enrollment key (emkey-auth-…, shown once — copy it now). Run it on your host:

$ curl -sSL https://emisar.dev/install.sh \
    | sudo EMISAR_AUTH_KEY=emkey-auth-… EMISAR_URL=https://emisar.dev bash

That leading space keeps the key out of your shell history if you have HISTCONTROL=ignorespace set. It's a plain, readable shell script — read it first if you'd rather. It:

• — verifies the download's SHA-256;
• — creates a dedicated emisar system user and an emisar.service systemd unit (Restart=on-failure);
• — bakes the key and URL into /etc/emisar/runner.env;
• — installs the host-matched starter packs (on a typical Linux + systemd host: linux-core, debugging, and systemd-deep);
• — starts the service, which dials out to the control plane over WSS.

3 · Watch it connect

Refresh the dashboard — your host appears under Runners, online, advertising its action catalog. On the host you can watch the same thing:

$ journalctl -u emisar -f
level=INFO msg="runner online" group=default packs=3 actions=89

The stock linux-core pack is trusted automatically — its bytes match the catalog emisar publishes, so the hash auto-pins as trusted. (A custom or edited pack lands as pending instead and waits for one click on the Packs page before anything can dispatch it. That's the drift guard; you'll meet it the first time you change a pack.)

4 · Run your first action

Open the runner, pick linux.uptime, add the required reason (one line — it's logged), and Dispatch. The output streams back live:

 14:32:07 up 18 days,  4:01,  load average: 0.42, 0.51, 0.48

linux.uptime is low risk, so the default policy runs it on the spot. A high-risk action — killing a process, restarting a service — would stop here for a human approval instead: same flow, one extra click. Either way the run is now in the searchable cloud audit and the runner's hash-chained journal, tagged with your reason.

5 · Point your LLM at it

A runner on its own is just a safer way to click buttons. The payoff is handing the catalog to a model. In the dashboard open LLM agents, pick your client — Claude Code, Claude Desktop, Cursor, Gemini CLI, Codex CLI, or remote MCP for Claude.ai and ChatGPT — and emisar mints a scoped API key with a prefilled config snippet to paste in.

Now your model sees the same catalog as typed tools, scoped to the runners you allow. Ask it "what's the load on web-01?" and it calls linux.uptime; ask it to restart a service and that high-risk action stops for your approval. Reads run on policy, mutations are gated, every call is audited — and the model never gets a shell. Full walkthrough: /docs/connect-an-llm .

6 · The workflow we recommend

emisar is built for the incident, not the steady state. Use it to investigate fast — let the agent work down the layers through declared, audited reads — and to hot-patch when you have to stop the bleed: a gated, one-approval action that buys you time. What it is not is your configuration manager. Standing changes an agent makes on a live host are how you get drift nobody can reproduce.

So the durable pattern — the one we'd actually recommend — pairs the agent with your infrastructure-as-code:

1. The agent investigates through emisar and finds the root cause — reads run on policy, so this part is unattended and on the record.
2. If it's on fire, it hot-patches through one gated action to contain it — approved by a human, audited.
3. Then it writes the durable fix as code — Terraform, Ansible, a Kubernetes manifest, whatever your fleet runs — and hands you a change you review and apply through your normal pipeline.

Imperative containment, declarative cure: stop the incident now through emisar, codify the cure in IaC you review. The agent never becomes the source of truth for your infrastructure — your repo stays that. See it end to end on a real incident: the 33-hour wipe — investigated through declared actions, contained behind one approval, then fixed in a Terraform PR the agent wrote.