Skip to main content
Ona Automations bring together the power of Ona Agent and Ona Environments to execute large-scale changes across your codebase. Handle predictable, repetitive work in isolated environments—giving your team time back to focus on what matters.

​
What are Ona Automations

Automations are end-to-end workflows that execute changes across your codebase—from routine maintenance to large-scale refactoring. They run on demand or trigger automatically from pull requests or schedules. Each automation combines:
  • Steps - Prompts, shell scripts, or pull request steps
  • Integrations - Connections to source control and organizational knowledge
Automations run inside the same production-grade development environments your engineers use. Every execution happens in a fully configured, reproducible environment with your tools, dependencies, and guardrails—completely isolated from your team’s daily work. Automation configuration interface

​
How automations work

  1. Define once - Create an automation with steps
  2. Trigger automatically or on-demand - Can be triggered on a schedule, by Pull Request events, or manual triggers
  3. Execute at scale - Run across selected repositories in parallel
  4. Create pull requests - Automations can open PRs with changes for review
  5. Review and merge - Inspect outputs, logs, and approve changes before they merge

​
Key terms

  • Automation - A workflow definition that executes changes across repositories
  • Execution - A single run of an automation across target repositories
  • Trigger - The event or schedule that starts an automation (manual, pull request, or time-based)
  • Action - The result of running an automation on one repository (one execution can create multiple actions)
  • Step - An individual operation within an automation (prompt, shell script, or PR creation)

​
What automations can do

Automations eliminate coordination bottlenecks for organization-wide initiatives:
  • Apply changes consistently - Execute the same update across hundreds of repositories
  • Run in parallel - Turn weeks of manual work into quick automated execution
  • Maintain visibility - Track every execution with full logs and audit trails
  • Enforce standards - Apply organizational policies and guardrails automatically
  • Integrate with your workflow - Trigger from pull request events or schedules
Automation execution dashboard showing parallel runs

​
Use cases

Automations adapt to different workflows through three trigger types: manual triggers for on-demand execution, pull request triggers for event-driven responses, and schedules for recurring tasks.

​
Manual triggers: README and Backstage YAML maintenance

Create and maintain README files and Backstage YAML configuration across your repository base. Run automations on demand to ensure documentation and metadata stay current without manual toil. Example: Platform team triggers automation → 100 repositories analyzed → READMEs and Backstage YAML updated → Pull requests created for review Why this works: Eliminates documentation toil for engineers while ensuring consistent saturation and standardization across all repositories. Platform teams gain control over documentation quality without manual enforcement.

​
Pull request triggers: Automated security code review

Automatically review code changes for security vulnerabilities. When a pull request is opened or updated, the automation analyzes changes for security issues and posts detailed review comments. Example: Developer opens PR → Automation triggers → Code analyzed for vulnerabilities → Security review comment posted on PR Why this works: Immediate security feedback on every code change without waiting for manual security review.

​
Scheduled triggers: CVE remediation and dependency updates

Automatically detect and remediate security vulnerabilities (CVEs) with complete fixes—including dependency upgrades, API migrations, and verified test runs. Schedule automations to run weekly or monthly, reducing critical vulnerability exposure from days to hours. Example: Weekly scan detects CVE → Automation upgrades dependency and migrates breaking API changes → Tests run and pass → Pull request created with complete remediation Why this works: Reclaim up to 20% of engineering hours spent on CVE remediation toil. Automated fixes handle not just version bumps, but the actual code changes required for successful upgrades.
Customer feedback: “90–95% of work is done by Ona Automations. We just have to do the final push commands.”

​
Prerequisites & access requirements

Automations is available for Enterprise customers. To get access:
  1. Request a demo to learn more about Automations
  2. Work with your account manager to enable Automations for your organization
Once enabled, you’ll be able to create and manage automations through the Ona dashboard.

​
Next steps

Ready to create your first automation? Start with Creating an Automation.

​
Frequently asked questions

Automations use existing Ona Environments to execute the various steps defined in your workflow. Each automation runs inside a fully configured environment with your tools, dependencies, and guardrails.
No. If you run 1,000 automations, you would have 1,000 environments in the sidebar, which would create a poor user experience. We are actively working on improving visibility and management of automation executions.
Not at the moment. Automation environments are isolated execution contexts that run your workflow steps but are not directly accessible for interactive use.
Start by testing your automation on one or a few repositories to validate it works as expected. Once you’re confident in the automation:
  1. Review the results manually
  2. Make any necessary adjustments to steps or configuration
  3. Execute the automation in batches based on your guardrail limits
  4. Scale up gradually to larger repository sets
You can rerun an automation if needed, but testing on a small scale first prevents issues at scale.
Yes, automations can use existing projects if they are available. Projects are a best practice for organizing repositories and reusing those definitions across multiple automations.
Use Projects when:
  • Running repetitive tasks on well-known repositories
  • Repositories are already organized and configured
  • You don’t need to act on thousands of repositories at once
  • Using pull request triggers (projects work better in this context)
Use Repositories when:
  • Performing large-scale migrations across many targets
  • You need to act on thousands of repositories simultaneously
  • You need fine-grained control over specific repository selection
  • Repositories span multiple projects or organizational boundaries
Example: For a large-scale migration affecting 10,000 repositories, use repository targeting with search queries. For routine maintenance on your “Backend Services” project, use project targeting.
Always install packages in your Dev Container configuration. This ensures:
  • Packages are available for all automation steps
  • Consistent environment setup across executions
  • Faster automation runs (packages are pre-installed)
  • Better reproducibility and debugging
Configure integrations through Ona settings using Model Context Protocol (MCP):
  1. Navigate to Settings
  2. Go to Integrations
  3. Configure MCP integrations for external systems (e.g., Notion, Linear)
These integrations are then available to your Dev Containers and automations, allowing Ona Agent to interact with external tools and data sources.