Skip to main content
Automations are background agents that run in the cloud. They combine AI prompts with deterministic commands to deliver merge-ready pull requests — triggered manually, on a schedule, on pull request events, or via webhooks. Automations page
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. Automation execution dashboard For how Automations fit into the broader platform, see Core Components.

Runs in the cloud

Automations run in the background. 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, Granola, 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

Get started with a template or build your own from scratch. 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. 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.

FAQ

No. Automation environments are isolated execution contexts, not interactive environments.
Test on one or a few repositories first. Review results, adjust steps, then scale up gradually.
Projects: repetitive tasks on known repositories, pull request triggers.Repositories: large-scale migrations across thousands of repos, fine-grained selection.
Always in your Dev Container configuration. Packages are then available for all steps, pre-installed for faster runs.
Configure MCP integrations in Settings > Integrations. These are then available to your Automations.
Yes. Disable it from the three-dot menu in the list or the toggle on the details page. Disabled Automations retain their configuration and history but won’t start new runs. See Enable and disable.