Does SSH user isolation replace codesign keychain partitioning on a shared Mac?

No. SSH separates login sessions and file ownership; codesign and notarization still need consistent identities, provisioning profiles, and non-interactive keychain access. Pool policy should name build accounts, dedicated keychain files or partitions, unlock windows for CI only, and forbid mixing interactive GUI signing with headless jobs on the same session.

How many concurrent Xcode builds are safe on one shared remote Mac?

Treat shared DerivedData roots, single clones, and global install prefixes as mutually exclusive: allow one heavy xcodebuild or archive at a time there. With isolated Git worktrees, separate build directories, and clear RAM headroom, two heavy integrations are sometimes acceptable; light jobs may reach two to four only when CPU stays below roughly seventy-five percent and free RAM stays above about eight gigabytes, and only if flock or runner concurrency caps match the shell scripts.

Which DerivedData path strategy should a small team standardize?

Default Xcode locations are simplest but create the hottest disk contention on pools. Per-repository or per-worktree subpaths make failures easier to attribute. Read-heavy module caches plus writable sandboxes can speed rebuilds but demand strict umask, scheduled cleanup, and linkage to queue timeouts—pause new heavy jobs when free disk drops below roughly fifteen percent.

What queue and timeout numbers belong in the runbook first?

Cap pending depth near twenty jobs per lane, set per-job timeouts from measured p95 plus margin—light checks about fifteen to twenty-five minutes, standard builds about thirty-five to sixty minutes, archives about forty-five to ninety minutes—and keep flock wait windows shorter than job timeouts, typically about one hundred twenty to three hundred seconds for dependency writes and about thirty to sixty seconds for tiny critical sections, tuned from lock-wait percentiles.

2026 Shared Remote Mac Xcode Codesign Decision Matrix: Concurrency, Keychain Partitions & Queue Timeouts

When a remote Mac becomes your enterprise build pool, outages cluster around signing mix-ups, concurrent writes to one build root, and mismatched queue timeouts. This internal-style FAQ contrasts SSH isolation with keychain partitions, ties concurrency to flock, compares DerivedData paths, and lists timeout defaults. See also pool FAQ, flock guide, and runner routing.

Three pool failure modes (approval-ready wording)

Signing boundaries blur. Multiple pipelines reuse one login session, keychain unlock drifts, provisioning profiles skew, and codesign errors become impossible to attribute.
Concurrency ignores directory mutexes. Parallel xcodebuild jobs target the same DerivedData root, Pods prefix, or artifact folder and leave half-written indexes.
Timeouts are tribal knowledge. Lock waits, job ceilings, and runner labels disagree, so zombies hold flock and the pool stalls.

Align sessions with the SSH/VNC isolation FAQ before tuning signing.

SSH session isolation vs codesign keychain partitioning

Separate SSH users are necessary but not sufficient for trustworthy signing on a shared remote Mac.

Dimension	SSH / session isolation	Keychain & codesign partition
Primary guardrail	Login identity, file ownership, non-interactive automation accounts.	Certificate visibility, private key access, profile-to-bundle binding, notary credentials.
Typical control	Per-role SSH certificates, jump hosts, no shared private keys.	Dedicated keychain files, CI-only unlock hooks, environment-scoped provisioning.
Common mistake	Assuming SSH equals signing safety while two sessions share one GUI login.	Treating the login keychain as a team-wide secret store without rotation logs.

Concurrency caps, flock, and orchestrator queues

Shell scripts and Actions concurrency groups must match flock or waits explode silently. Layout rules: worktree matrix.

Policy	When it fits	Parameter intuition
Strict serial + flock	One clone, shared DerivedData, global toolchain installs.	One heavy job; `flock -w 30–60` for tiny mutations; alert when median queue wait exceeds about fifteen minutes.
Bounded parallelism	Isolated worktrees, separate build sandboxes, monitored CPU and RAM.	Up to two heavy integrations or two to four light jobs when headroom holds; shrink automatically if free disk nears fifteen percent.
Platform queue	Self-hosted runners, internal schedulers.	Match labels to flock domains; cap pending near twenty jobs per lane; scale out before raising integers in YAML.

DerivedData path strategy comparison

DerivedData policy is a concurrency choice—pick one column per pool and document it with queue timeouts.

Strategy	Strength	Concurrency note	Operational cost
Default Xcode location	Zero config for ad-hoc users.	Highest collision risk; treat as single-writer unless paths are namespaced per job.	Requires aggressive scheduled cleanup.
Per-repo or per-worktree path	Clear ownership for support tickets.	Enables two parallel builds when combined with separate source trees.	More scripting in CI YAML or `xcodebuild` wrappers.
Shared read cache + writable sandbox	Faster module rebuilds for many apps.	Demands read-only mounts or strict permissions plus flock around writers.	Hardest to reason about; needs metrics on cache hit rate.

Build queue timeout parameter sheet

Keep this sheet beside the flock FAQ for on-call.

Parameter	Starting value	Notes
Pending queue depth	About twenty jobs per lane	Fail fast with explicit retry guidance instead of silent backlog.
Light job timeout	15–25 minutes	Lint, small unit suites, codegen checks.
Standard compile and test	35–60 minutes	Set from repository p95 duration plus margin.
Archive and upload	45–90 minutes	Include notary and symbol upload steps.
`flock -w` (seconds)	120–300 deps, 30–60 tiny sections	Always shorter than the job timeout; tune from lock-wait p95.
Median wait alert	> 15 minutes sustained	Signals under-provisioned pools or stuck locks.

Five rollout steps

Inventory mutexes: list every shared DerivedData root, dependency cache, Simulator lane, and signing identity per node class.
Assign identities: map automation users to keychain files, provisioning bundles, and SSH roles; ban shared GUI sessions for CI.
Align orchestration: set runner labels, GitHub Actions concurrency groups, and flock paths to the same resource names.
Encode timeouts: paste the parameter sheet into CI YAML, internal wikis, and alerting rules with owner tags.
Observe weekly: review wait percentiles, disk free, swap, and signing failures; adjust caps before adding raw concurrency.

Citable parameters

Heavy Xcode compile concurrency: start at one active job per shared mutable root.
Light jobs: up to two when sustained CPU stays under roughly seventy-five percent and free RAM exceeds about eight gigabytes.
Disk pressure pause: stop scheduling new archives when free space drops under roughly fifteen percent or about forty gigabytes, whichever is larger.
CI log retention: about fourteen to thirty days metadata, about seven days verbose logs.

Resource pool FAQ (quick answers)

Does SSH isolation replace keychain partitioning? No—SSH handles transport and POSIX boundaries; codesign still needs partitioned identities and non-interactive unlock paths.

Can we run two archives at once? Only with isolated worktrees, separate DerivedData paths, verified RAM and disk headroom, and matching runner concurrency—otherwise stay serial.

Timeouts too long? Zombies pin locks—shorten ceilings and fix leaks. For quotas see pool checklist.

Put the matrix on dedicated remote Mac hardware

Meshmac offers remote Mac nodes with SSH and VNC for small-team pools. Open the homepage to compare tiers without logging in, review plans and pricing when you are ready to expand capacity, and read the help center for connection and security basics. Continue exploring the blog index for mesh, runner, and OpenClaw deployment guides.

Homepage Plans & pricing Help center