Skip to main content

Overview

Service accounts are non-human identities that run automations independently of individual users. They decouple automation credentials from personal accounts, ensuring workflows continue to function when team members leave or change roles. Automated actions are clearly attributed to the service account, making it easy to distinguish agent activity from human work in commits, pull requests, and audit logs.
This feature is only available on the Enterprise tier. Contact sales to learn more about upgrading.

Accessing Service Accounts

Service accounts are managed from Settings > Members, under the Service Accounts tab. Only organization administrators can create, edit, or delete service accounts. Regular members can view service accounts and select them when configuring automations.

Service accounts list

Creating a Service Account

  1. Navigate to Settings > Members > Service Accounts
  2. Click Create New Service Account
  3. Enter a Name (e.g., “Automation Bot”) and optional Description
  4. Click Create
Service accounts are automatically assigned an expiration date of 1 year from creation.

Create a new service account

Git Authentication

Service accounts need Git authentication to clone repositories, commit changes, and create pull requests. Only PAT-based (Personal Access Token) authentication is supported.

Adding Git Authentication

  1. Open the service account details page
  2. Click Add Git Authentication
  3. Select the environment class where the automation will execute
  4. Choose your Provider (GitHub or GitLab)
  5. Enter a Personal Access Token from your SCM

Git authentication configuration

Creating a Personal Access Token

GitHub:
  1. Go to Settings > Developer settings > Personal access tokens > Tokens (classic)
  2. Click Generate new token
  3. Select scopes: repo, read:user, user:email, workflow
  4. Copy the token
GitHub documentation: Creating a personal access token GitLab:
  1. Go to Preferences > Access Tokens
  2. Enter a name and expiration date
  3. Select scopes: api, read_repository, write_repository
  4. Click Create personal access token
  5. Copy the token
GitLab documentation: Personal access tokens
Store the token securely. You won’t be able to see it again after creation.

Commit Attribution

When a service account commits changes, the Git author email is determined by the account that owns the Personal Access Token. This affects how commits appear in your repository history and audit logs.
  • GitHub: The PAT owner’s primary email address is used for commit attribution
  • GitLab: The PAT owner’s email address is used, but email verification policies may apply (see below)
Organizations with audit or compliance requirements should ensure the PAT is created from an account with an appropriate email address.

Platform-Specific Considerations

GitLab Email Verification Limitation

GitLab service accounts cannot have verified email addresses. If your organization requires verified emails for Git commits, you must use a dedicated real GitLab user account instead of a GitLab service account.
Many organizations enforce policies requiring all Git commits to use verified company domain emails (e.g., @company.com) for security and audit compliance. GitLab’s native service accounts have a limitation that prevents this:
  • GitLab service accounts can have custom email addresses assigned via API
  • However, these emails remain in an unconfirmed state and cannot be verified
  • Service accounts cannot sign in to the GitLab UI to complete email verification
  • Even with a verified domain configured in GitLab, service account emails are not automatically confirmed
This is a known GitLab limitation. Workaround for GitLab users with email verification policies:
  1. Create a dedicated real GitLab user account (e.g., [email protected])
  2. Verify the email address by signing in and completing verification
  3. Generate a Personal Access Token from this dedicated user account
  4. Use this PAT when configuring Git authentication for your Ona service account
This approach gives you the benefits of Ona service accounts (decoupled credentials, clear attribution) while satisfying GitLab’s email verification requirements.

GitHub

GitHub does not have the same email verification restrictions for automated commits. Personal Access Tokens work with any GitHub account type, including machine users and bot accounts.

Using Service Accounts in Automations

When creating or editing an automation, select a service account from the Run as dropdown. The automation will use the service account’s identity and Git credentials for all repository operations. For detailed guidance, see Service Accounts for Automations.

Deleting a Service Account

  1. Navigate to Settings > Members > Service Accounts
  2. Click on the service account name
  3. Click Delete Service Account
  4. Confirm deletion
A service account cannot be deleted if it is currently used by any automation. Update affected automations to use a different executor first.

Next Steps