k3sm licensed apache-2.0 (DCO)

Support

k3sm is funded through GitHub Sponsors. Sponsorship buys more Macs to test on and a developer identity for signed installs, and this page says what it does not buy.


k3sm is Apache-2.0 and free. One person funds it, and this page is how to help.

Sponsor k3sm on GitHub

That is the only funding channel, and there is no tier system. The button above is GitHub’s own embed; this site runs no other third-party script and no analytics.

What Funding Buys#

Three things, in order of how much they change what ships next.

More Macs. The multi-node path runs on two machines, an M1 Ultra Mac Studio and an M2 MacBook, and nothing else. A second Mac joins over the wireguard mesh and gets its own agent daemon, which starts at boot, rejoins with the credential it stored at the join, and removes the node from the cluster when you uninstall k3sm on that Mac. NodePort and in-Pod cluster DNS work on the joined worker. Multi-node is experimental until v0.3. High availability is further off: a control plane spread over several Macs is not available in this release, because a second server cannot join yet and the installer does not expose the flags, so one Mac runs the control plane. Building and testing that takes more Macs than the project owns, and every additional Mac model and macOS version is a configuration it has not seen. Both paths are documented on multi-node and high availability.

An Apple Developer Program membership. Installing k3sm is curl -fsSL https://k3sm.io/install.sh | sh, which verifies a checksum and hands a release tarball to sudo k3sm install; a curl download carries no quarantine attribute, so that path needs no notarization. Releases are ad-hoc signed and not notarized, and the checksum shows the tarball arrived intact and says nothing about who published it. A notarized .pkg and a Homebrew tap planned both need a developer identity behind them, and the tap is not published, so Homebrew cannot install k3sm yet. Signing and notarization are what let a downloaded package run on a stranger’s Mac without a security-settings detour.

Time. Sustained hours go into a project that is one founding maintainer’s work.

What Sponsorship Does Not Buy#

  • Sponsoring buys no support contract and no service-level agreement. It creates no obligation to respond, to fix, or to keep anything working.
  • There is no roadmap influence and no priority queue. Sponsors do not get features moved up, and a sponsored issue is not triaged ahead of an unsponsored one. Technical decisions are made on the governance model, in public, on merit.
  • Sponsors get no private builds, no early access, and no sponsor-only features. Everything k3sm makes is Apache-2.0 and public on the day it lands.
  • There is no logo wall. GitHub renders the sponsor list on the profile, and this site does not turn sponsors into marketing.

Other Ways to Help, Which Cost Nothing#

Some of these matter more than money right now.

  • Run k3sm on your own hardware and report what happened, especially a failure. The project has a narrow hardware sample, and every new Mac model and macOS version is a data point it does not have.
  • Port a workload you depend on and write up where it broke. The gaps that matter are the ones found by someone who was not expecting them.
  • Fix a documentation page that was wrong or too flattering.
  • Argue with a design decision in discussions. The trade-offs are written down and open to challenge.

If you are considering commercial use and need something this page rules out, say so at kitsumiko@k3sm.io. The answer today is likely “not yet”, but the conversation is useful either way.