Updated 20 May 2026: this roadmap has changed a lot since the January beta. Fluxer is now operating at a much larger scale, the canary client is far ahead of the original stable release, native mobile is in testing, and the backend reliability work is no longer theoretical.
Stevie Bonifield
Fluxer is still in public beta, but it is a very different project from the one I wrote about in January. The hosted instance had to grow up quickly after Discord's age-verification announcement, and the roadmap now puts reliability, safety, self-hosting, and fewer production incidents alongside new features.
I've also updated the longer release post that explains the journey, the architecture, and the reasoning behind Fluxer:
Hampus Kraft
Fluxer already covers a lot of what people expect from a modern chat app. The next phase is about making it steadier: fewer client bugs, self-hosting that is easy to set up, safer infrastructure, better moderation tools, and fewer production incidents.
#1: Canary to stable, and native mobile
The canary client is now the best way to use Fluxer. It has moved well past build v0.0.200, compared with v0.0.8 for the original stable desktop client, and it includes hundreds of fixes plus major voice and video improvements: screen sharing with audio, text in voice, better DM calls, a stronger device selector, more mic processing controls, noise suppression through DeepFilterNet3, and LiveKit-backed E2EE for voice and video in enrolled testing communities.
You can try it today through the canary desktop build at canary.fluxer.app/download, or in the browser at web.canary.fluxer.app. Canary moves to stable after the last serious bugs are fixed. Voice and video E2EE rolls out more broadly soon, then becomes enforced as supported clients catch up.
The launch PWA had rough edges, but the web platform let Fluxer ship across web, desktop, and mobile from day one. It will keep improving while the native app moves through testing.
Native mobile is happening in parallel. The iOS and Android app is built with Flutter, and as of 20 May 2026 it is being tested with Visionaries. The rollout is staged: Visionaries first, then a Plutonium beta, then a public release. The app code will be open source too.
Flutter also gives us an interesting desktop path later. Mobile comes first, and Flutter can become an alternative to Electron.
#2: Self-hosting and the backend cleanup
Official self-hosting support is the next major release after canary stabilisation. The target is early to mid June 2026. That release includes Docker images, documentation, a web-based setup flow, and a simple setup for a typical instance: API, Gateway, Worker, Media Proxy, database, Valkey, and NATS.
The current docs are pretty mediocre, and I am sorry about that. Brand new API docs and self-hosting docs are coming with that release.
The hosted Fluxer.app deployment is much larger than a normal self-hosted instance will ever need to be. Production now includes the TypeScript API and Worker, the clustered Erlang Gateway, the Rust Media Proxy, NATS, Valkey, and new Rust data services for caching and hot real-time data. Self-hosting needs the benefits of that work without requiring people to understand our entire production setup.
The Gateway clustering work is a recent example. Fluxer started with a single Gateway node because the original design was built for a much smaller user base. After the growth spike, that single-node design became a reliability problem. We rolled out Erlang Gateway clustering with 16 replicas across four physical machines, which gives the hosted service room for node failures and rolling changes without taking everyone down.
Those Rust data services belong to the same self-hosting and reliability work. One sits in front of Cassandra to reduce repeated reads through request coalescing and caching. The other supports the Gateway side by moving high-intensity real-time state, such as presences and member lists, into Rust while Erlang keeps doing session supervision and real-time coordination.
At launch, the Electron desktop app will support connecting to custom backends through in-app account switching. You will be able to point the regular desktop client at your own instance without waiting for full federation.
The Operator Pass comes soon after the docs and setup guides are solid. It will be a $199 or €199 one-time purchase for prioritised self-hosting support from the Fluxer team, so operators can get help directly when community support or GitHub threads are too slow.
This is also why GitHub is behind the hosted service right now. Recent work includes Gateway and API scaling, NATS job handling, Valkey caching and rate-limit work, Docker packaging, setup wizard work, database bootstrap and migration work, media proxy fixes, report queues, abuse throttles, spam heuristics, safety-list syncs, and admin workflows. Before publishing it, we are turning Fluxer.app-only settings into documented instance settings, removing private deployment details, and documenting it well enough that operators can actually run it.
#3: Localisation in the open
Fluxer already supports 34 locales across the app, email templates, marketing site, and similar places.
That currently means:
- العربية
- Български
- 简体中文
- 繁體中文
- Hrvatski
- Čeština
- Dansk
- Nederlands
- English (United Kingdom)
- English (United States)
- Suomi
- Français
- Deutsch
- Ελληνικά
- עברית
- हिन्दी
- Magyar
- Bahasa Indonesia
- Italiano
- 日本語
- 한국어
- Lietuvių
- Norsk
- Polski
- Português (Brasil)
- Română
- Русский
- Español (Latinoamérica)
- Español (España)
- Svenska (Sverige)
- ไทย
- Türkçe
- Українська
- Tiếng Việt
The current workflow uses LLMs for the first translation pass because the product changes quickly and the team is small. LLM literally means large language model, and this is one place where the tool is not half-bad: drafting product copy across languages. It saves humans from starting every locale from a blank page.
That first pass is only the start. It is product copy, not people's private conversations, and native speakers then improve and enrich it: tone, terminology, and cultural details. Native speakers in many languages have already told us the current localisation is good, which is encouraging, but human review and community input are what make it good enough to rely on.
We do not assume everyone speaks English. Fluxer needs to be versatile and usable internationally, whether English is your first language or not.
After the self-hosting release, localisation moves into a self-hosted Weblate instance so the work can happen in the open. If you want to improve an existing locale or add a new one, email i18n@fluxer.app and we will put you on the waitlist.
#4: Federation and multiple backends
Federation remains part of the plan, and the order matters. People who run and use Matrix tend to complain about specific things: large federated rooms can be slow and expensive to join because every server has to deal with room state, presence and device-list updates can create a surprising amount of background load, federation failures can leave rooms or encrypted messages half-working, and moderation gets harder when abuse, media, bans, and bridges cross server boundaries.
Shortly after the self-hosting release, the next step is simultaneous connections to multiple backends in one client. That means you can connect to more than one self-hosted instance, keep separate identities, and see them together without visually switching between workspaces. That already helps people who run more than one instance before true federation is ready.
Later, true federation can build on that foundation, with OAuth2-based authentication against remote servers and a clearer model for unified identity, communities, and data.
#5: Threads, forums, and publishing to the web
Amanda Silberling
Threads and forums are still on the roadmap. They need to be good enough that people do not immediately work around them.
Forum-style spaces will also have an optional public web mode. When a community chooses to publish something, it becomes readable without logging in, indexable by search engines, archivable, and available through RSS and Atom feeds.
With LLMs, Sellis said, Discord could take a long, meandering conversation and turn it into "something that could be more sharable and syndicated across the web." However, he said that he and his team hadn't "seen a solution that we feel great about yet."
Fluxer does not agree with Discord's premise here. We do not think LLMs should be used to turn people's "meandering conversations" into syndicated material. If something should become public, it should happen because a person or community chose to publish it.
This feature uses the web itself. Fluxer brings back the good parts of the web as a publishing and sharing medium: public pages with stable URLs, server-rendered posts, clear titles, search indexing, pages that can be archived, RSS and Atom feeds, and links people can share anywhere. People's posts remain their posts.
This is opt-in for communities that benefit from public knowledge: open source projects, developer communities, modding groups, creator communities, research groups, and support forums. Private chat stays private.
#6: Discovery for communities, instances, and apps
Fluxer already has basic in-app community discovery per instance. That is a good start, and it needs to grow once self-hosting and public web publishing become normal.
A public discovery system for Fluxer communities and instances will be visible on the web without logging in. The registry is built from pull requests to a public repository, so listings are transparent, reviewable, and easy for instance operators and community owners to update.
The same model can later extend to Fluxer bots and applications. If someone builds a good moderation bot, bridge, game, utility, or integration, there will be a public place to find it without relying on word of mouth.
Fluxer Platform AB still needs to moderate what appears in the official discovery index, but the list itself will be public and auditable.
#7: Slash commands, UI kit, and integrations
This needs Discord-level support for slash commands, modals, components, and interactions, then improvements based on feedback.
#8: Emoji and sticker packs
A lot of Discord users know the weird habit of joining communities just to use their emojis and stickers globally. Fluxer lets you skip that.
People will be able to create emoji and sticker packs that other users can equip directly to their account. Free users get an allowance for this too, while paid tiers can offer higher limits.
#9: E2EE where it makes sense
Platforms like Matrix do offer E2EE, but the complexity of the protocol and its client implementations often comes at the expense of what people actually want.
Most people want a reliable, feature-complete, non-E2EE Discord alternative: fast clients, good search, profiles and statuses, custom emoji, straightforward roles and permissions, solid voice and video, and practical moderation tools that work.
That's where Fluxer's priorities lie. Adding E2EE to text messaging adds real complexity, especially for search, moderation, history, recovery, and multi-device sync.
Optional E2EE still belongs in the roadmap for personal notes, calendar data, DMs, and small groups. E2EE for large communities is out of scope.
Voice and video are a better fit technically, and that work already exists in canary for enrolled testing communities using LiveKit's built-in E2EE support. It rolls out to everyone soon, then becomes enforced as supported clients catch up.
#10: Creator monetisation
Fluxer can let fans pay to unlock roles and access to a creator's exclusive community content. That access can be permanent or time-limited, billed as a one-off purchase or a recurring subscription. Creators can also sell event tickets for time-boxed sessions, where a ticket or temporary role unlocks specific text and voice channels for the duration of the event.
For Fluxer.app, the model is simple: charge a small, transparent fee on each transaction (for example, 5 to 10%) and stay competitive with alternatives like Patreon. Patreon has been moving towards Discord-style community features, while Discord has experimented with Patreon-style monetisation, but those efforts have been uneven. In Discord's case, they are still limited in availability and focus. This becomes another revenue stream so we do not have to rely on Plutonium as much.
Mia Sato
Focusing on this for the Fluxer.app instance also makes paid features easier to understand. Fluxer does not need to invent the content people pay for since creators already do that. Fluxer "just" needs to provide the best real-time communication platform (text, voice, and video) and the creator tools that make audience-building and community management easier. That means the free tier can be subsidised to a larger extent.
If you'd like to use Fluxer as an integrated Discord + Patreon solution, and you already have a large audience you'd be willing to bring over, get in touch. We're looking for early partners to test creator monetisation features, and we can offer a lower platform fee for partners. Email partners@fluxer.app.
And more!
Polls and scheduled events, profile connections, a theme marketplace, stage channels, activity sharing, streamer mode, DM folders, popping calls out into their own desktop windows, soundboard clips, community templates, public profile URLs, and better tools for operators and safety work. There are so many features, big and small, that Fluxer will keep adding over time.
GIF search also has maintenance work coming up. Fluxer currently relies on Tenor in the app, but Google is killing the current Tenor API on 30 June 2026. KLIPY support already exists in the codebase, alongside Tenor, and it is the natural replacement when the current Tenor API stops working. We are not switching to GIPHY. Sorry, but not sorry. GIFs are proxied through Fluxer, so providers do not see your IP address just because you searched for or viewed a GIF through the app.
You can influence the roadmap by joining the Fluxer HQ community, submitting issues in the GitHub repository, emailing me, or supporting Fluxer in any of these ways:
- Donate any amount, as an individual or a business.
- Purchase Plutonium on the main Fluxer.app instance.
- Spread the word about Fluxer with friends and on social media.
But why?
Why use Fluxer when Discord is free and works well? And, realistically, why trust a new product that could disappear next week?
If Discord does what you need, and you're fine relying on a proprietary, investor-driven platform with an upcoming IPO, then you may not need Fluxer. I want to compete with Discord's network effect by building a real alternative.
Julie Bort
Fluxer is for people who want different incentives: free, open source, self-hostable software, with an optional hosted version run by an independent, European-owned provider.
Fluxer is one of the closest FOSS attempts at the kind of chat app people expect from centralised proprietary platforms such as Discord or Slack.
Fluxer can succeed without Discord getting worse. I'm building something I believe the tech community has been missing, where people are generally more willing to switch to a real alternative if one shows up.
Discord's network effect is hard to beat head-on, so I'm focusing where switching is already plausible: technical users and communities that value control and transparency, and want software they can run on their own terms. Others may simply prefer a European-owned instance run without exploiting its users, with clearer incentives.
Fluxer is free and open source (AGPLv3), and the rule is simple: it remains the same software whether you use the hosted instance or run it yourself. Funding comes from a hosted freemium instance, Plutonium for higher limits, donations, and optional paid support for people who want help operating their own instance.
If the hosted free tier limits are too tight, you can always run your own instance. Fluxer is committed to keeping the software free of feature paywalls and licence key checks. It does not force upgrades to unlock quotas on software you run yourself. No SSO tax!
Closing thoughts
Phew. I care about this a lot. If you do too, the best ways to help are using Fluxer, buying Plutonium if the hosted instance works for you, donating if you want to support the project directly, reporting bugs well, and giving feedback in the community.
I want Fluxer to stay independent and bootstrapped. That means the roadmap has to be ambitious, but it also has to be honest about sustainability.
Got questions or concerns, or interested in partnering with Fluxer? Whether you're a content creator, run an open source project, manage a community of any size, or work at a CDN or trust and safety vendor, you can reach me directly at hampus@fluxer.app. If you're a fellow independent, bootstrapped, privacy-first alternative to the mainstream, or you're in the press, I'd love to talk too.
We've already come a long way, and I hope you've liked what you've seen so far. With your help, Fluxer can become a serious FOSS alternative to Discord.
See you in the Fluxerverse!