OptiTech Local

Run OptiTech compliance checks locally before they reach CI

OptiTech Local is the local execution mode of the OptiTech CLI. It runs the same checks that gate your pipelines, on your machine, before anything is pushed:

  1. Check your working tree - Evaluate infrastructure code and configuration against your control set while you work, instead of discovering violations in CI.
  2. Test custom checks in a sandbox - Develop and validate custom controls against a sandbox workspace before rolling them out to the live program.

Your CI setup (GitHub Actions, CircleCI, GitLab) stays authoritative; local runs are the fast feedback loop in front of it, the same relationship tests have to CI.

Install the CLI

curl -fsSL https://get.optitech.example.com/cli | bash
optitech --version

Authenticate

Create an API key with the CI checks scope under Settings > API keys, and set it in your environment:

export OPTITECH_API_KEY=<your_api_key>
export OPTITECH_WORKSPACE_ID=<your_workspace_id>

The key can run checks and read the controls they map to, nothing else. Local runs are attributed to the key in the audit log, like every other API action.

Run checks locally

Evaluate the current working tree against your mapped controls:

optitech checks run --local

Check a Terraform plan before applying it:

terraform plan -out=tfplan
terraform show -json tfplan > tfplan.json
optitech checks run --local --plan-file tfplan.json

Scope to specific paths, the same way as in CI for monorepos:

optitech checks run --local --paths 'infrastructure/**,services/payments/**'

Local runs are advisory by definition: they report, and nothing is blocked except by your own workflow. Results are printed per control, with the failing values and the control reference.

Watch mode

For an editing session on infrastructure code, watch mode re-runs affected checks on file save:

optitech checks watch --paths 'infrastructure/**'

Pair it with the VS Code extension if you'd rather see results inline in the editor than in a terminal.

Pre-commit hook

To catch violations before they're even committed:

optitech hooks install pre-commit

The hook runs the scoped checks against staged files. Keep it fast: hook runs use the same --paths scoping as CI, and slow checks (full cloud sweeps) belong in CI and scheduled runs, not in a commit hook.

Sandbox workspaces for check development

When developing a custom control, test its check logic against a sandbox workspace instead of your live program:

optitech checks test ./checks/prod-access-ticket.yaml --workspace sandbox

The sandbox run shows what the check would flag, without opening findings anywhere. Promote the control to the live workspace when the results look right, through the reviewed change process.

Configuration options

VariableDescriptionRequiredDefault
OPTITECH_API_KEYAPI key with the CI checks scope.YesN/A
OPTITECH_WORKSPACE_IDThe workspace whose controls are evaluated.YesN/A
OPTITECH_PROFILENamed profile from ~/.optitech/config for multi-workspace setups (MSPs, per-entity workspaces).Nodefault
OPTITECH_CHECKS_MODEadvisory locally; blocking is only meaningful in CI.Noadvisory

Configuration can also live in an optitech.toml at the repository root, which is the recommended way to pin --paths scoping so local runs, hooks, and CI evaluate the same surface.

Need help?

Join our Discord Server to ask questions or see what others are doing with OptiTech. For paid plan support options, see Support.

Was this page helpful?