Releases missing artifacts

[rnett]

The releases text states:

Download the appropriate installer for your platform below.

Windows: .msi or .exe installer
macOS: .dmg installer (Intel and Apple Silicon)
Linux: .AppImage, .deb, or .rpm package

However, there are no artifacts on the release other than the source code.

[adam-brusselback]

Was just about to open the same issue.

[0dragosh]

A container image would be useful too.

[cjroth]

Hi all! We're working on this - there are two issues at the moment:
(1) our platform releases pipeline is currently broken, which we are working on fixing
(2) if you want to self-deploy the backend, there are some templates for doing this with docker compose, helm, and pulumi here: https://github.com/thunderbird/thunderbolt/tree/main/deploy

[PylotLight]

Any thoughts to a client only solution for simple global ai chat client? Then optionally connect to backend for more features?

[bradleycundari]

A container image would be useful too.

Yes I agree. It would be ideal for individual components to have their own images published too. This project is a significant development for the self hosting niche. I'd be running and testing this today if there were images available. A wrapper image could be handled by other groups but nonetheless worth suggesting.

[alexgit2k]

@cjroth Could you kindly upload the binaries manually?

(1) our platform releases pipeline is currently broken, which we are working on fixing

It seems that the release pipeline for the binaries has never been working properly. The binaries are missing since the first release, which should have included them in November: https://github.com/thunderbird/thunderbolt/releases/tag/v0.1.19

[Muitamax]

This is a release packaging / CI pipeline failure issue, not a code bug.

1. Expected behavior

The project documentation says releases should include ready-to-download binaries, e.g.:

Windows: .msi / .exe
macOS: .dmg
Linux: .AppImage, .deb, .rpm

So users expect a GitHub release page like:

“Download installer → pick your OS → install immediately”

2. What is actually happening

Releases exist, but they contain only:

❌ Source code archives (zip / tarball)
❌ No compiled binaries
❌ No installers
❌ No artifacts attached to the release

So the release page is effectively non-functional for end users.

3. Root cause (from maintainer comment)

Two key problems:

(1) Broken release pipeline
CI/CD process that builds and uploads artifacts is failing
So binaries are never generated or attached
(2) Possibly never fully working
Evidence suggests this isn’t a recent regression
Even early release tags (e.g. v0.1.19) already lacked binaries
So it may be a systemic missing build/distribution setup
4. Impact
For end users
Cannot install via normal “Download and run” flow
Forced to build from source or use deployment templates
For project adoption
Major barrier for:
non-technical users
enterprise evaluation
quick testing
Makes the project feel “incomplete” despite active development
5. Workarounds currently provided

Maintainers point users to:

Docker Compose templates
Helm charts
Pulumi deployment configs
→ located in:
deploy/ folder of repo

So the current “official” install path is:

self-host via infrastructure tooling instead of downloading binaries

6. Community suggestions
   Container images

Several users suggest:

Publishing Docker images for components
Possibly even a “client-only” lightweight container

This would:

bypass missing binary issue
simplify self-hosting
align with modern deployment practices
7. Key technical takeaway

This is fundamentally a release engineering gap, typically involving:

CI build jobs (GitHub Actions / GitLab CI)
packaging steps (electron builder / rust/cargo / go-releaser etc.)
artifact upload step (GitHub Releases API)

The pipeline likely lacks one or more of:

build stage
packaging stage
release artifact publishing stage
8. What a proper fix would look like

A complete resolution would include:

Fix CI pipeline to build per-platform binaries
Add release job that:
builds artifacts
attaches them to GitHub Releases
Ensure versioned tagging triggers release automation
Optionally:
publish Docker images to registry (GHCR / Docker Hub)

[txhno]

ive fixed it here: #720

[alexgit2k]

ive fixed it here: #720

"If no desktop assets are attached yet, use the self-deploy templates ..."

Seriosly? 🙈
And how do the self-deploy templates generate installers?

[0dragosh]

@cjroth is there at least a plan for fixing these?

There's obviously demand for trying out the project and this is stifling early adoption.

I know for sure I will not look at the project again if it takes months to push a docker image.

[txhno]

#720 only fixes the release text so it no longer claims installers are attached when they aren't. It does not implement binary or Docker image publishing. The actual artifact/image pipeline still needs a maintainer-side fix.

[cjroth]

Hi guys, after re-reading this, I believe we should have done a better job of explaining the current state of the project - apologies for this.

There is not a publicly available version of Thunderbolt right now - you can clone the repo and run it yourself, but currently the app depends on a backend, so even if you download the binaries, you'd just see a waitlist screen. If you self-host it, you can update the env variables and point it at your own backend, but this requires compiling the binaries yourself.

We're working on getting some Docker images published shortly. We're also working on making the app fully local-first and NOT backend dependent, at which point we will have actually useful binaries that you can download and use, but it's going to be awhile.