Roadmap 2026

The current 2026 roadmap for Fluxer: canary, mobile, self-hosting, federation, voice and video, and the backend reliability work behind it.

Hampus Kraft
Hampus Kraft
January 26, 2026
Roadmap 2026

Updated 24 May 2026: this roadmap has changed a lot since the January beta. Fluxer now runs 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 in production.

Discord will require a face scan or ID for full access next month
Age verification for all.

Fluxer is still in public beta, but it has changed a lot since January. The hosted instance had to grow up quickly after Discord's age-verification announcement. The next stretch is about making Fluxer calmer to use and easier to trust: fewer client bugs, self-hosting that is easy to set up, a safer hosted service, better moderation tools, and fewer incidents, and then the new features people are waiting for. The hosted service pays for that work and puts it under real production load, and new work should happen in the open, with full tooling for people running their own instances.

I've also updated the longer post that explains how Fluxer got here, the architecture, and the reasoning behind it:

How I built Fluxer, a Discord-like chat app
Fluxer is a free and open source instant messaging and VoIP chat app built for friends, groups, and communities.

#1: Canary to stable, and native mobile

The canary client is now the best way to use Fluxer. It is past build v0.0.200, compared with v0.0.8 for the original stable desktop client, and includes hundreds of fixes plus major voice and video work: screen sharing with audio, text in voice, better DM calls, a stronger device selector, more mic processing controls, DeepFilterNet3 noise suppression, and LiveKit-backed E2EE for voice and video in enrolled testing communities.

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 once 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 it worked in the browser and as an installable app from day one, and it keeps improving while the native app moves through testing.

Native mobile is happening in parallel. The iOS and Android app is built with Flutter and has been testing with Visionaries since 20 May 2026. Visionaries get it first, then a Plutonium beta, then public release. The app code will be open source too.

Flutter also gives us a desktop path later. Mobile comes first, but Flutter can become an alternative to Electron for low-end devices.

#2: Self-hosting and the backend cleanup

Self-hosting is the next major release after canary stabilisation, targeted for early to mid June 2026. It includes Docker images, documentation, and an interactive setup command that walks you through configuring an instance in your terminal. A typical self-hosted instance only needs the app services, a database, Valkey, and NATS.

The current docs are not where I want them to be. Brand new API docs and self-hosting docs ship with that release.

Fluxer.app is much larger than a normal self-hosted instance will ever need to be. It runs the TypeScript API and Worker, the clustered Erlang Gateway, the Rust Media Proxy, NATS, and newer Rust services for users, messages, search, unfurling, and Snowflake IDs. People running their own instances should get the benefit of that work without having to understand the whole hosted setup: the hosted instance pays for and stress-tests the hard parts, and instance operators get the tools and documentation to run Fluxer themselves.

Gateway clustering is a recent example. Fluxer started with one Gateway node because the original design was built for a much smaller user base. After the growth spike, that became a reliability problem. We rolled out Erlang Gateway clustering, then split the gateway into specialised tiers: stateless websocket pods for client connections, and separate stateful clusters for sessions, guilds, presence, calls, and push notifications. All tiers discover one another through Erlang distributed clustering. A guild pod failure now only affects guilds on that pod instead of every connected user, and each tier scales on its own.

Scheduled maintenance - Incident details - Fluxer - Status
Scheduled maintenance window on 24 May 2026 for the Gateway role-split deployment and associated reliability improvements.

The Rust services are part of the same reliability work. The user and message services sit in front of the persistence layer and use request coalescing and caching, so a flood of identical lookups for the same hot key collapses into one database hit. The Gateway keeps presence, member lists, and the rest of its hot real-time state in Erlang, which is what Erlang is good at.

At launch, the Electron desktop app will support connecting to custom backends through in-app account switching, so you can point the regular desktop client at your own instance without waiting for full federation.

The Operator Pass comes once the docs and setup guides are solid. It is a $199 or €199 one-time purchase for self-hosters who want to support the open source work and join the Operators community: a smaller place to get help from other self-hosters and the Fluxer team, share ideas, and make feedback heard before it gets buried on GitHub.

The remaining repository cleanup is mostly fallout from the sudden growth, which forced urgent operational and anti-abuse work while we kept Fluxer.app stable. Before pull requests reopen, we are turning Fluxer.app-only deployment settings into documented instance settings, publishing the operator tooling people need, and making sure abuse protections stay useful without becoming a bypass guide. After that, normal development happens in the open.

#3: Localisation in the open

Fluxer already supports 34 locales across the app, email templates, marketing site, and similar places:

  • العربية
  • Български
  • 简体中文
  • 繁體中文
  • 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

We do not assume everyone speaks English. Fluxer needs to feel usable internationally, whether English is your first language or not.

Because the app changes quickly and the team is small, the first translation pass is drafted with LLMs. LLM literally means large language model, and this is one place the tool fits: it saves humans from starting every locale from a blank page. Native speakers then catch what a model can miss: tone, terminology, awkward phrasing, and cultural details. People have told us the current localisation is already good in many languages, but we still want native speakers involved before we treat it as something people can rely on.

After the self-hosting release, localisation moves into a self-hosted Weblate instance so the work can happen in the open. 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 complain about specific things: large federated rooms can be slow and expensive to join, presence and device-list updates can create surprising background load, federation failures can leave rooms or encrypted messages half-working, and moderation gets harder when abuse, media, bans, and bridges cross instance boundaries.

So the next step, shortly after the self-hosting release, is simultaneous connections to multiple backends in one client: connect to more than one self-hosted instance, keep separate identities, and see them together without switching between workspaces. That already helps people who use more than one instance before true federation is ready.

True federation builds on that foundation later, with OAuth2-based authentication against remote instances and a clearer model for unified identity, communities, and data.

#5: Threads, forums, and publishing to the web

Discord seeks to solve a problem that it created | TechCrunch
Conversations on Discord can be hard to follow. Discord SVP Peter Sellis proposes making forum-like features, or using AI summaries.

I want Fluxer's threads and forums 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 disagrees with Discord's premise here. LLMs should not turn people's "meandering conversations" into syndicated material. If something becomes public, it should be because a person or community chose to publish it.

This feature uses the web itself: public pages with stable URLs, server-rendered posts, clear titles, search indexing, archivable pages, RSS and Atom feeds, and links people can share anywhere. People's posts remain their posts.

Publishing stays 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. Once self-hosting and public web publishing become normal, it needs to grow.

Public communities on Fluxer instances should be discoverable 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 and community maintainers to update.

The same directory can later include Fluxer bots and applications. If someone builds a good moderation bot, bridge, game, utility, or integration, there should be a public place to find it without relying on word of mouth. We still review what appears in the official discovery list, but the list itself stays public and auditable.

#7: Slash commands, UI kit, and integrations

Fluxer needs bots and integrations to feel first-class: slash commands, modals, components, interactions, and then the improvements people ask for once they start building on it.

#8: Emoji and sticker packs

A lot of Discord users know the habit of joining communities just to use their emojis and stickers globally. Fluxer skips that: people will be able to create emoji and sticker packs that other users can equip directly on their account. Free users get an allowance too, and paid tiers can offer higher limits.

#9: E2EE where it makes sense

Matrix does offer E2EE, but the complexity of the protocol and its client implementations often comes at the expense of what people actually want.

Why We Abandoned Matrix (2024) | Hacker News

Most people want a Discord alternative they can use day to day: fast clients, good search, profiles and statuses, custom emoji, roles and permissions that make sense, solid voice and video, and moderation tools that work. That is where Fluxer's priorities lie. Adding E2EE to text messaging adds real complexity, especially around 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 runs 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 payments

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.

On Fluxer.app, the deal stays simple: creators bring the thing people want to support, Fluxer handles the community space and payments around it, and we take a small, transparent fee (for example, 5 to 10%) that helps pay for hosted infrastructure and the people keeping both Fluxer.app and the open source project moving. Patreon has been adding Discord-style community features, and Discord has experimented with Patreon-style payments, but those efforts have been uneven. If this works, it keeps the free hosted tier generous, funds work that also improves the self-hosted app, and means we rely less on Plutonium.

Patreon is adding a Discord-like chat feature for creators and fans
The Discord integration will still be available.

If you'd like to use Fluxer as a combined Discord + Patreon-style app, and you already have a large audience you'd bring over, email partners@fluxer.app. We're looking for early creators to test paid community features, and we can offer a lower fee while we learn what works.

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 instance operators and safety work. Fluxer will keep adding features, big and small.

GIF search has maintenance work coming up. Fluxer currently relies on Tenor, but Google is shutting down the current Tenor API on 30 June 2026. KLIPY support already exists in the codebase and is the obvious replacement. GIFs are proxied through Fluxer either way, so providers do not see your IP address just because you searched for or viewed a GIF through the app.

You can help shape the roadmap by joining the Fluxer HQ community, submitting issues in the GitHub repository, or emailing me. You can also support Fluxer directly:

But why?

Why use Fluxer when Discord is free and works well? And, realistically, why trust a new app that could disappear next week?

If Discord does what you need, and you're fine relying on a proprietary, investor-driven app that has reportedly filed confidential IPO paperwork, then you may not need Fluxer. I want to build something good enough to matter next to Discord.

Discord's IPO could happen in March | TechCrunch
Discord reportedly filed confidential IPO paperwork and has pinned its hopes on a debut in March.

Fluxer is for people who want a different deal: free, open source, self-hostable software, with an optional hosted instance run by an independent European company that helps pay for the open source work. You should not have to give up the basics you like just to leave Discord: Fluxer keeps the familiar shape of modern community chat while making the software open and self-hostable.

Fluxer can succeed without Discord getting worse. Discord's network effect is hard to beat head-on, so I'm starting where switching is already plausible: technical users and communities that value control and transparency, and want software they can run on their own terms. But you do not need to be technical for Fluxer to be yours: many people simply prefer a European-owned instance with clearer incentives and no appetite for squeezing users.

Fluxer is free and open source (AGPLv3), and it remains the same software whether you use the hosted instance or run it yourself. That is also the real answer to "why trust a new app that could disappear next week": the code is public, anyone can run it, and no community has to depend on one company surviving. Fluxer.app should earn money by being a good hosted service, then put that money back into infrastructure, documentation, review time, and development work that self-hosters benefit from too. Plutonium, donations, creator payments, and the optional Operator Pass all fit that model.

If the hosted free tier limits are too tight, you can always run your own instance. Fluxer will keep 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

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 to support the open source work directly, reporting bugs well, and giving feedback in the community.

I want Fluxer to stay independent and bootstrapped, with the hosted instance funding the infrastructure and people needed to keep the open source app moving. Self-hosters should benefit from that work too.

Got questions, or want to work with Fluxer? Reach me at hampus@fluxer.app if you're a content creator, run an open source project, manage a community of any size, or can help with CDN, trust and safety, or moderation work. 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.

I want Fluxer to become a real alternative to Discord without losing why I started building it.

See you in the Fluxerverse!

A DeLorean time machine lifts off, heading for new adventures.