helium-linux: the packaging and build tooling behind the Helium browser for Linux

The packaging repository, not the browser

The first thing to get straight is what this repository is. helium-linux is described as Linux builds, packaging and development tooling for the Helium Browser, and the browser itself lives in a separate repository, imputnet/helium. The distinction is not pedantic, because the two have different licences, different contribution guides and different change histories.

The repository layout reflects the split. There is a `helium-chromium/` directory holding the browser sources, a `patches/` directory for the changes applied to them, and a `scripts/` directory with the build, package and release automation. `downloads.ini` and `flags.linux.gn` are the Chromium build configuration, `revision.txt` records the upstream revision being built, and `pubkey.asc` is the signing key for the distribution channels. `docker/` holds the build image definition and `package/` the packaging material.

There is also a `LICENSE` and a separate `LICENSE.ungoogled_chromium`, and the difference between them is the interesting part. The licensing statement says that all code, patches, modified portions of imported code or patches, and any other content that is unique to Helium and not imported from other repositories is licensed under GPL-3.0, while any content imported from other projects retains its original license, and it gives the example that unmodified code imported from ungoogled-chromium remains under their BSD 3-Clause license.

So this is a repository of patches, scripts and build definitions, which is why it is written mostly in shell.

The Flatpak refusal is the most opinionated thing here

Before the install instructions, there is a note that tells you what the project will not do. Flatpak and Flathub are not supported, and the reason is given as a condition rather than a preference: the project will not support Flatpak as long as it is impossible to package Chromium without breaking its sandbox, and it links a discussion on that question. Where an official distribution package is not available, the recommendation is to use the AppImage.

That is a good example of a packaging project making a technical argument instead of a political one. The linked discussion is where that argument is made.

There is a second note at the top of the download section that deserves attention: packaging not listed there is not officially maintained and should be used with extreme caution. That is a warning about community packages, and it is the kind of statement that saves somebody from installing an unofficial build of a browser.

For scale, the project offers builds for `x86_64/amd64` and `arm64/aarch64`, so both Intel and ARM systems are covered by the official channels.

Installing from a COPR or an apt repository

The two distribution channels are documented in full, and they are the same shape as any native package repository, which is part of the point.

On Fedora, you enable the Helium COPR and install the package:

sudo dnf copr enable imput/helium

sudo dnf install helium-bin

On Debian and Ubuntu there are three steps. The signing public key is added first:

curl -fsSL https://raw.githubusercontent.com/imputnet/helium-linux/main/pubkey.asc | sudo gpg --dearmor -o /usr/share/keyrings/helium.gpg

Then the repository is added, with the architecture list and the `signed-by` keyring path:

echo "deb [arch=amd64,arm64 signed-by=/usr/share/keyrings/helium.gpg] https://pkg.helium.computer/deb stable main" | sudo tee /etc/apt/sources.list.d/helium.list

For prerelease builds, the documentation says to replace `stable` with `prerelease`. And then the install is:

sudo apt update && sudo apt install helium-bin

The two channels are worth comparing. The apt repository is hosted at the project's own domain, `pkg.helium.computer`, with a key you fetch from the repository itself and a signed-by pin in the sources line, so the trust root is the key in the repository rather than a distribution's signing infrastructure.

For everyone else, there are AppImages and binary tarballs on the GitHub releases page, and the README says plainly that the AppImage is the recommendation when no official distro package is available.

The build runs in Docker so your distribution stays clean

Building Chromium is famously dependency-heavy, and this repository's answer is to not ask you to solve that on your own machine.

To build the binary, you run `scripts/docker-build.sh` from the repo root. The script does two things. It creates a Docker image of a Debian-based building environment with all required packages included, llvm, nodejs and distro packages. And it runs `scripts/build.sh` inside that image to build Helium.

The documentation is explicit about the alternative: running `scripts/build.sh` directly will not work unless you are running a Debian-based distro and have all the necessary dependencies installed, and the stated reason for the container is that the repo is designed to avoid having to configure the building environment on your Linux installation.

There is a development variant too. By default the build script uses a tarball, and if you need to use a source tree clone you can run `scripts/docker-build.sh -c` instead, which the documentation says may be useful if a tarball for a release is not available yet. That is a small detail with a large practical consequence for a contributor working between upstream Chromium revisions.

Packaging comes after the build. `scripts/package.sh` is the straightforward route, and `package/docker-package.sh` builds inside a Docker image instead. Either of them creates `tar.xz` and `AppImage` files under `build/`. If you also want a `.deb` file, you set `MAKE_DEB=1` when running the release script.

Signed artefacts, and which ones

The signature section is short and specific, and the specificity is the point.

AppImage builds are signed since 0.5.7.1, binary tarballs since 0.7.7.2, and the `.deb` repository since 0.10.7.1, and all three are signed with the same key, whose PGP public key block is included in the readme with the comment identifying it as the Helium signing key and giving the address [email protected].

That last detail is what makes the block useful. A user who wants to verify an AppImage needs the key, and the key needs an identity they can check, and the identity in the comment is the bridge between the two. The readme also links the key through to the project's own site.

The same key material is in the repository as `pubkey.asc`, which is the file the apt instructions fetch. So the trust path is: the key in the repository, the key block in the readme, and the identity in the comment. A user verifying the .deb repository can compare the key it was told to trust against the one published, and both point at the same address.

The channel matrix also tells you something about the project's history. The AppImage channel was signed first, then tarballs, then the deb repository, so the deb repository is the youngest of the three, which is a reasonable order for a project that started with a tarball and grew into a distribution.

Where helium-linux is the wrong tool

The boundaries are mostly about scope, and one of them is a hard commitment by the project.

The first is the Flatpak question, which is not a limitation but a refusal. If your Linux workflow is built around Flatpak, this project will not meet you there, and the reason is one you should verify rather than accept, because the linked discussion is where the argument about Chromium's sandbox inside Flatpak is made. If that argument holds for your distribution and your use case, the AppImage is the alternative the project points to.

The second is that this is not where the browser's changes live. The patches are here, but the application source, the issue tracker for the browser itself and the contribution guide are in the main repository, and the README says to read the main repo's `CONTRIBUTING.md` before contributing to this one. A contributor who wants to change browser behaviour is in the wrong repository, and the packaging repository has a narrower remit: making the built artefact installable and signed.

The third is the licence split, and it is a real thing to check rather than a footnote. Helium's own code and patches are GPL-3.0, while unmodified code imported from ungoogled-chromium stays under BSD 3-Clause, and the project keeps a separate `LICENSE.ungoogled_chromium` file for it. The credits section also says the repo uses some things that originally came from ungoogled-chromium-portablelinux before it was fully remade and forked for Helium, so there is imported code with a history that a licence audit should look at rather than assume.

The fourth is the unofficial packaging warning. Anything not listed in the download section is not officially maintained and should be used with extreme caution, which is a reminder that a browser distribution is a security boundary and that the supported channels are the ones with a signature.

Releases measured in days, and sponsored runners

The release record says the project is moving quickly and reliably. Version 0.19.1.2 was published on 2026-10-08, 0.19.2.1 the same day, and 0.19.3.1 on 2026-10-14, with the last push to the repository carrying the same timestamp as the newest release. Three releases in a week for a browser build is a fast cadence, and the four-part version numbers, three components plus a revision, match the Chromium build model where the upstream revision changes constantly.

The infrastructure behind that cadence is credited in the readme. Depot sponsors the runners that handle the Linux builds of Helium, and the description of their high-performance infrastructure is that it lets the project compile, package and release new builds within hours, not days. That is a concrete explanation for the release frequency, and it is worth noting that a browser release pipeline depends on paid infrastructure, which is a cost the project carries rather than passes to users.

The licence for the Helium-specific content is GPL-3.0, as described above. For a user, the practical summary is that the Helium changes are copyleft and the imported Chromium derivative keeps its own terms, and that the artefacts you install are signed with a published key.

For contributors, the entry point is the main repository's contributing guide, and the packaging repository's own contribution path is the scripts and the Docker image definition, which is where a change to the release process or the apt repository layout would go.

Editorial conclusion

helium-linux fits a Linux user who wants the Helium browser as a normal package, an AppImage, or a tarball, and it fits a contributor who wants to build the browser without assembling a Chromium build environment by hand. It does not fit a user who wants a Flatpak, because the project refuses to ship one while Chromium's sandbox cannot survive that packaging, and it is the wrong place to look for the browser's own source and changes. Before you install, check which channel you want, since the apt repository offers a prerelease track, and note that code imported from ungoogled-chromium keeps its BSD 3-Clause terms while Helium's own changes are GPL-3.0.

Frequently asked questions

Official sources

1. imputnet/helium-linux on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases