This is what we're working towards in 2026. Not all of it will be done by 31 December, and some of it may move to the 2027 roadmap.
#1: Release the mobile apps on app stores
You can already use the mobile apps through the TestFlight beta on iOS or the Google Play beta on Android. Both are linked from our download page. A mobile app developer recently joined the team, and we're making the apps more stable so they're ready for a full release on the App Store and Google Play.
#2: Self-hosting
Fluxer is free, open source software, which means its code is public and free to use. Anyone can run their own copy of it on their own server, which is called self-hosting. Each copy is called an instance. Fluxer.app is the instance we run, and it's free to use.
Self-hosting work happens in public on GitHub. Ready-made packages for installing Fluxer on a server are available, and the self-hosting documentation walks you through setting up your own instance.
The desktop app is also getting proper support for self-hosted instances. When you first open it, it asks which instance to use. You can sign in to accounts on as many instances as you like and switch between them instantly. Every account stays connected in the background, so you get push notifications and unread mentions from all of them. The Quick Switcher lists accounts with unread mentions first. Accounts you aren't looking at keep their data in a small cache on disk instead of in memory, so staying signed in to several doesn't slow the app down.
The Operator Pass will be an optional one-time purchase of $199 or €199 for people who run their own instance. It unlocks nothing in the software, and self-hosting is free without it. It will help pay for infrastructure and developer costs, and it will come with these perks.
- A private #operators channel in Fluxer Labs, with a direct line to the team for help and feedback.
- The Operator role in Fluxer Labs, with its own colour and icon.
- Your avatar and name on this website, if you want them there.
You pay once and keep the perks for life. If you want to give more, you'll be able to set up a recurring donation at the same time.
#3: A new voice and video system
We're replacing LiveKit, the voice and video software Fluxer uses today, with our own system built around how Fluxer works.
- In our benchmarks it's faster and uses less memory than our LiveKit setup. It can also share bandwidth and server capacity fairly between users, which keeps CPU usage predictable and makes voice servers easier to plan and scale.
- Calls will be end-to-end encrypted with DAVE, the protocol Discord designed and published. Our implementation hasn't been audited yet. It follows the DAVE whitepaper and builds on its audited libraries.
- It replaces WebRTC with our own protocol over UDP and uses QUIC for encryption and connection management. Joining a call is faster, every client behaves the same way, and we can see what's happening at every step.
- Streams are separate from calls. Each stream gets its own connection and its own process on the server. A problem with a stream is less likely to affect the call, and a stream can handle far more viewers without slowing the call down.
- Every client shares one core written in Rust. It runs through WebAssembly in the browser and natively in the desktop and mobile apps.
- The gateway, the part of Fluxer that keeps clients up to date in real time, tells the voice servers who is in which call directly. This prevents the mismatches that came from keeping that information in sync with LiveKit.
Adding a voice server to a self-hosted instance also gets much simpler. You set a registration token when you set up the machine, and your instance picks up the server automatically. The admin panel shows each server's health and load, and calls are never sent to a server that's unhealthy.
#4: A new push notification system
We're building a new push notification system for the mobile apps. It will also let self-hosted instances send push notifications to their users on iOS and Android.
On Android, there are ways to deliver push notifications without a central service, but they're harder to set up and use. On iOS, there are no real alternatives to Apple's own service. So we're doing what many other apps do. We'll run a push relay that your instance connects to, and the relay delivers your instance's notifications to your users' phones.
The relay won't know what your notifications say. Each notification it passes on is only an ID with no readable content. When your phone receives it, the app asks the instance it came from for the details, using your account's login for that instance, and builds the notification on the phone. Fluxer, Apple and Google won't be able to see usernames, message contents or anything else.
The new system will also fix long-standing problems with the current one, like notifications that arrive late or not at all, and notifications that stay on your phone after you've read the messages on desktop.
#5: Federation and multiple backends
Federation would let people on different instances talk to each other as if they were on the same service, the way email works across providers. We have no plan or date for it. It's hard to get right, and we're discussing how it could work in the Fluxer Labs community. You're welcome to join in.
In the meantime, we're making it as easy as possible to use several instances at once from the mobile and desktop apps. You sign in to each instance separately and switch between them in the app. For most people, that may cover what they want from federation. One possible next step is client-side federation, where the app brings your accounts on different instances together in a single workspace for people who want that.
Full federation between servers would need much more work, and we're still working out what it would look like. For now, we're focusing on making several instances easy to use from one app.
#6: Threads, forums, and publishing to the web
Fluxer will support threads and forums. Forum channels will also have an optional public web mode. If a community turns it on, anyone can read those posts without an account, find them through search engines, archive them, and follow them with RSS or Atom feeds. Communities choose what to publish, and private chats stay private.
#7: Slash commands, UI kit, and integrations
Fluxer needs proper support for bots and integrations. That means slash commands, modals, buttons and other components, and interactions.
#8: Emoji and sticker packs
On many chat platforms, people join communities just to use their emojis and stickers everywhere else. Fluxer could remove that step by letting anyone create emoji and sticker packs that other people can add straight to their account.
#9: E2EE where it makes sense
End-to-end encryption (E2EE) means only the people in a conversation can read it, not the server running it. Matrix, another open chat system, offers E2EE, but the complexity of the protocol and its apps often gets in the way of what people actually want.
Most people want a Discord alternative they can use every day. They want fast apps, search, profiles and statuses, custom emoji, roles and permissions, voice and video, and moderation tools. That's where Fluxer's priorities are. E2EE for text messages adds real complexity, especially for search, moderation, message history, account recovery and using several devices.
Optional E2EE is still on the roadmap for personal notes, calendar data, DMs and small groups. E2EE for large communities is out of scope.
Voice and video are different. End-to-end encryption for calls is in testing for communities that have opted in, and we plan to roll it out to everyone soon. Once every supported app can handle it, encryption will be required for all calls.
#10: Creator payments
Fluxer could let fans pay to unlock roles and exclusive content in a creator's community. That access could be permanent or time-limited, as a one-off purchase or a recurring subscription. Creators could also sell tickets for events, where a ticket or temporary role opens specific text and voice channels for the length of the event.
This likely won't happen in 2026. Once it does, creators on Fluxer.app could run their community and take payments from supporters in one place. Fluxer.app would handle the payments and take a small fee, likely between 5 and 10%. That fee would pay for hosting and for the people who work on both Fluxer.app and the open source software.
Patreon and Discord have each tried to combine community chat with paid memberships, with mixed results. If Fluxer gets it right, the fee helps keep Fluxer.app generous for free users, pays for improvements that also reach self-hosted instances, and gives Fluxer more financial freedom to keep working on open source software.

And more!
We also want polls and scheduled events, profile connections, a theme marketplace, stage channels, activity sharing, streamer mode, DM folders, calls you can pop out into their own desktop window, soundboard clips, community templates, public profile URLs, and better tools for people who run instances and for safety work.
You can help shape the roadmap by joining Fluxer Labs or opening issues in the GitHub repository. You can also support Fluxer directly.
- Donate any amount, as an individual or a business.
- Subscribe to Plutonium, the optional paid subscription on Fluxer.app with higher limits.
- Tell your friends and followers about Fluxer.
Closing thoughts
See you in the Fluxerverse!



