SOC 2 for Self-Hosted Automation: n8n, Airflow, AWX, Jenkins, and Self-Hosted Runners

Self-hosted automation platforms meet SOC 2 the same way any other in-scope system does: the platform goes into scope, and the company shows access control, secrets management, change control, logging, patching, and backup for it, with evidence that matches the policy. SOC 2 is tool-neutral, so self-hosting is allowed. The difference with self-hosting is that the company owns every control the vendor would otherwise cover, and an automation server holds production credentials, so auditors look at it closely.

Does SOC 2 allow self-hosted automation tools?

SOC 2 allows self-hosted automation tools. The AICPA Trust Services Criteria describe what controls must achieve and leave the tooling to the company, so a self-hosted n8n instance, an Airflow cluster, AWX, Jenkins, or a fleet of self-hosted CI runners is acceptable when the controls around it work and produce evidence.

Teams self-host automation for the same reasons they self-host source control: data residency, customer contracts that restrict where data goes, cost at volume, or workflows that need to reach systems on a private network. The guide to SOC 2 secure development with self-hosted GitLab covers those reasons for source control in more detail.

What changes is responsibility. With a SaaS automation tool, the vendor's own SOC 2 report covers the platform's infrastructure, and the company reviews that report as a subservice organization. With self-hosting, the company covers those controls itself: it patches the server, protects the database, rotates the encryption key, and keeps the logs.

Which self-hosted automation systems are in SOC 2 scope?

A self-hosted automation system is in SOC 2 scope when it can read, change, or move anything inside the system boundary: production servers, databases, cloud accounts, customer data, or the deployment path to any of them. In practice that covers most automation platforms, because their job is to act on other systems.

An automation tool used only for internal tasks with no route to production or customer data can sit outside the boundary, as long as the system description says so and the network and credentials back it up. The guide to SOC 2 scoping for hybrid and on-prem infrastructure covers how to draw and document that line.

How do self-hosted automation platforms meet each SOC 2 requirement?

The table maps the control areas auditors test to what a self-hosted automation platform needs, and the evidence that shows it. Cadences are examples; the policy sets the real ones.

Stored credentials are the main SOC 2 risk in self-hosted automation

An automation server stores credentials for the systems it acts on, so whoever controls the server can reach those systems. That makes the credential store the first thing to get right.

Each platform handles this a little differently:

• n8n encrypts stored credentials with an encryption key. The n8n documentation describes setting a custom key through the N8N_ENCRYPTION_KEY environment variable. Keep that key in a secrets manager, out of the image and the repository, and back it up separately from the database.
• Apache Airflow encrypts connection passwords in its metadata database with a Fernet key, and supports external secrets backends such as HashiCorp Vault so credentials never sit in Airflow at all.
• AWX and Ansible Automation Platform store machine and cloud credentials encrypted and let jobs use them without showing them to the user who launches the job.
• Jenkins stores secrets through its credentials system. Pipeline logs mask bound credentials, but scripts can still print them in other ways, so review pipelines that handle secrets.

The control that auditors test is the inventory: a list of every stored credential, what it reaches, the service account behind it, the owner, and the last rotation date. Credentials scoped to one task (a read-only database user for a reporting workflow, a deploy role limited to one environment) shrink the damage if the platform is compromised.

SOC 2 change management for workflows, DAGs, and playbooks

SOC 2 CC8.1 covers changes to infrastructure, data, software, and procedures, and a workflow that moves customer data or deploys code is one of those. Auditors look for the same thing they look for in code: the change was authorized, reviewed, tested where it matters, and recorded.

Platforms that store their logic as code make this straightforward. Airflow DAGs, Ansible playbooks, and Jenkinsfiles live in Git, so the merge or pull request is the change record, the same way it is for application code. The SOC 2 change management guide covers what auditors expect in a ticket.

Visual workflow tools take more planning, because a workflow edited in the browser changes production with no review. Options that work:

1. Separate environments: build and test in a non-production instance, then promote to production through an export kept in Git and reviewed before import.
2. Restricted editing in production: only a small group can edit production workflows, and every edit links to a ticket.
3. Periodic diff review: export production workflows on a schedule, commit them to Git, and review the diff. This catches edits made outside the process.

Check which of these your edition supports. Some features that help here, such as environments, Git integration, SSO, and log streaming, are limited to paid or enterprise editions on some platforms.

Self-hosted CI runners: isolation and the public repository risk

Self-hosted CI runners execute whatever code a pipeline gives them, on hardware the company controls, often inside the private network. That makes isolation the main control.

GitHub's documentation is direct about the risk: self-hosted runners should almost never be used for public repositories, because any user can open a pull request against the repository and compromise the environment. GitHub-hosted runners start from a clean virtual machine for each job; self-hosted runners keep state between jobs unless configured otherwise.

For SOC 2, runner controls usually include:

• Private repositories only for runners that can reach production.
• Ephemeral or rebuilt runners so one job cannot leave anything behind for the next.
• Separate runner groups for production deploys and for general builds, with production runners limited to protected branches.
• Network limits so build runners cannot reach production databases they do not need.
• Patching the runner host and image on the same cycle as other servers.

The CI/CD security guide for SOC 2 covers the security scans that run in those pipelines.

Logging and monitoring for self-hosted automation

SOC 2 CC7.2 requires monitoring system components for anomalies and evaluating whether they are security events. For an automation platform, the useful records are who changed a workflow or credential, which jobs ran, under which account, and what failed.

Most platforms keep job or execution history in their own database, with retention limits that may be shorter than the audit period. n8n, for example, can prune execution data by age through settings such as EXECUTIONS_DATA_PRUNE and EXECUTIONS_DATA_MAX_AGE, described in the n8n execution data documentation. Jenkins records admin and job actions through plugins such as Audit Trail. Whatever the platform, forward admin actions and job logs to the central log store so retention follows the logging policy, not the app's pruning setting.

Alerts worth having: failed logins to the platform, new admin accounts, credential changes, and repeated job failures on production workflows. The SOC 2 logging and SIEM guide for bare metal servers covers log scope, retention, and tooling.

Patching and hardening the automation host

A self-hosted automation platform is a server, a database, and often a container image, and each one needs patching and a configuration standard. Plugins and community nodes count too: they run with the platform's access and can carry their own vulnerabilities.

Record the platform version, the plugin or node list, and the host OS version before and after each update, and tie the update to a change ticket. Keep the management interface off the public internet, behind a VPN, an identity-aware proxy, or a private network. The SOC 2 patch management guide for on-prem servers and the vulnerability scanning guide for on-prem servers cover cadence and tooling.

Evidence checklist for SOC 2 self-hosted automation

The auditor will sample from these. Collect them on the cadence in the policy and file them in the evidence repository with the system name and date. The guide to SOC 2 evidence collection on-prem covers how to script exports and build an evidence calendar.

• System description entry for each automation platform, with its role and what it can reach
• User and role export, with the signed quarterly access review
• Secrets inventory with owner and last rotation date for each credential
• Merge or pull requests for workflow, DAG, playbook, and pipeline changes during the period
• Platform, plugin, and host version records with the patch tickets that changed them
• Vulnerability scan reports for the host and image, with remediation tickets
• Log forwarding configuration, alert rules, and dated log review records
• Backup job records, including the encryption key backup, and the most recent restore test
• Runner configuration showing private-only repository access and separate production runner groups

Practical steps to bring self-hosted automation into SOC 2

1. List every automation platform and runner and what each one can reach. Anything that touches production or customer data goes in the system description.
2. Inventory the stored credentials and replace personal tokens with service accounts that have named owners.
3. Move the encryption key into a secrets manager and back it up separately from the database.
4. Put workflow logic under version control with review before production, or set up environments and periodic diff reviews for visual tools.
5. Connect the platform to SSO where the edition supports it, and remove shared admin accounts.
6. Forward admin and job logs to the central log store and set the alerts listed above.
7. Add the platform to the patch, scan, and backup schedules that already cover other servers.
8. Run a mock sample before the audit window: pick a quarter and confirm the access review, a workflow change record, and a patch record are all there.

If the platform runs on a third party's infrastructure, such as a managed Kubernetes cluster or a colocation facility, that provider is a subservice organization, and its SOC 2 report likely lists controls the company must operate. The guide to complementary user entity controls covers how to handle those.

Self-hosted automation passes SOC 2 when it is treated as production

Self-hosted automation platforms hold production credentials and change production systems, so auditors treat them as production. Companies that pass with them in scope give the platform the same access reviews, change control, logging, and patching as any other production server, and keep the evidence on the same calendar.

Frequently Asked Questions

How do self-hosted automation platforms meet SOC 2 compliance requirements?

They go into SOC 2 scope like any other production system. The company shows access control and quarterly access reviews, encrypted credential storage with a credentials inventory, version control and review for workflow changes, log forwarding and alerting, patching, vulnerability scanning, and backups, with dated evidence for each on the cadence the policy sets.

Is n8n SOC 2 compliant when self-hosted?

SOC 2 applies to organizations, not software, so no self-hosted tool is SOC 2 compliant on its own. A company can run self-hosted n8n inside a SOC 2 audit by controlling access, protecting the encryption key and stored credentials, reviewing workflow changes, retaining execution and admin logs, and patching the instance.

Do self-hosted CI runners need to be in SOC 2 scope?

Self-hosted runners that build or deploy to production, or that hold production credentials, belong in scope. Auditors look for runners limited to private repositories, separate runner groups for production deploys, ephemeral or rebuilt runners, network limits, and patching on the same cycle as other servers.

How do we handle SOC 2 change management for workflows built in a visual editor?

Use separate development and production instances and promote workflows through an export reviewed in Git, restrict who can edit production workflows and tie each edit to a ticket, or export production workflows on a schedule and review the diff. Each approach gives the auditor a record of who changed what and who approved it.

What SOC 2 evidence do auditors ask for from an automation platform?

Typical requests are the user and role export with access review sign-off, a credentials inventory, change records for workflows and pipelines, version and patch records, scan reports, log forwarding configuration and review records, and backup and restore test records. The auditor samples from the audit period, so each item needs a date.