Skip to main content
This page covers guardrails specific to Automations. For general Ona Guardrails (policies, SSO, audit logs), see Ona Guardrails.
Guardrails provide safety controls and policies that govern how automations execute across your organization. They ensure automations run securely, predictably, and within defined boundaries.

​
What are automation guardrails

Automation guardrails are security and operational controls that protect your codebase and infrastructure while automations execute at scale. They include:
  • Environment isolation - Automations run in isolated environments with controlled access
  • Command restrictions - Deny lists prevent execution of dangerous or unauthorized commands
  • Audit trails - Complete logging of all automation activity for compliance and debugging
  • Concurrency limits - Controls on parallel execution to manage costs and resources
  • Access controls - Service account permissions and organizational policies
These guardrails work together to ensure automations can execute powerful changes safely across hundreds or thousands of repositories.

​
Environment isolation

Each automation runs in an isolated Ona Environment with dedicated resources and no access to other automations or user environments. This prevents interference, maintains security boundaries, and ensures proper resource allocation. Learn more about Ona Environments.

​
Command deny lists

Command deny lists prevent automations from executing dangerous or unauthorized commands. When an automation attempts a blocked command, it fails immediately with an error. Common deny list rules:
  • Block sudo and destructive operations (rm -rf /)
  • Block cloud CLI tools (aws, gcloud, az)
  • Restrict system modifications
Configure deny lists at the organization level to enforce consistent policies across all automations. Learn more about Command Deny Lists.

​
Audit logging

Every automation execution is fully logged, including commands executed, files modified, pull requests created, and errors. Use audit logs to track activity, debug failures, and demonstrate compliance. Audit logs are retained according to your organization’s retention policy and accessible to administrators. Learn more about Audit Logs.

​
Concurrency limits

Concurrency limits control how many actions run simultaneously and in total. These limits prevent resource exhaustion and manage infrastructure costs.

​
What are concurrency limits

Two types of limits control automation execution:
  • Max concurrent executions - Maximum actions running at the same time
  • Max total executions - Maximum total executions allowed for a single automation run
Why concurrency limits matter: Cost control: Running 1,000 automations simultaneously consumes significant infrastructure resources. Limits prevent unexpected cost spikes. Resource management: Your infrastructure has finite capacity. Limits ensure automations don’t overwhelm systems or impact other work. Gradual rollout: Test automations on a small scale before running across your entire repository base. The max concurrent executions limit controls how many repositories are processed in parallel, allowing you to start small and scale gradually as you gain confidence. Error containment: If an automation has a bug, limits prevent it from affecting thousands of repositories before you can intervene.

​
Default limits

Automations use these defaults unless you configure custom values:
  • Max concurrent actions: 10 - Up to 10 automations run in parallel
  • Max total actions: 100 - Up to 100 repositories processed per automation run
These defaults work well for:
  • Team-level automations (10-50 repositories)
  • Testing and validation
  • Regular maintenance tasks

​
Configuring limits per automation

Adjust limits when creating or editing an automation:
  1. Open the automation configuration
  2. Set Max concurrent actions (1-50 recommended)
  3. Set Max total actions (10-1000+ depending on scale)
  4. Save the automation
Recommended approach:
  1. Start small: Test with 5-10 repositories first to validate your automation works correctly
  2. Scale gradually: Increase to 50-100 repositories after successful validation
  3. Use the 1:10 ratio: Set concurrent executions to roughly 1/10 of your total (e.g., 10 concurrent for 100 total)
  4. Contact us for large scale: Planning to run on 1000+ repositories? Contact your account manager first to ensure optimal configuration and a great experience
Example scaling path:
  • Initial test: 5 concurrent, 10 total
  • Team validation: 10 concurrent, 100 total
  • Department rollout: 20 concurrent, 200 total
  • Large-scale (contact us first): Custom configuration for 1000+ repositories

​
Queue behavior when limits are reached

When an automation reaches its concurrency limit:
  1. Additional executions wait in a queue
  2. As running executions complete, queued executions start
  3. The automation continues until all targets are processed or the total limit is reached
When the total execution limit is reached:
  1. The automation stops processing new targets
  2. Running executions complete normally
  3. You receive a notification that the limit was reached
  4. Increase limits and re-run if needed to process remaining targets
Example: Automation configured for 10 concurrent, 100 total across 500 repositories:
  • First 10 repositories start immediately
  • As each completes, the next repository starts
  • After 100 repositories, the automation stops
  • Remaining 400 repositories require a second run with adjusted limits

​
Monitoring concurrent executions

Track automation execution in real-time:
  1. Navigate to Automations in the left panel
  2. Click on the running automation
  3. View execution status:
    • Currently running (concurrent count)
    • Completed successfully
    • Failed
    • Queued (waiting for capacity)
    • Total processed
Use this information to:
  • Verify automations are progressing
  • Identify if limits are too restrictive
  • Spot failures early
  • Adjust limits for future runs

​
Next steps