Harbour puts Portainer on iPhone, iPad and Mac, with two gaps left open

Harbour is a remote for Portainer, not a Docker client of its own

The dependency stated at the top of the README is the whole architecture in one line: Portainer is required to use Harbour. That rules out the obvious misreading. This is not an app that talks to the Docker daemon over a socket or installs its own container runtime on the device, because iOS and iPadOS cannot do that and macOS would not benefit. It is a management client for a Portainer deployment, reachable from several servers and endpoints, and the app links back to Portainer from the interface. So the person who benefits is an operator who already treats Portainer as the control plane for their Docker hosts and wants a phone-sized view of it: health, environment variables, labels, mounts, networks, logs, and start and stop actions. If you have no Portainer instance, there is nothing to connect to and the app has no purpose.

Two unchecked boxes decide how far you can go with containers

The feature list is written as a checklist, and the unchecked items are the ones that carry the most information. Under containers, displaying details, inspecting logs, managing state and removing containers are marked done, while deploying new containers and editing existing containers are not. In practice that means you can look at a container, read its logs, stop it, start it, restart it and remove it, but you cannot create one or change its definition from the app. For a monitoring and triage workflow that is enough. For a developer who wants to spin up a stack while away from a laptop, it is a hard stop, and no workaround is described. The same list also marks stacks as fully covered, with details, state management, deployment, editing and removal all done, which draws a clear line between the two document types.

Stacks are the part of the feature set that is finished

Contrast the container row with the stack row and the project's priorities become visible. Stacks support displaying details, managing state, deploying new stacks, editing existing stacks and removing stacks. Deploy and edit are the operations that are missing for containers and present for stacks, which suggests the authors considered creation an editing concern and were willing to implement it first where the Portainer API exposed it more directly. For a team running compose-based services, that is the interesting half of the app, since a stack is usually the unit you actually want to push and change. It also means the app covers two different lifecycle shapes at different depths, and a review of the API surface behind the Portainer client would be the way to understand why.

The Apple integrations are the reason to build this in SwiftUI at all

Beyond the Docker operations, the checklist spends a lot of space on platform integration: widgets, App Intents and Shortcuts, Handoff, background notifications, Spotlight integration and multiple servers and endpoints. This is where an Apple-native client differs from opening Portainer in a browser. Notifications push container state changes to the device, so a failing container can surface without launching the app. App Intents and Shortcuts expose actions to the system, which is what makes the app usable from a Siri-style invocation rather than only from its own windows. Widgets put the same information on the home screen. Handoff and Spotlight handle continuity and system-wide search. None of these are container features, and all of them are listed as complete, which is the clearest indication that the project is as much an Apple app as a Docker client.

No telemetry, and the data path runs through your own Portainer

One line in the feature list is worth pulling out on its own: no telemetry. Combined with the requirement that Portainer be present, this means the sensitive material, the connection details for your Docker hosts and the environment variables inside your containers, travels between your device and a Portainer instance you control rather than to a vendor backend. The read-back side is the same story, since the app displays environment and label data straight from what Portainer exposes. That also sets expectations for connectivity: the same-server convenience of a local tool does not apply, and a remote Portainer has to be reachable from wherever the phone is. The documentation in the repository does not describe network requirements, TLS handling or how credentials are stored on the device, so those are the details to confirm before rolling the app out widely.

Three ways to get Harbour, and one undocumented step

Installation follows the usual Apple distribution route, with an App Store download linked from the README, and the project also accepts the community distribution path for people who cannot use the store listing. The README lists two alternatives under that heading. The first is to sideload the .ipa from the GitHub releases, which gives you the most recent published build without a compiler:

Sideload the .ipa artifact from the releases page of the repository, then install it on the device through the usual sideload tooling.

The second alternative is to build it yourself, and this is where the documentation thins out. The README states the option without giving commands, and the repository layout shows what a build would involve: an Xcode project named Harbour.xcodeproj, the main app source in Harbour, a separate widget extension in HarbourWidgets, shared code under Shared and Modules, a SwiftLint configuration, fastlane for release automation, and scripts and ci_scripts directories for automation. There is also a .gitmodules file, which is where Git submodule definitions live, so third-party code is pulled in that way rather than vendored. Anyone building from source has to supply their own Apple signing identity and provisioning.

An AGPL licence on a client that talks to your own infrastructure

Harbour is released under the AGPL-3.0 licence. That matters more than usual for a client application: AGPL reaches network use, so offering the application to users over a network triggers the source-sharing conditions, and the distinction between modifying and merely using it is the part to read carefully in the licence file rather than assume. The licence covers the code in this repository, and it says nothing about Portainer, Docker or the container images you point it at, which keep their own licensing. On maintenance, the last push was on 2026-07-23, and the recent tags are v4.2.9 from 2026-05-02, v4.2.8 from 2026-04-26 and v4.2.7 from 2025-11-25. The gap between the 2025-11-25 release and the spring 2026 ones shows a project that ships in bursts rather than on a fixed schedule, so pinning a version and reading the release notes before upgrading is the sensible habit.

Editorial conclusion

Harbour suits operators who already run Portainer and want to check container health, read logs and manage stacks from an iPhone, iPad or Mac without opening a browser. It is the wrong tool for anyone who needs to deploy or edit containers from the app, since those two boxes are still unchecked in the feature list. Before adopting it, confirm that your Portainer instance is reachable from your devices and check the version you install against the container actions the release notes mention.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. rrroyal/Harbour on GitHub