Skip to main content
emisar
Docs navigation

Get started

Go to production

The quickstart installed one runner on one host. Production adds many hosts, real consequences, and a security review that asks exactly how emisar stops an unsafe call.

None of this needs much configuration — the defaults are already conservative (policies & approvals states them). Going to production is mostly deciding where to tighten, and doing it once.

The shape of a production fleet#

Make two decisions first: how to group runners, and which people can reach each group. An agent key inherits its owner's scope, so when you limit a person you limit their agents too. Everything else on this page builds on these two decisions.

Installing runners — on a host, in a container, on a Kubernetes or Nomad node — has its own pages under Deploy on.

  • — Group by tier, not by host. A group is what policy, runbooks, member scopes, and agents all target. Name it for a fleet role — web, edge, db-prod, cache — never one machine. The installer defaults the group to the hostname; change it before you add a second host. web-01 is a label, not a group.
  • — Labels for everything else. Free-form key=value pairs — region=us-east-1, environment=prod, service=checkout — for filtering and searching the fleet without redrawing your groups. (Policy targets a runner, a group, or the account — not labels.)
  • — Keep policy and access aligned. Policy controls what a runner runs; access controls who reaches it. A locked database tier gets both — a strict ruleset, scoped to the DBAs and their agents.

Use this example to shape your runner fleet:

web
Ten hosts use nginx, linux-core, and debugging. Policy allows reads and requires one approval for a restart.
db-prod
Three hosts use postgres and linux-core. A targeted ruleset denies critical and requires two approvals for high. Scope only the DBA team.
staging
Two hosts use the full catalog, including the shell break-glass pack. Its looser policy lets an agent iterate on a fix, and it cannot reach a production host.

Roll out in phases#

Each phase is reversible and safe to stop after. No phase leaves the fleet more open than the previous one.

  1. Pilot on one non-prod host. Install, watch it connect, run a read, then open the row from Audit. Prove the whole path before it touches anything that matters.
  2. Configure the policy. Decide what each risk tier can do across the fleet. Keep policy strict where an action can take something down, and relax it only after an explicit decision. See policies & approvals.
  3. Add approvals where they matter. For anything that can drop a service or lose data, turn on four-eyes — two different approvers, self-approval off. Approvers get an email with the request.
  4. Scope people and agents. Give each member only the runners or groups they own — their agents' keys carry the same limit. Out-of-scope hosts are invisible to them. See per-member runner scopes.
  5. Lock the sensitive groups. Add a targeted ruleset for your production tiers. The db-prod group can deny critical and require two approvals for high. The rest of the fleet can keep the default.
  6. Connect identity. Require MFA account-wide. Add SSO so people sign in through your identity provider. Only available on Team & Enterprise. Add SCIM so a suspension in your directory ends sessions and revokes keys in emisar — no manual checklist. Only available on Enterprise.
  7. Connect your SIEM. Mint an audit-export token — the export is a pull API, so configure a collector to poll the NDJSON endpoint. See audit & SIEM. Only available on Team & Enterprise.

Before widening the rollout, prove the whole path once: run one low-risk read-only action on one non-critical runner, confirm it succeeds and appears in run history, and confirm your collector sends it to the SIEM. Repeat that check after every runner upgrade and pack rollout. Day-to-day signals — connectivity, run states, waiting approvals, pack trust, poller health — live with their owner pages under Operate.

Two worked examples#

An AI agent that reads the web tier and restarts behind approval

Goal: Let the incident agent investigate nginx without waiting. Require a person to approve each restart.

  • — Fleet: the ten web hosts share group web, packs nginx + linux-core + debugging.
  • — Policy: The defaults already fit. Low-risk and medium-risk log or status reads run immediately. The high-risk linux.systemctl_restart action requires approval — no override needed.
  • — Access: Scope the operator to the web group — they cannot reach another tier, and their agent key inherits the same scope.

Result: The agent runs nginx.error_tail immediately. A linux.systemctl_restart call waits for the on-call operator. The operator sees the host, exact arguments, and agent reason before approval. Each completed or gated run records its client, key, and reason in the audit.

A destructive action on db-prod, done safely

Goal: Allow terminating a stuck Postgres backend on db-prod only after two people approve.

  • — Fleet: group db-prod, three hosts, packs postgres + linux-core.
  • — Policy + approvals: a targeted ruleset for the group — critical denied, high require approval — with four-eyes on: two approvers, self-approval off.

The flow: A DBA agent calls postgres.terminate_backend with a reason. Policy holds the run for approval. Two other operators approve it. Because self-approval is off, the requester cannot be one of them. The runner executes the approved run. The audit records the requester, both approvers, and redacted command. No one drops a db-prod connection alone, and every step is recorded.

Go-live checklist#

The defaults ship safe, so this list is only the decisions you made on this page — walk it before you point production at emisar. A security reviewer will ask for the same things:

Every account

  • Group runners by tier. Give every production group its own locked ruleset.
  • Four-eyes is on for any group that can lose data or drop a service.
  • Members are scoped to the hosts they own — agent keys inherit that scope, so nothing is account-wide by accident.
  • Require MFA account-wide.
  • Pack secrets live in runner.env + inherit_env, never in call arguments.
  • The shell break-glass pack is on no production runner.
  • Signed dispatch is enforced wherever you must be able to prove which bridge sent a request. A customer-authorized bridge signs each request with a key the control plane never holds. See Signed dispatch.

On Team, add

  • Configure SSO so people sign in through your identity provider.
  • Poll the audit export API with an audit-export token. Confirm that its cursor advances. Alert on policy changes and admission blocks.

On Enterprise, add — on top of everything in Team

  • Configure SCIM so a suspension in your directory ends sessions and revokes keys in emisar.
On Enterprise, you have help with this
Enterprise includes a security and procurement review, a fleet-specific rollout plan, and design-partner support. Tell us what you run, and we can help you deploy it. See plans or email sales@emisar.dev.

← Previous

Manage the runner fleet

Next →

Upgrade runners

Last reviewed August 4, 2026