Hey Fluxers,
Hampus here. I know it sounds like a broken record to say the last few months have been intense, but there's no better word for it. We have a lot to cover, and I don't want to go further without saying thank you.
Fluxer has grown to more than 300,000 users. Today we're launching the mobile apps, big self-hosting and safety improvements, the reopening of pull requests, $1,500 in developer bounties, and a growing list of clients, tools, and bots. Thanks to @Fen and @Xeon, Fluxer is now also on Flathub.
We couldn't do this without all of you talking about Fluxer, subscribing to Plutonium, donating, filing bug reports, building things, testing rough edges, and helping us find what needs to be better. Volunteers have collectively put thousands of hours into Fluxer over the last few months. We're grateful to every one of you. Without you, none of this would be possible.
In the same spirit, we're glad to welcome a few new staff members: @Lilith, @Ferret, and @Stefan. They bring experience across support, safety, engineering, product, and more. Expect to see them around.
If you're new here, these two posts explain how Fluxer got here and what was next on the roadmap:
Hampus Kraft
Hampus Kraft
Before the announcements, one quick note: the self-hosting get-started guide is live. The rest of the self-hosting documentation is still being finalised, and the API documentation is being cleaned up too. We don't expect either to take more than a few days longer.
With that said, we promised one launch: an open source mobile app. We're also finally announcing the long-awaited Fluxer v2.
Fluxer v2
It's here. Fluxer v2.
Fluxer v2 is what we've been calling a large refactor and a set of infrastructure stability improvements. Most of the app stayed intact. Fluxer is still very much a polyglot codebase in TypeScript, Erlang, and Rust, using each one for the parts it is good at. We worked on it privately for the last two months because the code was moving fast enough that pushing broken builds to everyone would have helped nobody. The refactor includes a lot:
- Self-hosting documentation and prebuilt images.
- A cleaner split between Fluxer.app deployment settings and self-hosted settings.
- The Erlang Gateway role split for websocket connections, sessions, guilds, presence, calls, and push notifications.
- Rust services for hot paths like users, messages, unfurling, media, and Snowflake IDs.
- Better tools for operators and safety work around spam, illegal content, and instance moderation.
- The codebase back in a shape where public issues and pull requests can move again.
And a lot more.
fluxerapp
Now that the v2 refactor is out, we can keep GitHub in sync with active development, respond to issues, and review pull requests again. Thank you for your patience and kindness as we worked to reach this milestone, and thank you to the dozens of testers who helped get it launched.
Mobile app open source
For the last six weeks, we've been alpha testing the iOS and Android apps. They're built with Flutter, which isn't a typo, and it has made the apps fast and smooth. Early adopters, the Visionaries, have been daily driving them, giving feedback, and finding bugs while @M0N7Y5 and @Elias have been hard at work getting the clients closer to desktop.
They aren't fully there yet, but we think the native apps are ready for Plutonium subscribers on iOS and for open testing on Android. As of 15 June 2026, you can find the mobile client on GitHub.
fluxerappWe'll release prebuilt versions on F-Droid, Obtainium, Google Play, and the Apple App Store in the coming weeks. Accrescent will come as soon as they open up again.
The native client has about 50% of what we'd consider ready for a stable launch. Expect bugs. For now, we'd rather send new non-technical users to the Canary mobile PWA at web.canary.fluxer.app, which has also improved a lot, than have them bounce off a half-finished native app.
If you're on iOS and don't have Plutonium, please hold on a little longer and be careful with prebuilt apps from other sources claiming to be the official Fluxer client.
Safety, operations, and bounties
We've been hard at work behind the scenes on instance moderation and operations. We've dealt with spam attacks, CSAM, extremist content, and other abuse while continuing to improve reliability and uptime.
Many of those improvements are already part of the Fluxer v2 refactor, and more are coming soon. Check GitHub for the public roadmap, discussion boards, and feature requests.
fluxerappSeveral upcoming features also have bounties on GitHub. The bounties are tagged by priority as low, medium, high, and urgent, with different payments attached. Please read the contribution guidelines before getting started.
One thing I'm especially excited to keep testing in the open is the new native A/V architecture I've been working on. The goal is screen sharing with audio at 1440p 60fps without audio or video frame drops, built through a lot of optimization and native platform work. That code is on GitHub now, so if you want to help fix bugs before Canary reaches stable, you can.
Questions we know people have
We want to answer some of the obvious ones right away.
What about Partnered and Verified Communities?
We've been working on updated requirements, and the plan is to review applications within the next month. After that, reviews will happen every so often, so expect some time between additions. Keep an eye out for responses or follow-up questions from the team.
Why did GitHub lag behind internal development?
GitHub lagged because we made a call: the public code needed to be useful, not just current. Fluxer needed a cleaner foundation before it made sense to invite people back into issues, pull requests, and self-hosting.
Most of Fluxer was not rewritten. The v2 refactor was about separating what needed to move, cleaning up infrastructure, and making the codebase easier to run, self-host, and contribute to. Doing that privately made the public repo harder to follow, and I understand why that frustrated people.
At the same time, we were a small team carrying too much at once: backend, frontend, operations, moderation, mobile, and the v2 refactor. Native screen sharing, audio capture, and platform integration also came with a real learning curve for a mostly solo developer suddenly facing a lot of new technical requirements from a user base that needed more. I'm glad to be close to delivering that when Canary reaches stable.
Fluxer was also dealing with attacks involving CSAM and gore content across public communities. The new safety systems have put us in a much better place, but getting there was emotionally exhausting. I could not in good conscience push half-finished moderation tools, policy thresholds, or infrastructure changes to GitHub while that work was still tangled together.
So we finished the v2 foundation first. With the v2 refactor out, the safety work split out, and a roadmap in place, GitHub can be useful again. Issues, pull requests, self-hosting, and migration work can move in the open.
We're happy to be back there. Seriously, nobody is happier than we are to have this back in the open. Please submit issues and PRs. Pretty please :)
Why is federation taking so long?
We're working on it, and we need your input. Seriously, come talk through the design standard with the Fluxer team and developer community on GitHub and in Fluxer Developers. Federation matters to me and the entire team, and we want to do it right. A lot of questions are still unanswered:
- What happens when a user keeps returning to one Fluxer instance through another instance?
- How does Fluxer prevent illegal content like CSAM from propagating across instances?
- In DMs, which instance is responsible for moderation, if any?
- How do users and communities migrate between instances?
- How should Fluxer handle Plutonium?
- Why is Hampus a ghost?
And dozens more.
We'd really like to avoid the email problem, where some instances or clients never support newer standards, by being careful with the design upfront. Some split between instances is inevitable, but Fluxer shouldn't start there through rushed implementation.
We want Fluxer to be the home for your community for years to come, no matter who hosts it. That means putting in the thought and building slowly.
I'm worried about Fluxer disappearing!
Fluxer has a way forward, but we still need the community around it. Costs grow quickly with age and a larger user base, and the best version of Fluxer is built with people using it, testing it, supporting it, and telling us what needs work. Here's how you can help:
- Subscribe to Plutonium. Plutonium supports Fluxer while giving you fun perks. It's the best way to contribute to the hosted instance.
- Donate to Fluxer.
- File bug reports.
- Talk about feature requests, federation, and other parts of Fluxer in GitHub Discussions and the Fluxer Developers community.
- Invite your friends to hang out on Fluxer. We love company.
And thankfully, even if Fluxer were to close its hosted instance in the future, the point is that you can always run an instance on your own hardware. Fluxer is open source, now and forever.
Why should my community use Fluxer over other platforms?
You should use what gives you joy.
For us, that's the promise of being able to own your communications and still connect with others. If your community finds joy on other platforms, use them. But give Fluxer a try. You may find that little spark of magic here.
Communication belongs to people, and people create communities. Building so much at once has been a lot, and honestly, I feel like I need a vacation at this point.
More than that, though, we're excited to at long last share everything with the developer community and keep building in the open. That's what we wanted all along: for Fluxer to be a home for open, free communities, no matter who hosts them.
Thank you all for reading, and let's make 2026 the year of Linux Fluxer.