{"slug":"deploy-multiple-tailscale-ssh-session-recorder-nodes","title":"Deploy multiple Tailscale SSH session recorder nodes","tags":["tailscale"],"agent_summary":"Last validated: Dec 8, 2025","trigger_phrases":[],"runnable":false,"markdown":"\r\n# Deploy multiple Tailscale SSH session recorder nodes\r\n\r\nLast validated: Dec 8, 2025\r\n\r\nTailscale SSH session recording supports using multiple recorder nodes, both for a failover configuration and to separate recordings to different recorders based on your SSH access rules in your tailnet policy file.\r\n\r\n## [Deploy multiple recorders for failover](https://tailscale.com/docs/reference/multiple-recorder-nodes\\#deploy-multiple-recorders-for-failover)\r\n\r\nIf you are running Tailscale SSH session recording in a production environment, you may want to deploy multiple recorders in a failover configuration to prevent unwanted downtime.\r\n\r\nTo deploy multiple recorder nodes in a failover configuration, tag each node with the [tag](https://tailscale.com/docs/features/tags) that is defined in the `recorder` field in SSH access rules. While you can tag as many recorder nodes as you want, you can only assign one tag to each `recorder` field in SSH access rules.\r\n\r\nTailscale determines which recorder node will receive session recordings by choosing the node with the lowest IP address value. If that recorder is unavailable, Tailscale will attempt to reach the node with the next highest IP address value. It will continue attempting to reach recorder nodes in this manner until it successfully connects to a recorder node.\r\n\r\n## [Deploy different recorders for each SSH access rule](https://tailscale.com/docs/reference/multiple-recorder-nodes\\#deploy-different-recorders-for-each-ssh-access-rule)\r\n\r\nSometimes, it might be helpful to deploy multiple groups of recorder nodes, and direct traffic to different recorder nodes based on the underlying SSH access rule.\r\n\r\nFor example, the following access control policy snippet shows two SSH access rules. The first rule specifies that all members can use Tailscale SSH to connect to their own devices, and the second rule specifies that members of the `eng` group can connect to servers with the `prod` tag.\r\n\r\nSSH session recording is enabled for both SSH access rules, but each SSH access rule defines a different tag in the `recorder` field: The first SSH access rule sends recordings to nodes with the tag `dev-recorders`, and the second SSH access rule sends recordings to nodes with the tag `prod-recorders`.\r\n\r\n```json\r\n\"ssh\": [\\\r\n  {\\\r\n    \"action\": \"check\",\\\r\n    \"src\": [\"autogroup:member\"],\\\r\n    \"dst\": [\"autogroup:self\"],\\\r\n    \"users\": [\"autogroup:nonroot\"],\\\r\n    \"recorder\": [\"tag:dev-recorders\"]\\\r\n  },\\\r\n  {\\\r\n    \"action\": \"check\",\\\r\n    \"src\": [\"group:eng\"],\\\r\n    \"dst\": [\"tag:prod\"],\\\r\n    \"users\": [\"list-of-ssh-users\"],\\\r\n    \"recorder\": [\"tag:prod-recorders\"]\\\r\n  }\\\r\n]\r\n```\r\n\r\nYou may want to deploy recorders in this configuration if you need to isolate recordings based on the sensitivity of data, like recordings that contain user PII.\r\n\r\nIf a Tailscale SSH connection is allowed by multiple SSH access rules that each specify a different recorder tag, Tailscale will follow the instructions of the rule that is listed first in the tailnet policy file.\r\n\r\n![Project Logo](https://cdn.brandfetch.io/tailscale.com/fallback/lettermark/theme/dark/h/256/w/256/icon?c=1bfwsmEH20zzEfSNTed)\r\n\r\nAsk AI\r\n\r\nreCAPTCHA\r\n\r\nRecaptcha requires verification.\r\n\r\nprotected by **reCAPTCHA**\r\n","html":"<h1>Deploy multiple Tailscale SSH session recorder nodes</h1>\n<p>Last validated: Dec 8, 2025</p>\n<p>Tailscale SSH session recording supports using multiple recorder nodes, both for a failover configuration and to separate recordings to different recorders based on your SSH access rules in your tailnet policy file.</p>\n<h2><a href=\"https://tailscale.com/docs/reference/multiple-recorder-nodes#deploy-multiple-recorders-for-failover\">Deploy multiple recorders for failover</a></h2>\n<p>If you are running Tailscale SSH session recording in a production environment, you may want to deploy multiple recorders in a failover configuration to prevent unwanted downtime.</p>\n<p>To deploy multiple recorder nodes in a failover configuration, tag each node with the <a href=\"https://tailscale.com/docs/features/tags\">tag</a> that is defined in the <code>recorder</code> field in SSH access rules. While you can tag as many recorder nodes as you want, you can only assign one tag to each <code>recorder</code> field in SSH access rules.</p>\n<p>Tailscale determines which recorder node will receive session recordings by choosing the node with the lowest IP address value. If that recorder is unavailable, Tailscale will attempt to reach the node with the next highest IP address value. It will continue attempting to reach recorder nodes in this manner until it successfully connects to a recorder node.</p>\n<h2><a href=\"https://tailscale.com/docs/reference/multiple-recorder-nodes#deploy-different-recorders-for-each-ssh-access-rule\">Deploy different recorders for each SSH access rule</a></h2>\n<p>Sometimes, it might be helpful to deploy multiple groups of recorder nodes, and direct traffic to different recorder nodes based on the underlying SSH access rule.</p>\n<p>For example, the following access control policy snippet shows two SSH access rules. The first rule specifies that all members can use Tailscale SSH to connect to their own devices, and the second rule specifies that members of the <code>eng</code> group can connect to servers with the <code>prod</code> tag.</p>\n<p>SSH session recording is enabled for both SSH access rules, but each SSH access rule defines a different tag in the <code>recorder</code> field: The first SSH access rule sends recordings to nodes with the tag <code>dev-recorders</code>, and the second SSH access rule sends recordings to nodes with the tag <code>prod-recorders</code>.</p>\n<pre><code class=\"language-json\">\"ssh\": [\\\r\n  {\\\r\n    \"action\": \"check\",\\\r\n    \"src\": [\"autogroup:member\"],\\\r\n    \"dst\": [\"autogroup:self\"],\\\r\n    \"users\": [\"autogroup:nonroot\"],\\\r\n    \"recorder\": [\"tag:dev-recorders\"]\\\r\n  },\\\r\n  {\\\r\n    \"action\": \"check\",\\\r\n    \"src\": [\"group:eng\"],\\\r\n    \"dst\": [\"tag:prod\"],\\\r\n    \"users\": [\"list-of-ssh-users\"],\\\r\n    \"recorder\": [\"tag:prod-recorders\"]\\\r\n  }\\\r\n]\n</code></pre>\n<p>You may want to deploy recorders in this configuration if you need to isolate recordings based on the sensitivity of data, like recordings that contain user PII.</p>\n<p>If a Tailscale SSH connection is allowed by multiple SSH access rules that each specify a different recorder tag, Tailscale will follow the instructions of the rule that is listed first in the tailnet policy file.</p>\n<p><img src=\"https://cdn.brandfetch.io/tailscale.com/fallback/lettermark/theme/dark/h/256/w/256/icon?c=1bfwsmEH20zzEfSNTed\" alt=\"Project Logo\"></p>\n<p>Ask AI</p>\n<p>reCAPTCHA</p>\n<p>Recaptcha requires verification.</p>\n<p>protected by <strong>reCAPTCHA</strong></p>\n"}