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, because the defaults are already strict (policies & approvals lists 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 act on 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.

The pages under Deploy on cover installing runners on a host, in a container, or on a Kubernetes or Nomad node.

  • — Group by tier, not by host. A group is what policy, runbooks, member scopes, and agents all target. Name it for a fleet role, such as web, edge, db-prod, or cache, never for 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, such as region=us-east-1, environment=prod, or service=checkout, let you filter and search the fleet without changing your groups. (Policy targets a runner, a group, or the account, never a label.)
  • — 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, and access scoped to the DBAs and their agents.
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 (emergency access) 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, with self-approval off. Approvers get an email with the request.
  4. Scope people and agents. Let each member act only on the runners or groups they own. Their agents inherit the same limit. They can still see the whole workspace inventory. 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 the member's browser access to this workspace and revokes keys issued from that membership, without a 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. The pages under Operate cover the day-to-day signals: connectivity, run states, waiting approvals, pack trust, and poller health.

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 already requires approval, so you need no override.
  • — 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 that denies critical and requires approval for high, 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 covers only the decisions you made on this page. Go through 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 can act only on the hosts they own, and their agent keys inherit that limit.
  • 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, on top of everything in Team, add

  • Configure SCIM so a suspension in your directory ends browser access to this workspace and revokes keys issued from that membership.
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 September 23, 2026