Manjaro Linux Release History: Arch Base, Branches, Pamac, Updates

Manjaro Linux is a rolling release distribution built on Arch Linux that does not use Arch's repositories directly. Packages land first in Manjaro's own unstable branch, move to testing, and reach stable in tested batches, so a stable Manjaro system runs a little behind Arch on purpose. The numbered releases, from 0.8.0 in August 2012 to 26.1 "Bian-May" in August 2026, are installer snapshots, not versions you upgrade between.

That design is the whole story. Manjaro's history is a series of installer snapshots on top of one continuously updated system, three repository branches that act as a staged rollout, a graphical package manager (Pamac) that also reaches the Arch User Repository, Flatpak and Snap, and a hardware layer (mhwd and mhwd-kernel) that lets you keep several kernels installed side by side. This post walks through each of those with dates taken from Manjaro's own announcements, explains where the model bends (the AUR, partial upgrades, website certificates), and ends with a step by step routine to verify an ISO, switch branches, update and roll back.

Key takeaways

• There is one supported system: an up to date one. Manjaro's own 2012 explainer said that if your installation is updated, "you already have the latest release". Release numbers mark install media.
• Manjaro is Arch based but not Arch. Its AUR wiki page states it is "not possible" to use Arch's official repositories in Manjaro; it runs its own.
• Three branches form a staged rollout. The Switching Branches page says unstable is synced "several times a day" with Arch, and stable packages have had "roughly a couple of weeks" of testing.
• The current release is 26.1 "Bian-May". It was announced on 12 August 2026; the official x86 ISOs ship a Linux 7.1 kernel, and Plasma, Xfce and GNOME are the three desktops on the main download page.
• Stable is paused right now. The 7 September 2026 stable update put stable into "a frozen state" while the project moves from GitLab to Forgejo. Testing and unstable updates continued into October.
• The AUR is outside Manjaro's support. The wiki says to use it at your own risk, and AUR build scripts target Arch, whose libraries can be newer than Manjaro stable's.
• Kernels are a choice, not a default you are stuck with. mhwd-kernel installs extra kernel series next to the current one. The September 2026 stable thread recommends the 6.12 LTS, 6.18 LTS and 7.2 series.
• Website certificates expired more than once. Users reported expired TLS certificates on manjaro.org in October 2021, February 2026 and August 2026, and a March 2026 team manifesto names the issue. Package signatures are a separate trust path.

When did Manjaro start, and who runs it?

The ArchWiki's list of Arch-based distributions dates Manjaro to 2011. The earliest public release announcement we could retrieve from Manjaro itself is later: on 20 August 2012 the project posted "Finally! Manjaro XFCE edition is released", offering Manjaro 0.8.0 Xfce for both i686 and x86_64. That post explains the quiet period before it: the team "kept the public mostly in the dark" while building its own distribution framework, with one root server for the main repository and four official mirrors carrying "tested snapshots of Archlinux with our own packages in the mix". So the 2011 start date and the first downloadable 0.8.0 image are a year apart. When you see "first release 2011" elsewhere, treat it as the project start, not a dated release announcement we could verify from Manjaro's own pages.

The About Manjaro wiki page describes the project as "developed in Austria, France, and Germany", based on "the independently developed Arch operating system", and notes that Manjaro "officially only offers a 64-bit version" today. The 32-bit images in that 2012 post are long gone.

On ownership, the footer of manjaro.org reads "Copyright 2026 Manjaro GmbH & Co. KG". The company holds the brand and website; the work of packaging, testing, forum moderation and the wiki is done by a small team and a volunteer community. That relationship is currently under open discussion. In March 2026 team members posted a Manjaro 2.0 Manifesto in the announcements category proposing that "the Manjaro Project will split off from the Manjaro GmbH & Co KG" and become a non-profit registered association (an e.V. under German law). We did not find a forum announcement confirming that the association has been formed as of 25 October 2026, so read it as a proposal in progress, not a completed change.

How does Manjaro relate to Arch Linux?

Three facts define the relationship:

1. Same packaging base. Manjaro uses pacman, the same package format and largely the same package builds as Arch. The Switching Branches page says "only a subset of Arch packages are modified to suit Manjaro", and that unmodified packages synced from Arch "are considered stable as they have already been vetted by Archlinux Community".
2. Different repositories. Manjaro mirrors carry Manjaro's branch snapshots, not Arch's live repositories. You cannot point a Manjaro install at Arch's mirrors and stay supported.
3. Separate support. The ArchWiki carries a plain warning that Arch-based distributions "are not supported by the Arch community or developers". Manjaro questions go to the Manjaro forum, not Arch's.

Manjaro adds its own packages on top: kernels in many series, the mhwd hardware detection tool, Pamac, Manjaro Settings Manager, themes and the release package that names your install media. The About page lists the additions as a simpler installer, automatic hardware detection, automatic driver installation, "its own dedicated software repositories" and support for multiple kernels.

How do the stable, testing and unstable branches work?

The Switching Branches page describes three branches. Here they are in the order a package travels:

Note the subtlety the wiki adds about unstable. Unmodified packages from Arch arriving in unstable are not themselves "unstable"; they have already shipped in Arch. What is untested is the combination with Manjaro's own packages, especially kernels and kernel modules. That is why most real breakage reports on Manjaro involve drivers, kernel modules and desktop integration rather than plain applications.

How long are packages held back from Arch?

There is no fixed number of days in the current documentation. The wiki's wording is "roughly a couple of weeks" before stable. In practice the hold is set by batches, not a timer. A useful way to see this is to compare announcement dates in 2026 from the announcements category:

The gap between a testing snapshot and the stable push is often a few days. The longer delay is upstream of that: a package first appears in Arch, then in unstable, then sits in testing across one or more snapshots before a stable batch is cut. Add those stages and "a couple of weeks" behind Arch is a fair typical figure, with large stacks (a new Plasma or GNOME series, a new Python, a toolchain bump) held longer, and urgent fixes sometimes moved faster. Because the delay is variable, the practical rule is not to count days but to read the stable announcement thread before each update.

The September 2026 stable freeze

The 7 September 2026 stable update called itself "the second point release of 26.1 series" and added that it "sets Manjaro Linux into a frozen state for a while" until the GitLab instance is migrated to a new Forgejo instance. As of 25 October 2026, the announcements category shows testing threads into October (the latest dated 7 October 2026) and an October unstable thread, but no newer stable update. Two practical consequences follow. A stable system today is roughly seven weeks behind the September Arch package set. And anyone who needs a fix that has already reached Arch must decide between waiting, moving to testing, or installing a specific newer package, which creates a partial upgrade. We cover how to make that choice safely below.

A dated timeline of Manjaro releases

Release dates in this table come from Manjaro's own announcements: the old manjaro.org blog (read through the Internet Archive, since the old URLs no longer resolve) and the current forum's release category. Where a third party tracker lists a different day, we say so. Forum timestamps are in UTC, which explains most of the one day differences.

Three patterns stand out. First, the 0.8.x numbering was explicitly a beta marker. A December 2012 post said the leading zero showed the project "has not yet reached an officially stable first release", and that a graphical installer would come with later numbers. Second, from 2016 Manjaro used year.month style numbers with a codename, then later moved to its own major.minor numbering (20.1, 21.0, 22.0 and so on) that roughly tracks the year. Third, release spacing has stretched. In 2021 there were three new series; in 2025 only one (Zetar, April), and 26.0 followed in January 2026.

What release numbers do and do not mean

The December 2012 post is still the clearest statement of the model. Manjaro "uses a Rolling Release Development Model, whereby rather than being replaced, the same core system will instead be continually updated". A machine installed from 21.0 in 2021 and updated every week is the same system as a fresh 26.1 install, apart from configuration defaults that the installer sets once (themes, default applications, filesystem layout). There is no "upgrade to 26.1" step. The release package (manjaro-release) on an updated system will report the current series because the stable branch ships it.

Editions, installers and ARM images

Desktop editions

The x86 download page presents three main desktops: KDE Plasma ("one of the most advanced desktops"), Xfce ("a lightweight desktop") and GNOME. On 25 October 2026 the page links 26.1.0 ISOs for all three, each built on 12 August 2026 with the linux71 kernel package, and older 25.0.3 builds (dated 9 June 2025, linux612) for community desktops such as Cinnamon and i3. The About page explains the gap: community editions "are not subject to the same release schedules, and will only be developed when the time and resources are available".

Xfce was the original and long time flagship. The 0.8.0 post shipped only Xfce, and the 17.0 Gellivara announcement still called "the Xfce edition" the "flagship offering". Plasma and GNOME followed as official editions over time. The 26.0 and 26.1 announcements spend most of their space on GNOME and Plasma changes, which shows where current effort sits.

Because the install media are just snapshots, an older community ISO is not unsafe in itself. It simply means a larger first update. A 25.0.3 Cinnamon install will download a year or more of updates on its first pacman -Syu, including a kernel series change, so the first boot after install deserves the same care as any large update.

Installer milestones

Manjaro's installer history is a useful map of how Arch derivatives made Arch approachable:

Calamares is a distribution independent installer framework; its site says it aims to be "distribution-agnostic" and is now developed on Codeberg. Using a shared installer means Manjaro benefits from fixes other distributions contribute, and also inherits its release cadence. Thus and Calamares overlapped for a while: a 22 June 2017 stable update title still mentions both.

ARM images

The ARM download page is maintained by "the Manjaro ARM Team" and lists device specific images, including generic and generic EFI images, Raspberry Pi boards, Pinebook Pro, PinePhone and PinePhone Pro, several Odroid, Orange Pi, Khadas and Radxa boards and Quartz64 models. ARM images follow the same branch idea but are built per device, with board specific kernels and bootloaders. If you run Manjaro ARM, check the ARM page for your board rather than assuming the x86 release numbers apply; device images can trail or lead the x86 media.

How Pamac, pacman, the AUR, Flatpak and Snap fit together

Manjaro gives you several ways to install software. They are not equal in who builds the software, who signs it, and who supports it.

pacman and Pamac

pacman is the Arch package manager and the base layer. Pamac is Manjaro's own front end. The Pamac wiki page describes it as "Manjaro's Package Manager", "based on libalpm with AUR and Appstream support", and lists its packages: pamac-gtk (GTK4), pamac-gtk3, pamac-cli, libpamac, and integration packages for Plasma and GNOME. Because Pamac uses libalpm, the same library pacman uses, both tools read the same package database and cache. You can use either, but not at the same time; they share a lock.

Two Pamac specifics matter for safe updates. The wiki warns "Do not use sudo with pamac"; Pamac asks for elevated rights itself when needed, and running it as root can cause permission problems, especially when building AUR packages. And Pamac's "Ignore updates for" setting is described bluntly: ignoring updates for individual packages "will leave you in an unsupported 'partial upgrade' state", and "innocuous looking ignored packages" can leave a system unbootable.

Pamac also keeps old package versions in the cache, with settings for how many versions to retain. The wiki recommends keeping at least two unless you are short on disk space. That cache is your fastest rollback for a single bad package.

Pamac's "Enable downgrade" preference matters when you change branches; it lets Pamac move packages back to the versions your new branch carries.

Flatpak and Snap

Flatpak and Snap support in Pamac comes from plugins, libpamac-flatpak-plugin and libpamac-snap-plugin, enabled from the Third Party tab in Pamac's preferences. Manjaro's forum shows both plugin package names in update transactions and user troubleshooting threads, for example a 2023 thread where users reinstall both plugins after switching Pamac front ends. The supply chain point is simple: a Flatpak or Snap application does not follow Manjaro's branch hold. It updates on its publisher's schedule, through a different signing and distribution channel. That can be good (a browser fix arrives without waiting for a stable batch) or surprising (an application changes under a frozen stable branch). Track which applications on a machine come from which source.

The AUR and held back packages

The Manjaro AUR page opens with a warning box: "Use the AUR at your own risk! No support will be provided by the Manjaro team", and "When Manjaro is updated, AUR packages might stop working." It lists the risks: multiple versions of the same packages, out of date packages, broken packages, wrong dependencies, and "malicious packages (although extremely rare)". The Pamac page adds that AUR scripts "are created for Arch Linux by Arch Linux Users" and "have not been thoroughly vetted".

The Manjaro specific problem is timing. An AUR PKGBUILD is written and tested against Arch's current libraries. On Manjaro stable, those libraries can be days or weeks older. So an AUR package may:

• require a library version that Manjaro stable does not have yet, and fail to build or fail at runtime;
• build fine today against Manjaro's older library, then break when the stable batch moves that library forward (a soname bump), because the AUR package is not rebuilt automatically;
• push you toward installing a newer library by hand to satisfy it, which is a partial upgrade.

The safe pattern is to keep AUR use small, read the AUR page comments and the PKGBUILD before building (the wiki says Pamac "cannot tell you of any issues with build scripts"), rebuild AUR packages after large stable updates, and prefer a repository or Flatpak package when one exists.

How are kernels and hardware drivers managed?

mhwd-kernel and multiple kernels

Manjaro packages each kernel series separately: linux612, linux618, linux72 and so on, each with matching module packages. The Manjaro Kernels page documents the mhwd-kernel tool:

• mhwd-kernel -li shows the running kernel and lists installed ones.
• sudo mhwd-kernel -i linux66 installs a series and keeps the current one.
• adding rmc ("remove current") deletes the running kernel after installing the new one; the wiki recommends keeping the old kernel "even if only for a short time".
• sudo mhwd-kernel -r linux50 removes a series; the wiki warns not to remove the kernel you are running.

New kernels automatically get the extra modules your current kernel uses, and GRUB's "Advanced options for Manjaro Linux" menu lets you boot any installed kernel. Manjaro Settings Manager offers the same through a GUI with a "Recommended" tag; the wiki says LTS "is safest for most users".

The variety is a long standing Manjaro feature. The 17.0 announcement said nine kernel series were available, "ranging from the mature & rock-solid 3.10 series to the latest 4.10 release", plus two realtime series. The September 2026 stable announcement shows the current state: it lists 6.16, 6.17, 6.19, 7.0 and 7.1 as end of life and recommends 7.2, 6.18 LTS and/or 6.12 LTS, while introducing a 7.3 release candidate series. That last point matters for anyone who installed from the 26.1 ISO: the media shipped linux71, which the same thread lists as end of life, so a fresh install should move to a supported series soon after its first update.

Kernel end of life on Manjaro is announced, not automatic. If you stay on a series after its end of life notice, you stop receiving fixes for it. Check mhwd-kernel -li against the latest stable thread at least once a month.

mhwd and graphics drivers

The mhwd (Manjaro Hardware Detection) tool installs driver configurations. Per the graphics card wiki page, sudo mhwd -a pci nonfree 0300 auto installs the best proprietary driver for a PCI graphics card (class 0300), sudo mhwd -a pci free 0300 installs the open source one, and mhwd -l -d lists available configurations in detail. The wiki notes that mhwd "is only able to install drivers for graphics cards connected internally via pci".

Drivers are where branch delays and kernel choices collide. The September 2026 stable thread includes a clear example: the NVIDIA 590 driver dropped support for Pascal (GTX 10xx) and older GPUs, and the thread says that updating on such systems "will fail to load the driver". Owners of those cards had to switch to a legacy driver package before or during the update. This is the kind of note you only see if you read the announcement first.

What operational incidents shaped the project?

The most visible recurring incident is not a package compromise; it is expired website certificates. We describe it here as a lesson in separating trust paths, not as blame.

The March 2026 Manjaro 2.0 Manifesto lists "the TLS certificates not being renewed in time" as a known issue that team members had volunteered tooling and processes to fix. In the August 2026 thread a forum member suggested that renewal be automated "or at minimum, set a reminder before it expires". The certificates in question were short lived, automatically renewable ones, according to the February 2026 report.

Three lessons are worth taking from this for any project or company:

1. Automate renewal and alert on expiry independently. A renewal job that silently fails is the usual cause. An outside check that warns 14 days before expiry catches it.
2. Do not let website TLS be the only integrity check for downloads. Manjaro publishes .sig and .sha256 files beside each ISO and documents GPG verification. Packages are verified by pacman against the manjaro-keyring. A broken TLS certificate on the website does not break those checks, and a valid certificate is not a substitute for them.
3. Treat infrastructure changes as release events. The September 2026 stable freeze during the GitLab to Forgejo move is the same lesson at a larger scale: when the build and source infrastructure moves, publish what is paused, for how long, and what users should do meanwhile. Manjaro's stable thread did state the freeze; the remaining gap for users is the open end date.

Manjaro, Arch, Arch derivatives and Linux Mint compared

For Arch's monthly ISOs, signing and archive based rollback, see our Arch Linux release history. For Mint's Ubuntu bases and support dates, see our Linux Mint release history. For a source based contrast with profile driven updates, see our Gentoo release history.

The key trade off for Manjaro is clear from the table. Its delay buys a buffer against the occasional broken Arch update and gives Manjaro time to match kernels, modules and drivers. The cost is that a security fix already in Arch also waits, and AUR packages built for Arch may not match. Whether that trade suits you depends on whether you prefer a short buffer or exact Arch currency.

Step by step: verify, switch branches, update and roll back

The commands below use the 26.1.0 KDE Plasma ISO as an example. Replace the file names with the edition you download.

1. Download and check the ISO checksum

mkdir -p ~/manjaro-iso && cd ~/manjaro-iso
ISO=manjaro-kde-26.1.0-260812-linux71.iso
BASE=https://download.manjaro.org/kde/26.1.0
curl -LO "$BASE/$ISO"
curl -LO "$BASE/$ISO.sha256"
curl -LO "$BASE/$ISO.sig"
sha256sum -c "$ISO.sha256"

sha256sum -c should print OK. On 25 October 2026 the published SHA-256 for this KDE image was 711b64362abe0b45348dc33bd4a2c654641e069b50ae9ae37c01771da880aa99. A checksum only proves the file matches the checksum file you downloaded from the same server, so also check the signature.

2. Verify the GPG signature

Manjaro's verification guide offers two ways to get the keys: import the developer keyring file from Manjaro's source host, or search a keyserver for "Manjaro Build Server". The keyring path in the wiki points at GitLab, which is being migrated to Forgejo, so check the current location if the link fails.

# Option A: the Manjaro developer keyring (path from the wiki; may move after the Forgejo migration)
curl -LO https://gitlab.manjaro.org/packages/core/manjaro-keyring/-/raw/master/manjaro.gpg
gpg --import manjaro.gpg

# Option B: the build server key from a keyserver
gpg --keyserver keyserver.ubuntu.com --search-keys "Manjaro Build Server"

# Verify
gpg --verify "$ISO.sig" "$ISO"

The output should say "Good signature". The 26.1.0 KDE signature we inspected was made by the key with fingerprint 3B794DE6D4320FCE594F4171279E7CF5D8D56EC8. Compare the fingerprint gpg prints with the key you imported and with Manjaro's own published keys, not with a value in a blog post, including this one.

3. Write the USB stick (destructive)

Warning: the next command erases the target device completely. Check the device path first.

lsblk -o NAME,SIZE,MODEL,TRAN,MOUNTPOINTS
# Confirm the USB stick, for example /dev/sdX, by size, model and TRAN=usb.
# Make sure none of its partitions are mounted, then:
sudo dd if="$ISO" of=/dev/sdX bs=4M status=progress oflag=sync

Never guess the device name. A wrong of= target overwrites a disk with no undo.

4. Check which branch you are on and how current your mirrors are

pacman-mirrors -G                # prints stable, testing or unstable
pacman-mirrors --status          # sync status of mirrors in your list
cat /etc/os-release
mhwd-kernel -li                  # running and installed kernels

The pacman-mirrors page documents status, country and branch options. A mirror that is behind can give you a mixed set of packages, so rank mirrors before a large update.

5. Read the announcement, then snapshot

Open the latest thread for your branch in the announcements category. Read the notes and the known issues at the top. Then take a snapshot. On a Btrfs root with a snapshot tool such as Timeshift or Snapper this takes seconds; on ext4, Timeshift's rsync mode or a plain backup of /etc and your home directory is the minimum.

# Example with Timeshift, if installed
sudo timeshift --create --comments "before stable update $(date +%F)"
sudo timeshift --list

6. Update

sudo pacman-mirrors --fasttrack 5
sudo pacman -Syu
# or with Pamac (no sudo; Pamac asks for rights itself)
pamac checkupdates -a
pamac upgrade -a

-a includes AUR packages when AUR support is enabled. Read the transaction summary before confirming, especially removals and kernel or driver changes. Reboot after kernel, systemd, Mesa or driver updates.

7. Change kernel safely

mhwd-kernel -li
sudo mhwd-kernel -i linux618     # install 6.18 LTS, keep the current kernel
sudo reboot
# choose the new kernel under "Advanced options for Manjaro Linux" if it is not the default
uname -r
# after a few days of normal use, remove the old series
sudo mhwd-kernel -r linux71

Do not use rmc on a kernel change you have not booted yet.

8. Switch branches, and switch back

# Move to testing to get a fix earlier
sudo pacman-mirrors --api --set-branch testing
sudo pacman-mirrors --fasttrack 5 && sudo pacman -Syu

# Return to stable later
sudo pacman-mirrors --api --set-branch stable
sudo pacman-mirrors --fasttrack 5 && sudo pacman -Syuu

The double u allows downgrades, so packages return to the versions stable carries. The Switching Branches page says that without it pacman will report "newer packages installed than available in the repo", which resolves itself once stable catches up. Either approach is valid; the downgrade is cleaner if a testing package is what broke.

9. Roll back

If one package broke something, reinstall the previous version from the cache:

ls /var/cache/pacman/pkg/ | grep '^mesa-'
sudo pacman -U /var/cache/pacman/pkg/mesa-<old-version>-x86_64.pkg.tar.zst

Replace the placeholder with the real file name. If several packages broke, restore the snapshot from step 5 instead; mixing one old package with many new ones is a partial upgrade and should only be a short bridge until the next stable update.

Common mistakes

• Mixing AUR packages built against Arch with held back libraries. An AUR package that needs a newer library than Manjaro stable has tempts you to install that library by hand. That creates a partial upgrade. Wait for stable, use testing deliberately, or use a Flatpak.
• Skipping the announcement thread. The NVIDIA 590 note in September 2026 is a typical case: the fix was in the thread, and the failure was a black screen for those who did not read it.
• Running pacman -Sy then installing a single package. The ArchWiki's system maintenance page says partial upgrades are unsupported and to "never run pacman -Sy; instead, always use pacman -Syu". The same applies on Manjaro.
• Ignoring packages in Pamac. The Pamac wiki says it leaves you in an unsupported partial upgrade state.
• Changing kernels without a snapshot or a fallback kernel. Keep the old kernel installed and bootable until the new one works for a few days.
• Staying on an end of life kernel series. The ISO kernel can be end of life by the time you install. Check the stable thread.
• Using sudo with Pamac. The wiki says not to; it causes permission problems in the database and build directory.
• Assuming a Manjaro bug report belongs on Arch's forums. Arch does not support derivatives. Report to Manjaro.
• Trusting a download because the site has a padlock. Verify the .sig file. Equally, do not panic about package integrity when the website's certificate expires; pacman's signature checks are separate.
• Forgetting that Flatpaks and Snaps update separately. A frozen stable branch does not freeze them.

FAQ

Is Manjaro the same as Arch Linux?

No. Manjaro is based on Arch and uses pacman and mostly the same packages, but it runs its own repositories with three branches, its own kernels and tools, and a deliberate delay before stable. Arch does not support Manjaro installs.

How far behind Arch is Manjaro stable?

The Manjaro wiki says stable packages have had "roughly a couple of weeks" of testing. It varies by batch. Since 7 September 2026 stable has been frozen during a GitLab to Forgejo migration, so today the gap is larger than usual.

What is the latest Manjaro release?

Manjaro 26.1 "Bian-May", announced on 12 August 2026. The ISOs are dated 260812 and ship the linux71 kernel package. Point updates to the 26.1 series arrive through the stable branch, not new downloads.

Do I need to reinstall Manjaro to get a new release?

No. Manjaro is rolling. An installation kept up to date with pacman -Syu or Pamac is already on the current release; new ISOs are only for new installs.

Is it safe to use the AUR on Manjaro?

It works, but Manjaro does not support it and says to use it at your own risk. AUR scripts target Arch's current libraries, which can be newer than Manjaro stable's. Read each PKGBUILD, keep AUR use small and rebuild AUR packages after large updates.

Should I use the testing or unstable branch?

Only if you can fix a broken system yourself and want to help test. The wiki calls unstable a branch for users who "have the skills to get themselves out of trouble". Most machines belong on stable.

Which kernel should I choose on Manjaro?

An LTS series. The September 2026 stable thread recommends 6.18 LTS and/or 6.12 LTS, or 7.2 for newer hardware. Install with sudo mhwd-kernel -i linux618 and keep your current kernel until the new one is proven.

How do I verify a Manjaro ISO?

Download the ISO with its .sig and .sha256 files, run sha256sum -c, import Manjaro's keys and run gpg --verify. Compare the signing key's fingerprint with Manjaro's published keys.

Why did the Manjaro website show certificate errors?

Users reported expired TLS certificates on manjaro.org and related hosts in October 2021, December 2021, June 2022, February 2026 and August 2026. These affect the website, not package signatures, which pacman checks against the Manjaro keyring.

Who owns Manjaro?

The website is copyright Manjaro GmbH & Co. KG. In March 2026 team members published a manifesto proposing a split into a non-profit registered association. We found no announcement confirming that change as of 25 October 2026.

Where Safeguard fits, honestly

Safeguard does not manage pacman, Pamac, mhwd or Manjaro's branches, does not verify ISO signatures and does not review AUR PKGBUILDs. The steps above are the right tools for that. The fit is one layer up. A Manjaro laptop or build host is where developers check out projects that pull npm, PyPI, Maven, Go and container dependencies that pacman never sees. Safeguard scans repositories, container images and SBOM files for those dependencies, matches them against vulnerability databases, ranks findings with reachability analysis and can open fix pull requests, which ship switched off by default.

A frozen stable branch is a useful reminder that waiting on someone else's release schedule has a cost. The operating system on a Manjaro machine is the distribution's job, but the open source dependencies and container images you build on it age on their own schedule, so software supply chain hygiene still matters here even though the fit with Manjaro itself is indirect.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

None of these demos touches pacman, Pamac or Manjaro's branches. They show the dependency and image side of the work you do on a Manjaro machine.

The first demo sets up the Safeguard runner on your own machine: install it, approve it with a device code, then scan from the terminal. On a Manjaro workstation or build host, that is how you would scan the repositories and container images you build there, independent of which branch the OS tracks.

Click through it at your own pace, or open it full screen.

The second demo is a real CLI session. You ask the assistant to fix a lodash CVE; it reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. The same flow applies to a project checked out on a Manjaro laptop: Manjaro's branches keep the OS moving, and this keeps the project's own dependencies moving.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which Safeguard tools Claude can use, so an assistant can answer questions about your findings from real data.

Click through it at your own pace, or open it full screen.

To try it on your own projects, download Safeguard and follow the CLI documentation.

Quick check

Sources

• Manjaro wiki: Switching Branches
• Manjaro wiki: About Manjaro
• Manjaro wiki: Manjaro Kernels
• Manjaro wiki: Configure Graphics Cards (mhwd)
• Manjaro wiki: Pamac
• Manjaro wiki: Arch User Repository
• Manjaro wiki: Pacman-mirrors
• Manjaro wiki: How to verify GPG key of official ISO images
• Manjaro: x86 downloads
• Manjaro: ARM downloads
• Manjaro home page
• Manjaro forum: announcements category
• Manjaro forum: Manjaro 26.1 Bian-May released (12 August 2026)
• Manjaro forum: Manjaro 26.0 Anh-Linh released (4 January 2026)
• Manjaro forum: Stable Update 2026-09-07
• Manjaro forum: Manjaro 2.0 Manifesto (9 March 2026)
• Manjaro forum: release announcements, 20.1 Mikah to 26.1 Bian-May
• Manjaro forum: Expired certificate on manjaro.org (28 October 2021)
• Manjaro forum: expired manjaro.org certificate posts (24 February 2026)
• Manjaro forum: manjaro.org certificate expired (23 August 2026)
• Manjaro blog (archived): Finally! Manjaro XFCE edition is released (20 August 2012)
• Manjaro blog (archived): Manjaro installation up to date? Then you already have the latest release (11 December 2012)
• Manjaro blog (archived): Manjaro 0.8.5 released (13 April 2013)
• Manjaro blog (archived): Manjaro Ellada finally released (31 August 2016)
• Manjaro blog (archived): Manjaro XFCE 17.0 released (7 March 2017)
• Manjaro download server: 26.1.0 KDE ISO checksum
• ArchWiki: Arch-based distributions
• ArchWiki: System maintenance
• Arch Linux news
• Calamares installer
• DistroWatch: Manjaro Linux

Last reviewed: 25 October 2026. Manjaro is a rolling release and its stable branch is currently frozen; check the announcements category for the latest stable update, kernel end of life notices and any change to the project's governance before acting on this post.