Skip to content

Groups and Suggestions

melonfleet edited this page Oct 20, 2026 · 3 revisions

Groups and suggestions

A group is a saved, ordered set of containers that start and stop together — an app and its database, say. Suggestions are ready-made starting points: whole stacks created as groups, and single apps, volumes, networks, machines, clusters and DNS domains that fill in a form for you. They are covered below.

Groups

A group shows in the Containers list as one row — a half dot and "2 of 3 running" — with its members beneath it. See Containers for the row and its menu.

What a group is, and what it is not

A group is a remembered form submission, not an orchestrator. Starting one issues the same container run for each member that the Run form would issue for one container, through the same allowlist. It adds no new command to what Flotilla may run.

So a group has no health checks and no restart policy of its own — nothing keeps watching the group after the last command returns. Its only wait is the readiness port during a Start you asked for. There is no docker-compose.yml import either: a Compose file describes dependencies, health checks and scaling, none of which a group honours, and quietly dropping most of its meaning would promise more than Flotilla does. Groups and stacks can run on any host.

A member is still a container, and a container can have a policy. Open a member's page and set Restart and health on its Overview. It applies to that container alone, and the group does not know about it. A group's Stop counts as a deliberate stop, so it is not undone. See Containers. Flotilla cannot tell a crash from a clean exit, so the restart choice is if it stops unexpectedly, not on failure.

New Group

+ ▸ New Group… in Containers, or File ▸ New Group… (⌃⌘O). It works without container running: a group is Flotilla's own record until it is started.

  • Name — yours alone. It is never passed to container, and no container is named after it.
  • Network — chosen once, for the whole group, because networks are isolated from one another: a group spread across two would be a group whose halves cannot talk. It applies when a member is first created; one that already exists keeps its network until it is recreated.
  • Services — started in this order, top to bottom, and stopped in reverse. Each has the Run form's fields, plus From the Keychain and Ready when port answers, below. Its Name is required here: a group finds what it started by name, and an unnamed container gets a random one the group could never find again. A name another group uses is refused, since two groups each owning a db could never both run.

Add Service opens a picker first. Choose from:

  • the library's single-container suggestions;
  • the images on this Mac;
  • Blank Service, for an empty form.

A matching recipe fills in ports, environment and volumes. It matches only the same major version of the image: PostgreSQL 17 does not get PostgreSQL 18's settings, and an image with no version tag, such as latest, gets none.

Pick one for a form that is already filled in. Pick several to add them straight to the group, each with its own name, a free host port and its own password. Leaving the picker, or choosing Blank Service, cancels an add that is still preparing, so it can't add anything afterwards.

A service needs a host port that is a real port mapping. A pick with no free port is refused, with a message saying which services need one, rather than saved and failing at Start. A group saved earlier with a bad port is not lost: Flotilla keeps the service, drops that port and flags it. The flag shows in the Containers list, on the group's page and in its form. Start will not create that service until you choose a host port, or choose Keep Without It to keep it with no published port.

The Volumes field warns that a fresh named volume is owned by root, so an image that runs as a non-root user and does not fix that itself — Redis is one — fails to write to it, and stops.

Start, Stop and readiness

Start goes down the list. A member whose container already exists is started; one that does not is created, because container run would refuse a name already taken. A member that is already running is left alone.

Listed first means launched first, not ready first. A database takes a few seconds to accept connections, and an app started in that gap fails. So a member can name Ready when port answers: the port inside the container — 5432 for PostgreSQL, 3306 for MySQL or MariaDB — whether or not it is published. Start then waits up to two minutes for that port to accept connections before starting the next member. If it gives up, or the member stops while it waits, it says which service and port, and what was already started. There is no wait after the last member.

Only Start and Restart wait. Nothing watches the service afterwards, and if Flotilla quits half way, the rest are not started. It is a bounded check that says when it gives up, not a fixed pause that only looks as if it works.

Stop goes up the list, bottom to top, so an app stops before its database.

The group's running state is never stored. It is worked out from the live container list each time, so it stays right when someone stops a member from the list, the menu bar or Terminal.

Passwords

A member's From the Keychain variables hold a password's name, not its value. The value lives in this Mac's login Keychain and is read when the member is created. Two members may name the same secret, which is how an app and its database agree on a password nobody typed.

The group's Passwords section lists each one with Show, Copy and Generate New. Passwords never go into Flotilla's settings or an export. Every value is read before anything starts, so a missing one stops the group cleanly rather than half way through. A new password only matters for containers created afterwards, with fresh volumes: an existing database keeps the password it was set up with, and Flotilla says so first.

Save to File… writes the group as a configuration file, and says what it left out.

Suggestions

Suggestions is one section in the sidebar, under Overview. It has tabs: All · Apps · Stacks · Volumes · Networks · Domains · Machines · Clusters. Each tab shows how many suggestions match your search. There is no Images or Registries tab.

It is a split view, like the other lists: the suggestions on the left, the selected one's details on the right. Tick several for a summary. Search finds suggestions by name, category, image and licence.

Apps and stacks come from the suggestions library, which Flotilla checks daily (see Updates). Volumes, networks, domains, machines and clusters come from suggestions built into Flotilla.

Other ways in:

  • The search box (⌘K) finds suggestions of every kind from any page. Choosing one opens Suggestions on its tab with the row selected. It never creates anything. A tab with no match offers Show all matches.
  • + ▸ Suggestions… in Containers, Volumes, Networks, DNS, Machines and Kubernetes, the "start from a suggestion" links in empty lists, and File ▸ Suggestions all open the matching tab.

Using one

Use… opens the form for that kind, full width and already filled in: Run, the stack form, New Volume, New Network, New DNS Domain, New Machine or New Cluster. The filled-in values do not count as unsaved changes, so leaving without editing asks nothing. Nothing is created until you press the form's main action (▶ or ✓).

Close or finish a form, or visit another section, and you come back to the same tab, search, category, selection and Mac.

Tick several apps or stacks and use them in turn, one form each, marked "1 of N", with Skip under ⋯. If two want the same port, the later one gets a free port. Volumes, networks, domains, machines and clusters are used one at a time.

A name already taken moves on to -2, -3, and so on. A DNS domain does not: a domain that exists is the same domain, and the form says so.

The library's logos appear beside each suggestion, and on Containers and Images made from one. Machines and registries show their distribution's or registry's logo when the library has it.

Stacks

Five, each pinned to versions pulled and tested before release:

  • PostgreSQL + pgAdmin
  • WordPress + MariaDB
  • Redis + RedisInsight
  • MySQL + phpMyAdmin
  • Prometheus + Grafana

The stack form has a working default in every field, so ▶ works untouched:

  • Name — the start of everything it makes: blog gives blog-db, blog-site, blog-db-data and blog-net.
  • Network — a new one of its own, which keeps the stack apart, or an existing one.
  • <Service> on this Mac — the port each web page opens on, at 127.0.0.1 only, never your network.
  • Settings — the stack's few choices, such as database and user names.
  • Services find each other — decided by this Mac's DNS setting. With a domain in use for containers, services reach each other by name; without one, Flotilla publishes each database on the network's gateway, reachable from this Mac and its containers but never from your network.
  • Passwords — generated now and kept in the Keychain.

The rail shows what it will create and which images it pulls first. The stack is then left ready to start from its row in Containers, with Getting started notes on the group's screen, such as which account to sign in to pgAdmin with.

Where a recipe asks, a fresh volume is set up so an image that does not run as root can write to it. This happens only on a volume Flotilla has just created. It refuses a volume that already has data. pgAdmin, Grafana, Prometheus, RedisInsight and Redis keep their state in the container instead: it survives Stop and Start, but not Delete. Where a licence is not a permissive one — Redis and RedisInsight — the form says so.

Everything else

  • Volumes — PostgreSQL, MySQL or MariaDB and MongoDB data, each showing the path where the image expects it, because a volume mounted at the wrong path stores nothing.
  • Networks — an application network, a frontend tier and a host-only backend.
  • Domains — test and internal for container names, and host.container.internal as a host alias.
  • Machines — Alpine, AlmaLinux 9 and AlmaLinux 10, each booted on container 1.5.0 before release. Stock Ubuntu and Debian cannot be machines: Apple needs /sbin/init in the image. A machine can be made from a suggestion on This Mac only.
  • Clusters — Starter (2 CPUs, 2 GB), Standard (4 CPUs, 8 GB) and Disposable, which is removed when it stops.

Vulnerability reports

The library is scanned for known vulnerabilities once a day, in the cloud. Flotilla downloads the report, checks its signature, and matches it against your images on your Mac. Nothing about your Mac, your images or their names is sent.

Findings show on an image's page and on the page of a container made from it, in a Vulnerabilities card, and as a chip on image rows. They list critical and high findings, and say which have a fix in a newer version. To fix one, use a newer image: updating packages inside a container does not change the image, and is lost when the container is recreated.

Reports are advice. They never stop, pull, rebuild or restart anything. They cover the library's images only. An image you built or pulled from elsewhere has no card, which does not mean it has no vulnerabilities.

Clone this wiki locally