The wiki catches up with 1.5 beta 5: Tasks, form buttons, Suggestions tabs, Add Service, vulnerability reports, Greta (experimental), the list redesign and host tabs
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The wiki catches up with 1.5 beta 4: the fleet, notifications, Kubernetes and more
Every existing page keeps what is still true and gains what changed since
12 September (Dashboard is now Overview; Go To, the search grammar, groups,
registries, pushing to hosts, the Helper, the wire). Nine new pages: Hosts,
Notifications, Kubernetes, DNS, Registries, Groups and Suggestions, Sharing
and Export, Updates, and the Flotilla Helper. Checked against the code.
Drafted by Iris, deepened by Sonny, reviewed by Andy.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Flotilla keeps its capital F again
Reverts the lowercase change: only the app's drawn wordmark is lowercase (the owner, 10 October).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
flotilla is written lowercase, like the logo
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Correct the machine/container relationship — they are siblings, not nested
The central page said "a container runs inside a Linux virtual machine, that VM
is the machine", with a diagram of containers nested in a machine and a claim
that Set as Default "makes it the machine new containers run in". All of that is
wrong, and it was the page telling readers it was the one thing worth reading.
Measured on this Mac rather than reasoned about: with both machines stopped —
including the one marked default — a container ran normally, neither machine
started, and the container took its own address on the same bridge as them
(buildkit .6, machines .7 and .8, the new container .13). Sequential neighbours
on one network, not one thing inside another. `container run` has no flag for
choosing a machine, and a container's own inspect output never names one.
So each container gets its own VM, and a machine is a separate persistent VM you
create and shell into. The page now leads with that, shows the evidence, and says
plainly that the Machines section can be ignored entirely.
Two things it now refuses to claim. Set as Default: `container machine
set-default --help` says only "Set the default container machine" and does not
say what the default affects, so the page says that and stops, rather than
inventing a behaviour twice. And the old "a container cannot exceed its machine"
resource table is gone — a container's CPUs and memory are its own, because a
container is its own VM.
Added what a machine is *not*, since that is what sent the owner looking: the
rootfs is a container image and the kernel comes from Apple's runtime, which is
why images come from Docker Hub, why the disk reads tens of megabytes, and why
only alpine boots. Anyone wanting a real Ubuntu or Fedora VM is pointed at Lima,
UTM or Vagrant instead of being left to conclude the feature is broken.
Swept Home, Machines and First-Run for the same claim.
docs: correct two first-run claims that beta testing disproved
The page said the not-installed message points at apple/container. It does not —
it names the five directories it searched and nothing else. The link is in the
wiki now, and the real message is quoted verbatim.
It also said Flotilla offers to start a stopped runtime service. The detection
exists but nothing surfaces it, so a tester with the service stopped got no
warning at all. Recorded as a known gap with the workaround rather than left as
a promise the app does not keep.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
docs: the Flotilla wiki
Thirteen pages covering install, first run, each section of the app, the
security model, building from source, troubleshooting and an FAQ.
Written from verified behaviour rather than from the feature list: the machine
images that actually boot, why memory differs from Activity Monitor, why logs do
not follow, why eight settings are disabled and what each one says, and why the
terminal is a capability boundary rather than a convenience.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>