[Bug]: NO Linux app image

[Abdulee]

Before you submit

• I searched existing issues and confirmed this is not a duplicate.
• I replaced the example text with the real behavior, reproduction steps, expected result, and version from the app's About menu or od --version.

What happened?

Although the readme.md says there is a linux binary / appimage however I can't seem to find it in releases. Nothing no mention of linux there.

Steps to reproduce

Try installing on linux

Expected behavior

Nothing

Open Design version

0.10

Platform

Linux

Logs (optional)

Screenshots (optional)

No response

Additional context

No response

[open-design-bot]

🎉 ✨ Welcome to Open Design, @Abdulee!

✨ 🔥 Lit the spark.

🌱 Your first contribution adds energy to the project. Thanks for showing up and helping Open Design grow.

💛 Thanks for helping Open Design grow. Keep building in the open. 🚀

🔗 Share on X (English) · 分享到 X（中文）

[lefarcen]

Hey @Abdulee! 👋 Your observation is correct — the README lists Linux (AppImage, optional lane) under the download section, but no Linux asset is included in the current releases (v0.10.1, v0.9.0, and earlier). The "optional release lane" phrasing is intended to mean the AppImage isn't published on every release cycle, but it's easy to read as "Linux is available now" — totally valid confusion.

The active tracking issue for this is #3759, which covers the Linux desktop app request and is currently waiting on product direction. There's also ongoing packaging work (PR #2736 — Flatpak) that's still in draft while some pieces are resolved.

If you'd like to follow updates on the Linux release, #3759 is the best place. Thanks for reporting the discrepancy — the README wording is something we should make clearer regardless. 🙌

[asdlem]

Hope to see Linux support land someday. The README (especially the Chinese version at docs/i18n/README.zh-CN.md) mentions "Linux（AppImage，可选通道）", but no Linux binary has ever shipped across 13 releases. #1613 already laid out a complete implementation plan — would be great to see it picked up. 🤞

[lefarcen]

Hey @asdlem! Good catch on the Chinese README specifically — docs/i18n/README.zh-CN.md mentioning "Linux（AppImage，可选通道）" across all 13 releases without a binary ever shipping is a fair thing to flag.

One small clarification on #1613: that issue covers in-app auto-update for Windows and Linux (wiring electron-updater after binaries already exist) — it was actually closed in May by the author since it overlaps with the active #1375 work. It's downstream of, not a substitute for, the initial Linux packaging. So the sequencing is roughly:

1. Product direction lands on Please bring the linux app as well #3759 (currently labeled needs-product-direction)
2. PR feat(flatpak): add desktop metadata #2736 (Flatpak packaging, still draft) gets reviewed and merged
3. The auto-update path from [codex] Add packaged desktop auto-update #1375 can then extend to cover Linux

The Flatpak PR does show real packaging work has started — the draft gets the app building and running under zypak sandboxing, with the remaining blocker being the daemon-to-opencode connection. Not there yet, but not a blank slate either. Fingers crossed the product direction piece moves soon. 🤞

[richardstevenhack]

Good to see AppImage and Flatpak work being done. This is the way to go for Linux as more distros move to immutable deployments.

[luna-system]

Hey @Abdulee! 👋 Your observation is correct — the README lists Linux (AppImage, optional lane) under the download section, but no Linux asset is included in the current releases (v0.10.1, v0.9.0, and earlier). The "optional release lane" phrasing is intended to mean the AppImage isn't published on every release cycle, but it's easy to read as "Linux is available now" — totally valid confusion.

just a point of order - the open design website does directly state:

which is more than a little confusing. probably worth updating.

[lefarcen]

Hey @luna-system — good catch. If the website is also advertising Linux desktop availability directly, then this mismatch is broader than the README wording alone.

That makes this issue a docs/site-surface discrepancy, not just a releases-page one. We should treat the website copy alongside the README/i18n copy until the Linux packaging work in #3759 and PR #2736 actually lands.

[sunraysun]

Is there any new progress?

[lefarcen]

Hey @sunraysun — no material public progress yet, unfortunately.

The latest visible state is still:

• PR #2736 (Flatpak packaging) is still draft and its current GitHub state is DIRTY / review not ready
• #3759 is still open and still carries needs-product-direction
• I’m not seeing a newer public maintainer/product update after the June follow-ups

So the short version is: the Linux packaging work has not landed yet, and there isn’t a newer public timeline I can point to today. If that changes, the clearest places to watch are #3759 and PR #2736. 🙌

[Xpos587]

How soon can we get at least some version for linux?

[lefarcen]

Hey @Xpos587 — we still don’t have a public ETA I can honestly give you.

The closest public path to “at least some Linux version” is still PR #2736, but it remains draft and GitHub still shows it as DIRTY / not review-ready. The broader release-direction thread is still #3759, and that issue is still open with needs-product-direction.

So the short answer is: not imminently, based on the current public state. I’d rather be explicit about that than guess at a date we can’t back up yet. If/when there’s a first Linux build path we can point people to publicly, #3759 and PR #2736 are still the places that should show it first. 🙌

[mohyddintash]

Hi @lefarcen, really happy to see Linux being at least considered, I came across this package in AUR do you think it is good workaround for the meantime? I am not sure fi I should trust it though as it is not official. Otherwise, what is the current ways to run it on Linux?

[lefarcen]

Hey @mohyddintash — good question. As of July 26, 2026, I’d treat that AUR package as a community workaround, not an official Linux release.

A bit more concrete context:

• the AUR package is maintained by a third party and is not published by the Open Design team
• it does appear to build from the official GitHub source tag (open-design-v0.16.1), which is a better sign than a repackaged mystery binary
• but it still isn’t something we can vouch for as an official/supported release channel

So the cautious answer is: reasonable to inspect/use if you personally trust the PKGBUILD and build process, but not something we should present as “official Linux support” yet.

The currently verifiable Linux paths are still:

• Docker: the repo README has a deploy/ flow for running Open Design on Linux via docker compose
• Run from source: clone the repo, corepack enable && pnpm install, then pnpm tools-dev run web

Separately, the public packaging work is still tracked in PR #2736. It’s no longer draft, but it still hasn’t landed, so I’d still consider Linux desktop packaging in progress rather than shipped.

So if you want the safest route today, I’d recommend Docker or source-run over the unofficial AUR package. If you do try the AUR package, I’d strongly suggest reading the PKGBUILD first so you know exactly what it’s pulling and building. 👀