Cursor Automations on Cloud Mac: Scheduled Agents, Webhooks and Background Agent Division

1. Why 2026 agents split "trigger" from "execution"

Over the past year, developer AI tooling evolved along three parallel product lines: on-demand dispatch (Background / Cloud Agent), event-driven automation (Automations), and self-hosted orchestration (launchd, cron, n8n + MCP). Many teams treat them as interchangeable — "aren't they all agents running automatically?" — and end up forcing iOS builds inside Linux sandboxes, manually clicking Background Agent on every PR, or stacking ten cron jobs on Cloud Mac with nobody reading logs.

What slows delivery is rarely model IQ; it is misaligned workflow entry points: scheduled work dispatched manually, macOS tasks thrown into Cursor's cloud sandbox. Typical support evolution: first "how do I enable Automations?" (see official Automations docs), then "can Archive run automatically after PR merge?" (not on Linux sandbox alone), finally "can a Webhook hit my Cloud Mac?" — the decision chain this article unpacks.

Site context: last week's Background Agent runtime field test answers "which Mac runs the agent"; launchd scheduled Agent FAQ answers "self-hosted macOS orchestration"; this piece fills the middle layer — Cursor Automations capability boundaries and how Cloud Mac complements them.

2. What Cursor Automations is: always-on Cloud Agent

Per the 2026-03-05 changelog and official announcement, Cursor Automations let you configure "always online" agents with triggers + natural-language instructions + optional tools.

Create them at cursor.com/automations; the June /automate skill lets Cursor generate config from chat (see 06-18 improvements).

Trigger types (any match fires a run):

• Scheduled: preset cadence or cron expression;
• GitHub / GitLab: PR opened/pushed/merged, push to branch, CI completed, review comment, and more (June added several GitHub events);
• Slack: new channel messages, emoji-reaction triggers;
• Linear / PagerDuty: Issue, Cycle, Incident;
• Webhook: private HTTP endpoint + API Key after save; POST to trigger.

Each trigger spins up a cloud sandbox where the agent follows your instructions, can comment on PRs, post to Slack, call MCP, and use memory across runs. Repo modes: no repo (Slack/MCP/Webhook orchestration only), single repo, multi-repo environment — no-repo mode cannot edit code or open PRs, ideal for notifications and external integrations.

Asymmetric conclusion: Automations value is in the trigger ecosystem, not macOS runtime — models keep getting cheaper, but "someone starts investigating 30 seconds after PR merge" prices response entry, not another GPT pass.

3. What Background Agent is: one long run you dispatch

Background Agent (now often Cloud Agent) is on-demand: you explicitly assign a task in the IDE, cursor.com/agents, Slack @Cursor, or the API; the agent runs in a cloud VM until it opens a PR, delivers logs, or fails. It has no built-in "scan dependencies every Monday" or "auto-fix when CI goes red" — unless Automations or external cron replaces the finger click.

Mnemonic:

• Automations: "when X happens → do template Y"; repeatable ops and code hygiene;
• Background Agent: "do this complex thing now"; exploratory refactors, cross-module rewrites, one-off hard problems;
• Cloud Mac launchd: "run on my macOS per my plist"; Keychain, Xcode, local MCP paths.

The official PagerDuty case is typical: Incident triggers Automation → agent queries Datadog MCP → finds recent repo changes → Slack on-call + opens fix PR — Automations + MCP + single repo, all closable in Linux sandbox. If the last step needs xcodebuild archive to verify an iOS build, you need a separate macOS execution channel.

4. Where Automations run: Linux sandbox, same origin as Cloud Agent

Official docs: Automations run in Cursor-hosted cloud sandboxes (Linux + optional Dockerfile / snapshot), same as Cloud Agent. That means:

• ✅ Edit Node/Python/Go repos, run unit tests, open PRs, call cloud MCP (Datadog, Linear, etc.);
• ❌ Native xcodebuild, iOS Simulator, macOS Keychain signing, macOS-only CLIs;
• ⚠️ June changelog added computer use for Automations, but still inside the sandbox — not a substitute for real Apple toolchain.

Same conclusion as our Background Agent runtime article: Cursor official cloud = Linux first. Automations offers no separate "macOS trigger runtime" — only a stronger trigger side.

So "configure Automations on Cloud Mac" has two engineering meanings: ① configure Automations in Cursor console (logic in Cursor cloud); ② for macOS tasks, Webhook / CI-completed trigger → forward to dedicated Cloud Mac. Most searches for "Cursor Automations Cloud Mac" mean ②, not moving the Automation process onto a Mac mini — not an official path today.

5. What Cloud Mac fills in the automation stack

A dedicated Cloud Mac (hosted M4 Mac mini) typically plays four roles:

1. macOS execution node: xcodebuild, Flutter iOS, notarytool, Simulator — same battlefield as Archive CI troubleshooting;
2. Webhook receiver: HTTP service on intranet or tunnel, accepting POST from Automations / GitHub Actions / monitoring;
3. launchd always-on host: calendar or KeepAlive runs for Claude Code, Codex CLI, custom scripts (see launchd Agent FAQ);
4. MCP co-located deployment: agent and MCP server share paths, avoiding "config on laptop, repo in cloud" splits (see MCP placement guide).

Windows-primary teams especially need this chain: code on Windows, iOS builds on Cloud Mac, Automations in Cursor cloud for PR hygiene and dependency scans, Webhook after merge triggers Cloud Mac Archive — three layers, each doing its job, far more stable than stuffing everything into one Automation.

6. Five-dimension comparison of three approaches

Add the trigger-vs-execution lens: Automations excels at trigger diversity; Background at single-task depth; Cloud Mac at OS capability. No row wins all three — hence the hybrid mandate.

7. Hybrid architecture: Webhook chaining Automations → Cloud Mac

Our recommended standard hybrid stack (validated on one daily-lease Cloud Mac):

[GitHub PR merged]
       ↓
[Cursor Automation: trigger = PR merged, repo = single]
       → Linux sandbox: lint / test / docs PR (optional)
       → Tool: Webhook POST → https://<cloud-mac-tunnel>/hooks/ios-archive
       ↓
[Cloud Mac local service: nginx/caddy + auth]
       → launchd or one-shot: git pull → xcodebuild archive → exportArchive
       → on failure: Slack / Feishu webhook alert
       ↓
[TestFlight / internal distribution]

Key points:

• Automation Webhook tool appends raw payload into agent instructions — or create a Webhook-only, no-repo Automation for routing and auth checks without touching code;
• Cloud Mac side uses short-lived tokens to validate POST; never expose bare endpoints (tunnel security parallels OpenClaw Webhook patterns, though OpenClaw is not this article's focus);
• Do not push macOS builds back into Linux Automation — Archive pipeline is Keychain- and Scheme-sensitive; run verified plist / Fastlane scripts on Cloud Mac;
• Scheduled tasks like "Monday 9:00 dependency audit" can live entirely in Automations; "Monday 9:30 iOS regression build" on Cloud Mac launchd — summarize both in Slack.

8. Scenario matrix: which option to use

9. Recommended combos and red lines

Combo A (full-stack Web + small iOS module): Automations for PR hygiene and dependency bot; iOS subdirectory merge → Webhook → Cloud Mac Archive; Background Agent only for one-off "major version migration" tasks.

Combo B (indie iOS): one 16GB Cloud Mac monthly; launchd for nightly tests; Cursor Automations bound to GitHub "PR comment" as Code Review assistant (no macOS build); CLI Agent shares worktree with Cursor (see dual-Agent isolation).

Combo C (platform / SRE): PagerDuty → Automations → Datadog MCP + fix PR; if fix touches iOS client, Automation ends with Webhook to Cloud Mac for verification build — never put Archive in Linux sandbox.

Red lines: ① never use no-repo Automation to edit code — official docs forbid opening PRs; ② after Team Owned Automation upgrade, rotate Webhook API Key and reconfigure MCP OAuth; ③ Cloud Mac Webhook must have auth + rate limits; ④ don't run "launchd Simulator farm + parallel Background + Archive" on 16GB — see Runner memory articles.

10. Common misconceptions

• Myth 1: "Automations replaces Background Agent" — Automations wraps triggers; complex exploratory work still needs manual Background dispatch.
• Myth 2: "Automations replaces Cloud Mac" — only the Linux-closed-loop portion; iOS/macOS involvement needs Mac runtime.
• Myth 3: "Webhook equals automation done" — Webhook is the wire; receiver script, Keychain, git state machine on Cloud Mac are the execution core.
• Myth 4: "Duplicates the launchd article" — launchd piece covers self-hosted macOS orchestration; this piece covers Cursor official Automations and how to connect — different trigger sources.
• Myth 5: "Every scheduled agent needs cron" — prefer official Automations Scheduled when possible; reserve launchd for macOS-only tasks.

11. 7-step rollout checklist

1. At cursor.com/automations create a test Automation: Scheduled every 6 hours or Webhook, instruct "list stale repo dependencies and post to Slack" (no macOS).
2. Daily lease one Cloud Mac; complete SSH + disk baseline per onboarding acceptance checklist.
3. Deploy a minimal Webhook receiver on Cloud Mac (caddy reverse proxy + Bearer token); local script runs git pull && ./scripts/smoke-build.sh only.
4. Create a second Automation: GitHub "Workflow run completed" or "PR merged" → Webhook tool → Cloud Mac endpoint; payload includes commit SHA.
5. In parallel, manually dispatch Background Agent on the same event; compare turnaround and reproducibility — Automations should feel more templated, Background more flexible.
6. Solidify macOS build scripts in launchd plist or Fastlane lane; forbid long shell in Automation instructions (hard to audit); Automation only "calls Webhook".
7. Run 48 hours: at least one real merge trigger + one intentional failure (test alerts); upgrade to monthly if satisfied; document Webhook Key rotation SOP.

12. FAQ

Q: Can Cursor Automations and Background Agent be one product mentally?

Yes: Automations = triggers + templated Cloud Agent; Background Agent = manually triggered Cloud Agent. Same Linux runtime; different "when to run" configuration layer.

Q: Can Automation SSH directly to my Cloud Mac?

Official tools don't include "SSH to tenant Mac". Practical path: Webhook to HTTP service on Cloud Mac, or GitHub Actions self-hosted runner on Cloud Mac (parallel to Automations, not a substitute).

Q: What is no-repo Automation good for?

Pure Slack rollups, PagerDuty notifications, external MCP calls, Webhook routing — cannot edit code. Bind a repo to open PRs.

Q: Why rotate Webhook Key after Team Owned?

Official note: after promotion to team ownership, identity becomes team service account; old keys expire; MCP OAuth must switch to team credentials.

Q: Is 16GB Cloud Mac enough for this hybrid stack?

Single worktree + occasional Archive + light Webhook service: 16GB daily lease validates. launchd Simulator farm + parallel Agents: prefer 24GB monthly.

13. Conclusion

Cursor Automations productizes "always-on Agent" as triggers — schedule, GitHub, Slack, Webhook — the orchestration layer worth adopting first in 2026. It shares Linux cloud sandbox with Background Agent and cannot solve Xcode or Keychain.

The right posture is three-layer division: Automations for events and templated edits; Background for one-off deep tasks; Cloud Mac via Webhook / launchd for macOS execution. The question is not "which agent is smarter" but whether trigger entry and execution boundary align.

Suggested action this week: create one Webhook Automation in Cursor console, connect one Archive smoke-test chain on a daily-lease Cloud Mac — within 48 hours you'll see where official automation and Mac runtime each belong.