Runbook automation in TypeScript or Python, with approvals

ShiftLabs runs your runbooks as workflows written in TypeScript or Python. Each step is saved as it finishes, so a run picks up where it stopped. Commands run on a runner inside your network. A step that changes production waits for a person to approve it, in the dashboard or in Slack.

Start free · Read the runbook docs

How a runbook run works

A trigger starts the run.
A webhook, a schedule, Run now in the dashboard, the API, or an agent's tool call.
Steps do the work.
step.run calls an API. step.exec runs a command on your runner. Steps retry on failure.
A person approves the risky step.
step.waitForApproval holds the run until an approver answers. Nobody answers in 72 hours by default, and the request counts as denied.
The run records what happened.
Each step, command output, approval and outbound request shows on the run.

A runbook in code

This workflow lists the pods, asks an admin, then restarts a deployment. Both commands run on your runner.

TypeScript

import { workflow } from "shiftlabs";

export default workflow<{ deployment: string }>(async ({ payload, step }) => {
  await step.exec("list pods", { command: ["kubectl", "get", "pods", "-n", "apps"] });
  const decision = await step.waitForApproval("restart", {
    message: `Restart ${payload.deployment}?`,
    approvers: ["role:admin"],
  });
  if (!decision.approved) return { restarted: false, note: decision.note };
  await step.exec("restart", {
    command: ["kubectl", "rollout", "restart", `deployment/${payload.deployment}`, "-n", "apps"],
  });
  return { restarted: true };
});

The same workflow can be written in Python with ctx.step.exec and ctx.step.wait_for_approval. See Workflows.

Commands run inside your network

ShiftLabs is hosted. The runner is the one part you run.

Outbound only.
The runner calls https://api.shiftlabs.org and waits for work. It needs no inbound port, load balancer or public address.
Your credentials stay with you.
Commands use the kubeconfig or cloud role you give the runner. ShiftLabs never sees the runner's own credentials.
Limited to named workflows.
A runner token can name the workflows it serves.
Docker or Kubernetes.
The runner image is on Docker Hub for amd64 and arm64. See Docker and Kubernetes.

Approvals in the dashboard or in Slack

Approvers are role:admin, role:manager or members' emails, up to 20. A developer never approves.
A request can need 1 to 5 different approvers.
Connect Slack in Settings → Approvals, and requests arrive with Approve and Deny buttons. Each approver links their own Slack account once.
The approver can write a note. The workflow reads it with the answer.

See Approve in Slack.

Schedules

A schedule starts a workflow on a cron, in your time zone, such as 0 3 * * * in America/Detroit. Schedules deploy with your workflows. See Schedules.

Runbooks in GitHub Actions

The github-actions-runbook template starts a script in your repository's GitHub Actions after an approver says yes, then waits for its signed result. The credentials your script uses stay in GitHub. See Run tools in GitHub Actions.

Limits

	Free	Pro
Price	$0, no card	$49 a month
Runs	1,000 a day	250,000 a month included
Runs at once	10	100
Runner tokens	2	20
Longest command	30 minutes	12 hours
Commands waiting for a runner	20	500

Commands run on your machines, so they use no CPU time or outbound requests of your plan. Every limit is on Pricing.

Not a fit yet

Runs execute in US regions only.
ShiftLabs is hosted. Only the runner runs on your side.

Start with one runbook

Pick the runbook your team runs most by hand. Write the read-only steps first, then put the change behind an approval.

Start free · See the templates