Deploy Nexus Shell on managed Macs with AutoPkg and Munki

By Nexus Shell · Published September 12, 2026

If your developers use Apple Silicon Macs to manage Linux servers, you can distribute Nexus Shell through the existing AutoPkg and Munki workflow. The official download recipe selects a GitHub release and verifies its Developer ID signature. The Munki recipe imports it into a testing catalog. Importing the app does not deploy it to every Mac or grant users a commercial license.

This guide is for Mac administrators evaluating an SSH workspace, not for setting up a new MDM system. Nexus Shell combines SSH terminals with Pro features such as SFTP, Docker controls and monitoring. macOS 14.2 or later and Apple Silicon are required. Intel Macs are not supported.

Start with the official recipes

Use a Mac with AutoPkg already installed. Review the developer-maintained repository and its recipes before running them. Use your normal AutoPkg administrative account rather than adding an unnecessary sudo step.

autopkg repo-add viewer12/nexusshell-recipes
autopkg make-override NexusShell.download
autopkg verify-trust-info NexusShell.download
autopkg run NexusShell.download -k FAIL_RECIPES_WITHOUT_TRUST_INFO=yes

Create the override only after reviewing the recipe. It records trust in that version of the parent recipe. A later trust mismatch is a reason to review the change, not to disable verification. A successful download verifies the app but does not install it across your fleet.

What the download recipe checks

The recipe selects a stable-looking Nexus-Shell-vX.Y.Z.dmg asset from viewer12/Nexus-Shell-Releases. It passes the app inside the disk image to AutoPkg's CodeSignatureVerifier with strict verification enabled.

• Expected bundle identifier: sameral.Nexus-Shell.
• Expected developer Team ID: 5MBFAB57U2.
• Expected Apple Developer ID certificate chain.
• Strict code-signing validity.

These checks establish signing identity and integrity against the recipe requirement. They do not replace your own software approval, runtime evaluation or malware review. This recipe downloads the selected release; it is not a version-pinning or automatic rollback system.

Import into your Munki testing catalog

Use a writable test Munki repository already configured in AutoPkg. Do not run the import against production as your first evaluation. The recipe defaults to apps/NexusShell, the testing catalog, minimum macOS 14.2 and arm64. It sets unattended_install to false.

autopkg make-override NexusShell.munki
autopkg verify-trust-info NexusShell.munki
autopkg run NexusShell.munki -k FAIL_RECIPES_WITHOUT_TRUST_INFO=yes

Check the resulting pkginfo, package location and version. Regenerate catalogs with your existing Munki workflow, then make the app available to a test manifest through your normal approval process. Import alone does not publish a Managed Software Center offer or assign software to clients.

Keep local policy in recipe overrides instead of editing the shared upstream recipe. Do not copy a testing catalog setting into a production rollout without a review.

Evaluate one Mac before broad distribution

• Confirm the supported macOS version and Apple Silicon architecture.
• Install the approved build on a test Mac, launch it, and create a connection to a test Linux host.
• Confirm the actual workflow your team needs: basic terminals, remote file editing, container inspection or monitoring. Test the relevant feature and entitlement rather than assuming successful packaging proves feature readiness.
• Keep SSH passwords and keys in each user's approved credential workflow. Do not embed them in a recipe, Munki manifest or shared package.
• If evaluating Agent Bridge, enable it deliberately for the test user and review its per-agent authorization. Packaging does not enable it or configure an organization's Agent permissions.

Commercial use and feature access

The Free tier is for personal, non-commercial use. Managed delivery of the binary does not grant organization-wide Pro rights. Review the current pricing and license terms before using it commercially. Registration provides the existing seven-day Pro trial; it is not evidence of a completed installation or a volume-license agreement.

This workflow does not claim managed preference keys, centralized license assignment, MDM configuration profiles or automatic SSH connection provisioning. Agent Bridge is available in the direct-download build used by these recipes; it is excluded from TestFlight and Mac App Store builds.

Troubleshooting without weakening the checks

Parent trust verification fails

Inspect the changed parent recipe and processors. Update trust information only after reviewing and accepting those changes. See AutoPkg's parent trust documentation.

The signing requirement fails

Stop the import and check the selected release, downloaded artifact and expected publisher identity. Do not remove CodeSignatureVerifier or replace the expected Team ID just to make the run pass.

The app was imported but is not offered to clients

Check your Munki catalog generation, test manifest and client eligibility. The recipe imports content; client distribution remains your Munki configuration's responsibility.

Evidence and next steps

The published repository records a download-recipe test with AutoPkg 2.9.1 and Nexus Shell 1.6.9. This article additionally checks the current recipe definitions, including the Munki import defaults. It does not claim a new end-to-end run on the latest release or validation in your fleet.

Use the official recipes and deployment checklist for review. If you are evaluating a single Mac first, download the app below. For your first server task, see remote file editing or remote Docker troubleshooting.