Requirements and Install

Requirements and install

What you need

macOS 26 or later, on Apple silicon. Both, not either. Apple's container runtime requires them, so Flotilla does too. There is no Intel build and there will not be one.

Apple's container CLI, from apple/container. This release is built and tested against 1.5.0; the oldest Flotilla will start with is 1.0.0, and an admin offers Upgrade… for a host on anything older than 1.5.0. On the Mac you sit at, upgrading an older container is up to you. Flotilla drives that tool — it does not bundle it and does not replace it.

It will install it for you, though never silently. Installing container is a privileged package install that drops a launchd service, and an app that quietly escalates to install something is an app you cannot audit. So:

• On an admin Mac, first run (and the banner, later) offers Download and Install container 1.5.0. Flotilla downloads Apple's signed installer — about 118 MB, from apple/container's GitHub releases — checks it carries Apple's Containerization signature and notarisation, and hands it to Apple's Installer, where you approve it with your password. Then it offers the recommended kernel, which needs no password.
• On a host, there may be nobody at the keyboard, so the Flotilla Helper can install it. The Helper installs a package only if it is genuine Apple container, notarised, and exactly the version Flotilla asked for — never a downgrade. It can install that and nothing else, and only once the host's owner has switched the Helper on.

Nothing else. No account, no sign-in, no telemetry. Even the wordmark is drawn in SwiftUI rather than loaded as a webfont, because an app that promises no phone-home should not be requesting a font from a CDN. Flotilla reaches the internet only for reasons you can name: Sparkle reading Flotilla's update feed on an admin Mac, Docker Hub when you open its browser, Apple's package when you install container, and other Macs only once paired. About Flotilla lists every address and when.

Getting the app

Flotilla 1.5.0-beta.5 is in beta. Each release on GitHub Releases is signed with Developer ID and notarised, in four forms:

Download	For
Flotilla-<version>.dmg	Drag Flotilla to Applications
Flotilla-<version>.pkg	MDM and scripted installs — signed with a Developer ID Installer certificate
Flotilla-<version>.zip	The same signed, stapled app; also what Sparkle and the fleet use
Flotilla-<version>.tar.gz	The same app again, for scripted installs

There are no unsigned builds among them. Install Flotilla in /Applications, on every Mac. An update replaces the app where it is, so a copy run from a shared folder would rewrite that folder for every Mac using it.

After that, an admin Mac updates itself with Sparkle, asking you once before it checks by itself. Betas come only on the pre-release channel, chosen in Settings ▸ Updates. A host is updated by its admin, one host at a time when each is idle, and never checks on its own. See Updates.

Why there is a .pkg at all

A .pkg can place the app, register it properly, and be signed and notarised as a unit. It is also the format a managed Mac can deploy without a human dragging an icon. Since the app is intended to work on both an individual's Mac and a managed fleet, the format that serves a fleet matters as much as the one that serves a single Mac.

That used to be an argument for shipping only a .pkg. It stopped being one when Sparkle arrived: Sparkle and the fleet update a Mac from a signed zip, and a DMG is still the friendliest way to install a single Mac. So there are four, each for its audience, and every one is signed.

The package installs Flotilla only. It does not install container — Flotilla offers that itself, as above, and a Jamf fleet usually manages the runtime separately.

Building it yourself

git clone https://github.com/melonfleet/flotilla.git
cd flotilla
Scripts/make-app.sh
open build/Flotilla.app

make-app.sh assembles a real app bundle — bundle identifier, Info.plist, icons, version stamping — and signs it ad-hoc. That is fine for local use. Three consequences worth knowing:

• macOS may refuse login-item registration for an ad-hoc-signed bundle. "Launch at login" can therefore fail to stick. That is macOS being correct, not Flotilla being broken.
• Gatekeeper will treat it as unsigned software, because it is.
• The Flotilla Helper will not work. It accepts only a Developer ID-signed app of its own team, so an ad-hoc build cannot use it — no DNS domains, no automatic container install on a host.

See RELEASING.md in the repository for the signed-and-notarised path, which needs a Developer ID Application certificate, a Developer ID Installer certificate for the .pkg, and a stored notarytool credential. See also Building from source.

The Flotilla Helper

The Helper is a background service, and optional. It carries out the few jobs that need root: DNS domains, the fleet's name resolution, installing Apple's container, and installing a Flotilla update on a host. A signed copy of Flotilla registers it at launch. Approve it once in System Settings ▸ General ▸ Login Items & Extensions. A configuration profile can pre-approve it on a managed Mac. See Flotilla Helper.

A host's one click

A new host needs one click on macOS's local network prompt before an admin can reach it. Local network access is a per-user setting that neither a configuration profile nor MDM can grant, and Flotilla's host listener runs inside the app because container needs a user session. So even a fully managed host needs that click once.