Outline on ARM: which build, and who maintains it?

An ARM64 label settles one compatibility question and leaves three harder ones open. It does not say who produced the executable, which source revision it came from, or who will ship the next security fix. When an old forum answer points at a community build, those questions decide whether the installation is defensible. Separate them before downloading anything.

Manager or client: pick the right artifact first

Outline ships a manager for administering servers and a client for connecting devices, and they are separate applications. The upstream repository distinguishes the two roles and links to their own installation channels. Installing a manager on a Raspberry Pi does not give you a client for that Pi. The two channels also update on different schedules. Both roles exist, so the question is which one the device is meant to play.

Check the current client channel for the operating system you run. A generic Linux entry is not an architecture matrix, and it is not a promise about every board. Read the download page as a list of what exists rather than a list of what should exist.

A historical issue asking for ARM support says nothing about what is published today. Treat it as a record of a past gap rather than a statement about the present. The channel you can download from is the only evidence that counts.

Which architecture does the installed system really run?

Record the release and the artifact under review, not just the board name. Match the executable and its native components to the target, because a 64-bit kernel can run a 32-bit userland and the label on the box will not tell you which.

The client source contains shared interface code and platform-specific components. Rebuilding only the interface is not a platform port, however cleanly it compiles. The native pieces are where the architecture actually shows up. A rebuild that only touches the interface will run and still fail on the native side.

uname -m and the package architecture of the installed system are the two facts that matter here. Read them on the device, not on the machine you are building from. A mismatch at that step invalidates every later comparison.

A community build adds a release owner

If the official channel has no supported artifact for your target, a community build becomes a deployment decision rather than an installation. Identify the publisher, the source revision, the changes from upstream and the build instructions.

Then ask how future fixes reach the installation. Updates may come from upstream, from the fork, or from a manual rebuild that someone has to remember to run. The third option is the one that quietly stops happening.

A current-looking repository says nothing about which revision produced a binary you already have. Compare the build instructions with what the artifact reports about itself. If the two disagree, the artifact is the one to distrust.

What a checksum does and does not prove

A checksum identifies particular bytes. A checksum published by the same unofficial builder does not make that builder the upstream project, and it does not tell you what those bytes contain. It answers whether the download arrived intact, which is a useful but narrow question. That is a property of the file, not of the person who published it.

A screenshot of a successful launch is evidence about one machine. It is not a review of the binary or of its update channel. Neither artifact substitutes for reading the source.

Keep an unfamiliar build away from production secrets until provenance and required privileges have been reviewed. Run it in a throwaway environment first, with its own account. That is cheap, and it converts an opinion into a test.

Decide whether this is an experiment or an appliance

An administrator may deliberately build reviewed source for a supported target and accept responsibility for dependencies, packaging and updates. That is a different support model from installing a maintained upstream artifact. For an unattended device, pick the model the responsible owner can sustain.

Record the artifact identity, the platform, the verification result and the update owner beside the deployment. The decision is complete when those agree, not when an ARM binary starts once.