Overview

Proactive background agents that combine AI prompts with deterministic commands in trigger-based, closed-loop workflows.

Automations are proactive background agents running in the cloud. They combine AI prompts with deterministic commands in trigger-based, closed-loop workflows that deliver merge-ready pull requests.

Each Automation defines when to run (manually, on a schedule, on pull request events, or via webhooks), what to operate on (configured projects, single repositories, or a fuzzy match across your GitHub or GitLab org), and what work to do using custom sequences of prompts and commands with your own CLI tools.

Automations work best with projects. A project provides the Dev Container configuration, pre-installed dependencies, and environment settings that every Automation run uses. Set up a project first, then build Automations on top of it.

How Automations work

Every Automation follows a closed-loop workflow:

1. Trigger: run manually, on PR events, on a schedule, or via webhook.
2. Execute: Ona clones, branches, installs, builds, tests, iterates, commits, pushes, and opens a PR. The same loop a human engineer runs, except Automations can do it across hundreds of repos in parallel.
3. Review: inspect outputs, logs, and linked PRs. Approve and merge when satisfied.

Every Automation runs in a fully configured environment defined by devcontainer.json and automations.yaml. Dependencies install, services start, tools are available. Not a minimal CI runner, but a full development environment.

For how Automations fit into the broader platform, see Core Components.

Runs in the cloud

Automations run in the background in the cloud. Your laptop does not need to be on. Review results from your phone or iPad.

On Ona Cloud, execution happens in Ona’s infrastructure. Enterprise customers can run Ona in their own network (AWS, GCP), giving Automations the same connectivity and context your engineers have: query databases, hit internal APIs, run the full test suite against staging without tunnels or exported secrets.

Integrations

Ona has native integrations with Linear, Sentry, Notion, GitHub, GitLab, and Atlassian, giving Automations the same context and permissions your engineers have to read backlogs, triage issues, and open PRs.

Any MCP server can be added as config-in-code via .ona/mcp-config.json in your repository.

Use cases

Autonomous backlog picker

Runs daily. Scans your Linear backlog for well-scoped tickets, picks one up, writes the code, runs CI, and opens a PR. Work that would sit at the bottom of the backlog for months gets done autonomously.

Sentry error triage and fix

Runs daily. Uses Ona’s Sentry integration to triage new issues, fix them, and open PRs. Engineers start their day with bugs already fixed instead of a triage queue.

Codebase cleanup with Knip

Combines a deterministic command (Knip) with the agent. Finds unused JS/TS dependencies, exports, and files. Creates small, reviewable PRs with automerge enabled. Keeps the codebase clean and context windows tight.

CVE remediation with Snyk or Aikido

Runs CLIs from Snyk or Aikido against targeted projects. Resolves all found CVEs, reruns the scan until clean, and creates standardized PRs. Schedule for off-hours, review clean PRs the next morning.

Migrations at scale

Batch repos on a schedule (e.g., 10 every Sunday night). Creates incremental, reviewable PRs. Examples: CI pipeline migration, Java version upgrades, JS to TS conversion.

See Automations in practice for detailed setup guides for each use case.

Access

Automations are available on Core and Enterprise plans with plan-based limits on the number of Automations, concurrent actions, and features like webhooks. Enterprise organizations require Ona Intelligence.

Organization admins can share Automations with individual users and groups, allowing team members to run pre-built Automations without admin privileges.

Related: Tasks and Services

Automations run across repositories at scale. For per-environment automation (database seeding, server startup, test commands), see Tasks and Services. Tasks and Services are configured in automations.yaml and run within individual environments.

Next steps

• Create your first Automation
• Automations in practice for real-world examples

FAQ

Can I see Automation environments in the sidebar?

No. Automation environments are isolated execution contexts, not interactive environments.

How should I iterate on an Automation?

Test on one or a few repositories first. Review results, adjust steps, then scale up gradually.

Projects vs repositories: when to use which?

Projects: repetitive tasks on known repositories, pull request triggers.

Repositories: large-scale migrations across thousands of repos, fine-grained selection.

Where should I install packages?

Always in your Dev Container configuration. Packages are then available for all steps, pre-installed for faster runs.

How do I integrate with external systems?

Configure MCP integrations in Settings > Integrations. These are then available to your Automations.