2 сентября 2026 года Cursor опубликовал в блоге анонс Self-Hosted Machines (автор — Jack Pertschuk): cloud-агенты Cursor теперь умеют исполняться не только в облаке Cursor, но и на динамически выделяемых пулах машин внутри вашей сети (cursor.com/blog/self-hosted-machines). Вы управляете железом, Cursor оставляет за собой оркестрацию: цикл агента, инференс и планирование по-прежнему живут в облаке, а вот выполнение инструментов — правки файлов, команды в терминале, браузер — уезжает к вам.
Это не «ещё один облачный раннер», а сдвиг границы ответственности. В анонсе прямо перечислены сценарии, ради которых команды забирают исполнение к себе:
«Cursor cloud agents can execute on dynamically scheduled pools of machines inside your network. You manage the underlying infrastructure, while agents are still started and managed from Cursor. This gives teams more control over where agents execute and what infrastructure they use. Agents can work next to internal services and source control, run on custom hardware, or use operating systems and build pipelines that are difficult to package as a Cloud Agent build.»
«Cloud-агенты Cursor могут исполняться на динамически выделяемых пулах машин внутри вашей сети. Инфраструктурой управляете вы, агенты по-прежнему запускаются и управляются из Cursor. Это даёт командам больше контроля над тем, где исполняются агенты и какую инфраструктуру они используют. Агенты могут работать рядом с внутренними сервисами и системой контроля версий, на собственном «железе» или с ОС и сборочными пайплайнами, которые сложно упаковать в Cloud Agent build.» — Cursor Blog, 02.09.2026
Разбираем, что именно появилось, как это подключить и в каких случаях это решает реальную проблему.
Что именно изменилось
Раньше cloud-агент Cursor работал только так: вы даёте промпт, агент поднимается на виртуалке Cursor, пишет код, пушит. Вся работа — файлы, команды, секреты — происходила в облаке Cursor. Для команд, у которых код и сервисы не должны покидать внутренний контур, это был барьер.
Self-Hosted Machines меняет одно, но принципиальное: место исполнения инструментов. Агентский цикл (планирование, инференс, оркестрация) остаётся в Cursor, а вызовы инструментов — редактирование файлов, выполнение команд, работа браузера — выполняются на машине, которой управляете вы.
Ключевые элементы из анонса:
- Workers — воркеры, которые подключают вашу инфраструктуру к agent-loop Cursor. Регистрация машины — через CLI:
agent worker start. - Pools — пулы воркеров, которые масштабируются под спрос и обслуживают любой репозиторий. Один пул может раздавать задачи по множеству репозиториев.
- Sandbox-провайдеры — поддержка AWS Lambda, Cloudflare, Coder, Daytona, E2B, Modal, Namespace, Vercel: воркеры запускаются там, где уже крутятся ваши песочницы.
- Браузеры агентов на Linux и Mac — computer use теперь работает и на Linux-воркерах, а не только на Mac.
«Cloud agents now create more than 60% of the pull requests we merge internally and are taking on a growing share of software work at many of the largest enterprises we work with.»
«Cloud-агенты сейчас создают более 60% pull request, которые мы мёржим внутри компании, и берут на себя растущую долю работы в крупнейших enterprise-командах.» — Cursor Blog, 02.09.2026
Как это устроено технически
Воркер поднимается на машине в вашей сети и открывает исходящее HTTPS-соединение к облаку Cursor:
ваша машина (worker) ──исходящее HTTPS──▶ облако Cursor
▲ │
│ правки файлов, команды, браузер │ планирование, инференс
└───────────────────────────────────────┘
результаты инструментов идут назад
Cursor никогда не инициирует соединение внутрь вашей сети. Это снимает главный вопрос безопасности: не нужно открывать входящие порты, публичные IP или VPN-туннели.
Воркеры бывают двух конфигураций (документация):
| Конфигурация | Для чего | Кому подходит |
|---|---|---|
| My Machines | Одна машина (ноутбук, devbox, удалённая VM) привязана к вашему аккаунту | Личные рабочие процессы, машина с нужным состоянием, проба модели перед пулом |
| Team Pools | Именованная очередь воркеров на команду или enterprise, общая ёмкость | Команды и компании, которым нужна управляемая инфраструктура исполнения |
Пул масштабируется автоматически: контроллер следит за очередью запросов и по спавн-скрипту команды поднимает новые машины под всплеск спроса. Если в пуле есть свободный воркер — он забирает запрос; если нет — запрос ждёт, пока появится ёмкость. Команде не нужно решать заранее, сколько машин держать включёнными.
Облако Cursor против своих машин
Облачное исполнение осталось по умолчанию и для большинства команд — рекомендованным путём. Каждая сессия в облаке Cursor работает на выделенной VM с установленными зависимостями и собственными сетевыми правилами.
Изоляция на агента, редактирование секретов, контроль исходящего трафика и подписанные коммиты покрывают требования безопасности большинства команд. Cursor прямо пишет: начните с управляемых cloud-агентов, а к своим машинам переходите, только если ограничения не влезают в облачную модель.
Сравнение по сути:
| Параметр | Облако Cursor (по умолчанию) | Self-Hosted Machines |
|---|---|---|
| Где исполняются инструменты | Виртуалки в облаке Cursor | Машины в вашей сети / у ваших провайдеров |
| Agent-loop, инференс, планирование | В облаке Cursor | В облаке Cursor |
| Управление железом | Никакого — всё делает Cursor | Вы: образы, патчи, масштабирование |
| Доступ к внутренним сервисам | Через PrivateLink / Cloudflare Tunnel / Tailscale | Напрямую, рядом с БД и API |
| Комплаенс / data residency | Ограничен облаком Cursor | Код и данные не покидают ваш контур |
| Стоимость инфраструктуры | Включена в использование модели | Плюс ваши машины / кластер |
| Особое «железо» (GPU, Mac) | Нет | Да, если есть у вас |
Ключевая деталь: свои машины не заменяют управляемый Cursor-контур. Self-Hosted Machines — это когда требования к сети или «железу» не закрываются managed-режимом. Только исполнение уезжает к вам; артефакты (скриншоты, видео, логи) воркер загружает обратно в хранилище Cursor, чтобы они попадали в pull request и дашборд.
Для кого это
Из документации и анонса — три группы случаев, когда self-hosted имеет смысл:
1. Код и сервисы не могут выходить за периметр. Агент должен выполнять инструменты внутри сети с прямым доступом к приватному Git, внутренним API и сервисам. Если вам нужен доступ к приватному source control или внутреннему реестру пакетов, Cursor предлагает сначала попробовать managed-агентов с приватной связностью (AWS PrivateLink / Cloudflare Tunnel) — но когда и этого мало, воркер внутри сети решает вопрос напрямую.
2. Специфическое «железо» и ОС. GPU-машины для обучения/инференса, Mac для iOS-разработки, Kubernetes, песочницы, управляемые VM. Для iOS- и macOS-сборок Namespace поднимает настоящий Mac на Apple silicon для каждого cloud-агента:
«You can’t build iOS or macOS apps without a Mac. Namespace Devboxes spin up a real Mac for each Cursor Cloud Agent, which can now perform that work on Apple silicon.»
«Нельзя собрать iOS- или macOS-приложение без Mac. Namespace Devboxes поднимают настоящий Mac для каждого cloud-агента Cursor, и теперь он может выполнять такую работу на Apple silicon.» — Hugo Santos, CEO Namespace, cursor.com/blog/self-hosted-machines
3. ОС и пайплайны, которые не упаковываются в Cloud Agent build. Сборка под нестандартную ОС или внутренний сборочный конвейер — то, что трудно повторить в стандартном build-образе Cursor.
Как начать: пошагово
Самый быстрый способ попробовать — конфигурация My Machines: подключить одну машину к своему аккаунту.
Шаг 1. Установите Cursor CLI
На macOS, Linux и WSL:
curl https://cursor.com/install -fsS | bash
Проверьте установку:
agent --version
Шаг 2. Войдите в аккаунт
agent login
Шаг 3. Запустите воркер
agent worker start
Процесс долгоживущий: держит соединение, пока вы его не остановите, и переиспользуется в будущих сессиях.
Шаг 4. Запустите агента
Перейдите на cursor.com/agents. В выпадающем меню окружения должна появиться ваша машина. Отправьте задачу — и она выполнится у вас, а не в облаке Cursor.
Полезные опции для личного воркера (документация My Machines):
# имя машины (нужно для вызова worker=имя из Slack/GitHub/Linear)
agent worker start --name "my-devbox"
# рабочая директория с репозиторием
agent worker --worker-dir /path/to/repo start
Для командной настройки пулов нужен enterprise-план Cursor, сервис-аккаунт API-ключ и админская настройка в дашборде Cloud Agents:
export CURSOR_API_KEY="<сервис-аккаунт-ключ>"
agent worker --pool gpu --idle-release-timeout 600 start
Для запуска в Kubernetes есть готовый шаблон anysphere/k8s-workers: контроллер поднимает по одному pod’у на запрос (--spawn) или держит тёплые pod’ы (--warm-idle), без CRD.
Computer use на Linux
Чтобы агент мог кликать, делать скриншоты и управлять браузером на Linux-воркере, поставьте desktop-пакеты (пример из документации):
sudo apt-get install -y --no-install-recommends \
dbus-x11 ffmpeg tigervnc-standalone-server \
x11-utils x11-xserver-utils xdotool xfce4
Затем запускайте воркер с флагом --computer-use. На macOS первым стартом ставится helper-приложение Cursor Computer Use, которому нужно выдать права Accessibility и Screen Recording.
Партнёрские sandbox-провайдеры
Cursor не требует строить кастомный слой песочниц. Воркеры запускаются и оркеструются там, где уже живут ваши песочницы:
| Провайдер | Документация / гайд | Что это даёт |
|---|---|---|
| AWS Lambda | MicroVMs + Cursor Self-Hosted | МикроVM в вашем AWS-аккаунте: мгновенный старт из снимка, пауза при простое, полный стейт при возобновлении |
| Cloudflare | Sandbox-туториал для Cursor | Агенты в изолированных окружениях Cloudflare Containers |
| Modal | modal.com/docs/cursor | Отдельная Modal Sandbox под каждую сессию |
| Namespace | namespace.so/docs/integrations/cursor | Настоящие Mac на Apple silicon |
| Vercel | kb: Cursor + Vercel Sandbox | Изолированная песочница по требованию, без простаивающего флота |
| Daytona, E2B, Coder | гайды в их доках | Песочницы / dev-окружения по запросу |
«Self-Hosted Machines put teams in control of where Cursor agents run, and Vercel Sandbox makes it effortless. Every task gets an isolated sandbox on demand, no fleet to manage, and nothing sitting idle.»
«Self-Hosted Machines дают командам контроль над тем, где исполняются агенты Cursor, а Vercel Sandbox делает это без усилий. Каждая задача получает изолированную песочницу по требованию — без управления флотом и без простаивающих машин.» — Allen Zhou, Vercel, cursor.com/blog/self-hosted-machines
Что уходит из вашей сети — и что остаётся
Разбираем границу данных, потому что именно она — причина, по которой команды смотрят на self-hosted.
Остаётся на вашей машине: полный checkout репозитория, build-кэш, локальные credentials машины. Только исполнение — у вас.
Уходит в Cursor во время работы: содержимое файлов, вывод терминала, диффы, скриншоты, результаты локальных MCP-серверов и routing-метаданные — воркер отправляет Cursor то, что нужно агенту для следующего шага инференса. Воркер также загружает артефакты (скриншоты, видео, ссылки на логи) в управляемое хранилище Cursor, чтобы они появились в PR и дашборде.
Сеть: воркеру нужен исходящий HTTPS к api2.cursor.sh и api2direct.cursor.sh для сессии и к cloud-agent-artifacts.s3.us-east-1.amazonaws.com для загрузки артефактов. Никаких входящих портов. Если загрузка артефактов не нужна — заблокируйте исходящий трафик к S3-хосту, сессия продолжит работать.
Privacy Mode распространяется и на Self-Hosted Machines: при включении код, уходящий с воркера, не используется для обучения ни Cursor, ни провайдерами моделей.
Ограничения на момент публикации (12.09.2026)
Team Pools — только на Enterprise-плане. Пул воркеров для команды требует Cursor Enterprise, сервис-аккаунт API-ключ и админ-настройку. Личная конфигурация My Machines доступна и на обычных платных планах, но общая командная ёмкость — enterprise-история.
Артефакты всё равно идут в Cursor. Код исполняется у вас, но скриншоты, видео и логи загружаются в хранилище Cursor. Если комплаенс запрещает и это — нужен отдельный разговор с отделом продаж (или отключение загрузки артефактов с потерей их в PR).
Agent-loop остаётся в облаке Cursor. Self-hosted — не «полностью офлайн». Если задача — убрать зависимость от облака Cursor вообще, этот инструмент её не решает. Он решает вопрос контроля над исполнением и данными внутри контура.
Гигиену секретов никто не отменяет. Воркер шлёт Cursor вывод терминала и содержимое файлов. Держите секреты вне tool-вывода и артефактов — это написано в доках прямо.
Одна сессия — один воркер в пуле. Пока агент работает, воркер занят. Для параллельности нужно масштабировать пул.
Лимиты регистрации: до 200 воркеров на пользователя и 1000 на команду; для больших развёртываний — обсуждение с Cursor.
Блок российских реалий
Cursor в целом работает из РФ без VPN — приложение доступно, сайт не заблокирован. Проблема традиционная: оплата.
Оплата. Cursor принимает банковские карты Visa, Mastercard, American Express. Российские карты Visa/Mastercard не работают для международных платежей с 2022 года. Mir и UnionPay официально не поддерживаются. Рабочие пути (из обсуждений в русскоязычном сообществе и наших предыдущих статей):
— карта иностранного банка (Казахстан, Армения, Турция, Сербия и др.);
— UnionPay российских банков — работает нестабильно, зависит от банка-эквайера;
— посредники по оплате зарубежных подписок — комиссия 10–30%, не все работают с Cursor.
Self-hosted на российской инфраструктуре. Сама по себе схема self-hosted воркеров не требует «российской» инфраструктуры Cursor: воркер — это любая машина с исходящим HTTPS к api2.cursor.sh. Технически можно поднять воркер на виртуалке в Yandex Cloud или VK Cloud — соединение исходящее, блокировок этих хостов со стороны российских провайдеров на момент публикации не зафиксировано. Но: (1) доступ к самому Cursor и оплата подписки Enterprise остаются той же проблемой, что и для обычного Cursor; (2) русскоязычного опыта именно Self-Hosted Machines в рунете нет — тема новая (анонс 02.09.2026), даже англоязычные разборы только начинают появляться.
Русскоязычные материалы. По Cursor Cloud Agents в рунете практически ничего нет, по self-hosted-режиму — тем более. Честно: если у вас есть опыт развёртывания воркеров Cursor на российской инфраструктуре — делитесь в комментариях, тема остаётся белым пятном.
Практические советы
Начните с My Machines, а не с пула. Подключить один ноутбук к аккаунту — 10 минут. Понять, где проходят границы данных, что уходит в Cursor, а что остаётся, удобнее на одной машине, чем на enterprise-пуле.
Сначала проверьте managed-вариант с приватной связностью. Cursor прямо рекомендует: если нужно только дотянуться до приватного Git или сервисов в VPC — попробуйте managed-агентов с AWS PrivateLink / Cloudflare Tunnel / Tailscale. Self-hosted имеет смысл, когда нужен именно контроль над железом и исполнением.
Настраивайте idle-timeout и hibernation. Оставлять машину включённой, пока агент простаивает, дорого. Если машину освободить — при follow-up агенту понадобятся минуты на пересборку рабочего окружения. Гибернация со снимком решает это: машина останавливается, а в окне переподключения снимок восстанавливается и воркер стартует с тем же ID.
Держите секреты вне выводов. Воркер передаёт Cursor содержимое файлов и терминала. Секреты, попавшие в артефакт или лог, уедут в облако Cursor — следите за этим.
Один пул — много репозиториев. Пул не привязан к конкретному репозиторию: запросу достаточно указать пул, и любой свободный воркер его заберёт. Не плодите пул под каждый репозиторий.
Вывод
Self-Hosted Machines — ответ Cursor на вопрос «где исполняется код агента». Облачная модель остаётся по умолчанию, но командам с приватной инфраструктурой, особым железом и требованиями к data residency Cursor теперь предлагает исполнительный контур внутри их сети — при том что планирование и инференс остаются в облаке Cursor.
Анонс показателен и в другом: Cursor внутри сам мёржит более 60% PR, созданных агентами. Когда агенты становятся основным производителем кода, машины, на которых они работают, превращаются в стратегический ресурс — и инструмент управления этим ресурсом появляется именно сейчас.
Для команд из РФ главный барьер — не техника (воркер на российской VM технически возможен), а оплата Cursor и доступ к enterprise-функциям. Техническая новинка для нас пока опережает практику: русскоязычных кейсов самохостинга агентов Cursor нет.
Источники
- Cursor Blog — Run cloud agents on machines you manage (02.09.2026) — основной источник анонса.
- Cursor Docs — Self-Hosted Machines — обзор, термины, требования.
- Cursor Docs — My Machines — подключение личного воркера, команды CLI.
- Cursor Docs — Team Pools — настройка командных пулов.
- Cursor Docs — Computer use — браузеры агентов на Linux и Mac.
- AWS Lambda — MicroVMs + Cursor Self-Hosted Machines — партнёрский гайд AWS.
- Cloudflare — Sandbox tutorial: Cursor Cloud Agents — партнёрский гайд Cloudflare.
- Cursor Pricing — планы и цены на момент публикации.
Связанные статьи
- Кейс: Cursor Cloud Agents без репозитория — старт агента с нуля, Origin repo.
- Как пользоваться Cursor — установка, правила, режимы агента.
- Песочницы для ИИ-агентов — изоляция исполнения как слой защиты.
- Claude Code
--restricted— ограничение инструментов выполнения кода. - Промпт-инъекции в кодинг-агентах — угрозы, из-за которых контроль исполнения важен.
