How I built Fluxer, a Discord-like chat app

I'm Hampus Kraft, a 23-year-old software developer from Sweden, nearing completion of my BSc in Computer Engineering at KTH Royal Institute of Technology. You can find my LinkedIn page here. In Sweden, our resident and company registration databases are public records.

Ever since the pandemic hit in 2020, while I was still in senior high school, I've been fascinated by Discord, the instant messaging and VoIP chat app that became the default home for so many online communities.

Fluxer is the community chat app I kept coming back to for five years: familiar, free and open source (AGPLv3), and built so people can run their own instance.

Fluxer in 60 seconds

Why use Fluxer when Discord is free and works well?

If Discord does what you need, and you're fine relying on a closed, investor-driven app that has reportedly filed confidential IPO paperwork, then you may not need Fluxer. Fluxer is for people who want an open, self-hostable alternative.

Fluxer is for people who want a different model: 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 shouldn't 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 already makes sense: technical users and communities that value control and openness, and want software they can run on their own terms. You don't need to be technical for Fluxer to be yours: many people prefer a European-owned instance that has clearer reasons to treat users well.

Fluxer is free, open source, and self-hostable. The public code should be useful to people who run their own instance, not only to Fluxer.app, and no community should have to depend on one company surviving. The hosted instance should fund hosting and development work that also helps the open source project:

Fluxer.app is the hosted instance. It's free to use, and Plutonium gives hosted users higher limits while helping pay for hosting, support, and open source development. There was also a limited-time lifetime Visionary plan for early supporters; it sold out at around 1,000 copies before I stopped it.
Donations are open for people and organisations who self-host Fluxer, or who want the open source project to keep improving.
For people who self-host and want a closer community around it, I plan to offer a one-time Operator Pass at $199 or €199. It helps fund the open source work and gives self-hosters 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.
Managed hosting comes later. Right now, the priority is making self-hosting reliable first.

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, licence key checks, upgrade-for-quota gates, and SSO tax.

Now, my backstory

2017 to 2020

I started using Discord in 2017, and my interest only grew. By January 2019, I'd joined Discord Testers, their crowd-sourced bug reporting programme, and by April 2019 I'd earned enough XP to unlock the Bug Hunter badge. Around the same time, I was accepted into Discord's HypeSquad Events programme, though I never got the chance to represent Discord at any events.

2020 to 2022

When the pandemic hit, studying from home gave me more time to learn. Until then, I'd treated programming casually, but I kept returning to the project.

During my senior high school years, I worked on early prototypes of what is now Fluxer. My final graduation project became that prototype, plus a technical report on what I'd learned from studying Discord's technical blog posts and architecture and how I applied those ideas in practice. When I graduated in summer 2022, I received a small $200 scholarship from the school, and the title "Web Guru of the Year."

2022 to 2023

I've been a student at KTH Royal Institute of Technology since autumn 2022. By summer 2023, I decided to focus more actively on Fluxer, but my studies still took up much of my time, so progress came in bursts.

In October 2022, I co-authored a medium-severity bug bounty report for a permission bypass vulnerability and submitted it to Discord's security team. The report earned my co-author and me a shared award of $1,500.

While studying, I also led web development for a popular Minecraft: Bedrock Edition server with nearly 6 million registered players. I built and ran the web systems, working on API design, security, billing, and reliability. It taught me how to keep large services running, and I still help maintain those codebases when needed.

2023 to 2024

In July 2023, I released the first private alpha of Fluxer to a few dozen testers. Since then, I've changed the tech stack many times before settling on what I run today.

The current stack is heavily inspired by Discord and, to some extent, WhatsApp. It uses boring, proven pieces for realtime delivery, internal messaging, fast shared state, and durable persistence. I did try simpler alternatives because I wanted less complexity, but I kept reinventing the wheel for problems that proven technologies already solve well.

Those changes, along with continued research into Discord's architecture, shaped the stack. I dug through Reddit and Hacker News posts from Discord employees, public conversations with their engineers, and many blog posts and postmortems, then tested the ideas in code to see where they held up. At the same time, my KTH studies in computer science, network security, software testing, and distributed systems gave me the background to judge the trade-offs.

My degree programme also puts a lot of weight on applying knowledge in practice. In spring 2024, I joined a project course where we delivered an internal tool for Giesecke+Devrient, an international security technology company.

2025

In January 2025, I grew wary of how Discord handled my personal data and where the app was headed. I built Discorch, a tool that guides you through Discord's undocumented privacy request process to bulk delete messages. It produces a CSV plus instructions for contacting Discord's privacy team to request deletion.

As more people used it, Discord kept changing the process and eventually restricted it, including blocking deletion of your own DM messages through this route because you can still delete those manually. The route now only works for servers and groups you've left.

In spring 2025, I reported a security vulnerability to Discord and was awarded $2,000. Later that summer, I registered Fluxer Platform AB, a Swedish limited liability company, which required a minimum deposit of $2,000.

Maeby from Arrested Development: "Well, that was a freebie."

By summer 2025, I'd finished most of my university courses and spent the summer writing my bachelor's thesis with a fellow student for the supportive and welcoming Intelligent Heart Technology Lab at KTH. The thesis was published in September 2025.

Between September and December 2025, I worked day and night to make Fluxer ready for public release. Getting the architecture, feature set, and web client ready for real users by myself was the hardest work I'd done.

On 25 October 2025, I opened the first private beta because I needed funding to keep going. It was a small group of around 30 testers who could invite people they knew, and a handful bought Visionary at $299 each while I worked towards feature completion.

2026

On 2 January 2026, I opened Fluxer up to everyone. I tried a Show HN, which didn't go far, and launched on Product Hunt, which gained a little more traction. A few more people bought Visionary, enough to keep me going, and I started polishing things towards a self-hosting release.

There was effectively no marketing. Then a Bluesky post after Discord's IPO plans leaked travelled further than expected, and Discord's age-verification announcement on 9 February 2026 changed the scale of the project overnight. Fluxer grew to about 195,000 users, with a peak of around 11,000 concurrent connections, while the hosted setup was still built for a much smaller load and I was the only full-time engineer.

After Discord's age-verification announcement, Visionary sold out quickly: around 1,000 copies at $299 each before sales were paused. Visionaries are recognised in-app with a numbered badge that shows how early they supported Fluxer.

Visionary was never about FOMO; I didn't know what was coming. I capped it at 1,000 slots with an expiration date in October 2026 because that seemed far above likely demand. It sold out in a matter of days.

Fluxer uses familiar community-chat patterns and includes the features people expect from this kind of app. In several areas it already does more than the other open source options, and it stays close to classic Discord where that model works.

The team is still tiny, but the day-to-day load is shared now. The goal is still simple: free and open source software, self-hosting without licence-key checks, and a hosted instance whose job is to serve users and fund the open source work.

You can support Fluxer through Plutonium, a custom donation, or issues and PRs in the GitHub repo. That support goes into hosting, documentation, code review, and the work needed to keep both Fluxer.app and the self-hosted release moving.

Fluxer's backend

Discord's backend scaling work is unusually well documented, and their engineering posts have been a big reference point for me. Start here:

I respect their engineers, even if I'm not a fan of some of Discord's business decisions. Meanwhile, a usable self-hosted alternative still doesn't really exist, and building something good enough to replace what people already use takes an enormous amount of time and energy, since people usually only pay once an app feels close to what they expect.

What kept me going was years of work to understand Discord's architecture in depth: Hacker News and Reddit threads, postmortems and blog posts, relevant courses at KTH, and professional experience along the way. I've also been active in Discord's meta communities for years, alongside fellow enthusiasts, security researchers, and bug hunters, and I've spoken with Discord engineers directly a few times.

That knowledge of Discord's development, and of people's frustrations with it, is what I'm putting to work on an alternative to closed community chat apps. Fluxer should be more than a Discord clone.

What the backend looks like now

At launch, I described Fluxer as mostly TypeScript with a bit of Erlang. That was accurate at the time. Today Fluxer.app is a set of focused services, because different parts of the app have different needs.

Most of what people touch every day goes through the API. It's a TypeScript service running on Node with Hono, and it owns the parts of Fluxer that change the most: accounts, authentication, communities, channels, messages, attachments, billing, reports, downloads, unfurls, and the public HTTP API. Cassandra stores durable data on Fluxer.app, Valkey handles fast shared state, and NATS carries internal messages. The Worker uses the same TypeScript stack for jobs that shouldn't slow down a request, such as attachment expiry, CDN purges, search refreshes, billing reconciliation, trust and safety syncs, data exports, and bulk deletion.

The Gateway is where Fluxer stops looking like a normal web app. It's plain Erlang on OTP 28, and it owns the live side of the system: WebSocket connections, sessions, event fanout, presence, guild routing, voice and call state, and push notification delivery. In production it's split into specialised tiers for websocket connections, sessions, guilds, presence, calls, and push. The websocket tier stays stateless, while the stateful tiers own the live data they're responsible for, which makes production rollouts and failures easier to contain.

Media lives in Rust because it's CPU-heavy, memory-sensitive, and exposed to untrusted input. The Media Proxy runs on axum and Tokio and handles uploads, thumbnails, metadata, transforms, external media, static files, and the upload relay. The heavy lifting goes through libvips, libheif, and FFmpeg behind a hand-written C shim, with Rust wrapped around it for memory safety, strict input limits, bounded concurrency, and request coalescing. If a hundred people open the same image, they share one transform instead of making the system do the same work a hundred times.

Rust also sits behind the API for hot paths that benefit from a smaller, more predictable service. In the code that's public today, that means services for users, messages, link unfurling, and Snowflake ID generation, modelled on the data services Discord built between its API and its database. They use NATS-based RPC, caching, and request coalescing where it helps. Production search runs on Elasticsearch, and self-hosted instances can choose Meilisearch when they want a lighter search backend. The Snowflake service uses the same 2015 epoch and 64-bit layout as Discord's, so IDs sort by time the same way.

NATS carries internal RPC and background jobs, the Gateway calls back into the API when it needs app data, and Valkey handles caching, rate limits, locks, cache invalidation, pub/sub, and small internal queues.

The API is the authority for accounts, permissions, billing, and app data. The Gateway is the authority for live sessions, routing, presence, and real-time delivery.

The public repository lagged until 15 June 2026 because the growth spike forced urgent anti-abuse and production work while I kept Fluxer.app stable. The sync separated Fluxer.app deployment settings from reusable server code and moved the remaining operator work into the open.

A typical self-hosted deployment is much smaller than the hosted setup. The Kubernetes clustering and role-split tiers described above are specific to Fluxer.app; you shouldn't need to recreate my production cluster to run your own instance. The small setup keeps the app services together and needs only a database, Valkey, and NATS. The goal is Docker images plus a web setup wizard that walks you through configuring an instance. Small instances can run on a Raspberry Pi.

The Electron desktop path starts with custom backends through in-app account switching in the regular client, so you can run your own instance without waiting for full federation.

Why three languages?

A polyglot backend sounds like a maintenance tax, and it can be. It pays off here because the three languages line up with three very different kinds of work, while the fast-moving majority of the app stays in just one of them.

Most of Fluxer is ordinary app code: accounts, permissions, billing, moderation, settings, REST endpoints. It's I/O-bound and changes constantly, so what matters is how fast one person can move through it. That work lives in TypeScript, end to end. The same language runs the API, the Worker, and the web and desktop clients, and they share types, validation, constants, and even a Discord-compatible Markdown parser (written in Rust, compiled to WebAssembly) across the wire. One person can follow a feature from a button in the client to the row in the database without switching mental models. For a codebase built mostly by one developer, that shared surface is the main reason I can keep moving fast.

The real-time layer is a very different problem: hundreds of thousands of long-lived connections, each needing isolation, supervision, and cheap concurrency. Erlang/OTP was built for exactly that, and trying to rebuild it in a general-purpose language is how you end up living Virding's First Rule (quoted below). Discord and WhatsApp both proved the model at a scale Fluxer won't reach for years.

The third kind of work is CPU-bound and sensitive to latency and memory: decoding untrusted media, and shielding the database from read amplification. There, a garbage collector and an interpreter get in the way. Rust gives predictable memory, no GC pauses, safe concurrency, and a safe way to wrap the C media libraries. It's also the language Discord reached for when the BEAM VM's garbage collector struggled with large data structures.

So the split is: keep the fast-moving majority in the language that lets me move fastest, and use specialised runtimes only where the work needs them. A small team keeps moving while the parts that need to scale have room to scale.

Why choose Erlang/OTP?

The Erlang runtime system is designed for distributed, fault-tolerant, soft real-time, highly available, non-stop applications, with hot swapping to change code without stopping the system.

Hello Mike. Hello Joe. Hello Mike. Hello Robert. Hello Joe. Hello Mike. Hello Robert. Hello Mike. Hello. Looks like we fixed the bug!

It was originally developed as proprietary software at Ericsson, a Swedish telecom company, by Joe Armstrong (who wrote his PhD thesis at my university, KTH, in the year I was born), Robert Virding, and Mike Williams in 1986. It was released as open source in 1998 and is maintained by the OTP unit at Ericsson.

Notable large-scale users include WhatsApp, plus Discord via Elixir (which compiles to bytecode for the same BEAM virtual machine that Erlang runs on). WhatsApp is far larger than Discord: more than 3 billion MAU, largely built on Erlang, with a famously small engineering team.

I tried several real-time architectures before accepting this rule:

"Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang."

Robert Virding, co-creator of Erlang

Fluxer's real-time system is heavily inspired by Discord and wire-compatible with enough of Discord's protocol to make porting existing Gateway bots easier. A websocket connection identifies itself, a session process owns that live client state, and guild and presence processes decide which sessions should receive each event. Short disconnects can replay missed events instead of rebuilding the whole initial state, while member and presence updates stay lazy, incremental, and compressed. This is the same direction Discord went when they cut their WebSocket traffic by 40%.

A big guild's member list can hold hundreds of thousands of entries that change constantly, and your client only ever wants a small, sorted slice of it. Fluxer keeps the member rows in ETS, but the sorted index behind rank and range reads lives in a Rust NIF, just like the approach Discord described when their BEAM-side sorted member list created too much garbage-collector and allocator pressure. The NIF owns a compact order-statistic tree, so Erlang keeps supervising the guild process while Rust handles the insert/delete/rank/range work that needs predictable memory behaviour.

Kudos to the engineering team at Discord for the inspiration.

Why choose Cassandra?

Fluxer.app uses Cassandra in production today. Self-hosting is being designed to support Postgres too, because smaller instances shouldn't have to run the same database setup as the hosted service.

For a long time, ScyllaDB was my database of choice, and Discord also migrated to it after running Cassandra. As of December 2024, though, ScyllaDB is no longer open source software, which is a deal-breaker for me.

Cassandra has trade-offs. I keep using it because it fits Fluxer's write-heavy, event-driven design.

First, Cassandra makes it hard to be accidentally inefficient. You have to think upfront about how your data is modelled and queried, because inefficient queries are either impossible or explicitly opt-in through features like ALLOW FILTERING.

Second, Cassandra prioritises high write throughput, and Fluxer is built to keep reads low. When you send a message, the database does very little: it validates your auth session (a read usually served from cache) and writes the message row. Permissions are answered by the Erlang Gateway over RPC, which keeps an in-memory cache of everything needed to compute permissions in a community (called a guild internally), so a permission check is a fast internal call instead of a query. Clients mostly read from the database when starting a new session to populate initial state; after that, everything stays in sync through the event dispatching system.

Third, operationally, Cassandra avoids a class of problems I've struggled with in traditional RDBMS setups at hosted-service scale. Postgres is the right direction for smaller self-hosted instances because people already know how to run it, but Fluxer.app has different constraints. Cassandra keeps the hosted deployment away from JOIN planning, index tuning, lock-heavy migrations, and many of the schema-change risks that show up under load.

Finally, Cassandra fits Fluxer's message rows. Unfurled links, file attachments, and similar metadata work well as embedded documents. Cassandra gives you rich types like sets and maps, along with user-defined types that can be nested, typed, and stored efficiently, so a single document doesn't need extra table queries or untyped JSON blobs.

Building Fluxer's hosted data model around relational joins doesn't fit the access patterns. The app's already shaped like an event-driven document and key-value system, so a NoSQL database fits the hosted service better.

You mentioned Postgres for self-hosted instances?

Yes. The persistence layer is being shaped around explicit access patterns rather than ad hoc SQL sprinkled through the app. Cassandra is the hosted production backend today, and the same query model is meant to support Postgres for self-hosted instances.

Because Cassandra behaves like a key-key-value (KKV) store (partition key + clustering key, where the clustering key identifies a specific row within a partition), I already had to design my tables and queries so that every lookup requires the full key, or at least a sufficiently specific leading part of it for SELECT queries.

In Cassandra, secondary indexes are typically implemented at the application level using additional tables optimised for alternative access patterns, maintained on writes via logged batches, with optional denormalisation depending on how important it is to skip an extra read for the full primary row. Materialised views and native secondary indexes exist, but their caveats can make them risky in production.

Given those constraints, the first Postgres backend is careful on purpose: a KV-shaped storage layer keyed like the hosted database, with prefix range queries where listing is needed. It keeps the self-hosted path close to the production data model and leaves room to add relational tables later where they clearly help.

Other database backends can come later, but the priority is one reliable self-hosted path first.

Fluxer's frontend

Fluxer's web app codebase is complex. The PWA is much better in the canary client than it was at launch. To try the newest client work, use the canary desktop build at canary.fluxer.app/download or the canary web client at web.canary.fluxer.app.

Canary has fixed hundreds of bugs and adds major voice and video work: screen sharing with audio, text in voice, DM call fixes, a redesigned input and output device system, more mic processing controls, and DeepFilterNet3 noise suppression.

The web app has to handle the details people notice immediately: infinite scrolling, stable scroll position, bounded caches, jumping in time, state reconciliation, unread handling, and Discord-compatible Markdown. Those parts are tedious, but they're the difference between a usable client and a demo.

As of 15 June 2026, the native app, built with Flutter, has moved past Visionary testing. The iOS app is in a limited TestFlight beta with a small group of Plutonium subscribers, since TestFlight slots are capped, and the Android app is available now as an APK from github.com/fluxerapp/flutter_client. Both are early alphas, so expect missing features and bugs while they move towards a public release. The mobile app code is open source.

Unlike Discord, Fluxer welcomes client changes: custom themes, non-malicious account automation, third-party clients, and anything else that tickles your fancy. It's all open source anyway, so you're welcome to send changes that fit the goals of the project. Just open an issue first to discuss it :)

Electron? Right to jail, right away

Fluxer currently uses Electron. I know, I know. I'm not too happy about it either. Tauri isn't mature enough for what I need yet, and I ran into hurdles there that I didn't have in Electron. In the spirit of choosing boring technology, Electron unfortunately wins. A lot of apps give Electron a bad name, but it doesn't have to be that way.

Tauri uses the system webview. That sounds great on paper, but it leaves the desktop app at the mercy of whatever runtime the OS provides, with whatever bugs come with it. And when those bugs happen, you can't ship a fix by updating your runtime, because the runtime is tied to OS updates.

I'll look at Tauri again when there's a mature, supported option for shipping a consistent runtime with it, like CEF (cef-rs).

For most people, Electron is an acceptable choice because it gives Fluxer a consistent desktop runtime while sharing the same client base as the web app.

I believe in the web platform for this kind of application. It's mature, cross-platform, well understood, and good at complex interfaces that need to run on many devices. It's also the platform I know best, which is part of why Fluxer could ship with a PWA from day one.

The first PWA had mobile issues, but it worked, and canary has improved it a lot. You can see that work today while the native Flutter app moves through its iOS TestFlight beta and open Android APK toward a public release.

The best mobile client is native, which is why the Flutter iOS and Android app comes first. Flutter can target desktop later, and that may become a better option than Electron for low-end devices down the line. Until then, the priority is simple: ship a reliable client that behaves consistently across web and desktop.

The LLMephant in the room

I've used LLMs sparingly as a troubleshooting and planning aid on Fluxer. Fluxer isn't vibe-coded, and describing it that way would be false and unfair to years of work. I'd never outsource my judgement to an LLM; limited use was a necessary compromise while I was carrying too much of the project alone, when the alternative was abandoning Fluxer or raising venture capital to ship it. I'm strongly opposed to the venture-capital path for Fluxer, and open source contributions now mean I no longer need to handle every part of the project by myself. Fluxer's core predates LLMs becoming normal in software development. The architecture, safety decisions, technical choices, and product direction are mine, and I only ship changes I understand and can explain. I expect the same from external contributors.

Who is building Fluxer now?

Fluxer is no longer a one-person project, but the team is still small for something this big.

I'm still the only person who has worked across the whole codebase from the beginning, and I spend most of my time building the app, working on backend architecture and reliability, and handling production operations. Support, trust and safety, abuse prevention, billing, accounting, and internal tools have all spent time on my desk too.

Around that, someone is helping with direction and safety: where Fluxer goes, report review, policy work, and safety tooling. An engineer focused on systems works on scaling, monitoring, CDN work, internal tooling, and voice server deployment. The native iOS and Android app has a paid contributor focused on the mobile app, and a newer team member is taking support and billing load off my plate.

Frequently asked questions

What about the open web?

Chat apps have swallowed useful knowledge that used to live on the public web, then made it invisible to search engines, archives, and people who aren't logged in.

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 starting point here. LLMs shouldn't turn people's "meandering conversations" into web content. 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 putting parts of their forum-style spaces on the open web: open source projects, developer communities, modding groups, creator communities, research groups, support forums, and any other space where public answers are meant to be searchable and useful later. Private chat stays private.

This looks a lot like Discord!

Yes, on purpose. Community chat has a shape people already understand: server list, channel list, message timeline, member list, composer, and voice controls. Discord didn't invent that; it built on patterns already familiar from IRC, TeamSpeak, Slack, forums, game launchers, and older community tools.

Fluxer values a clear first screen over novelty. A Discord-like app needs to feel easy to understand for people coming from Discord. Familiarity makes switching less painful, keeps muscle memory intact, and lets Fluxer focus on the parts people actually care about: ownership, openness, privacy, performance, self-hosting, federation, safety, and who the app answers to.

Copyright works the same way. It protects specific expression, not the general idea of putting servers, channels, messages, members, and voice controls where people expect them. In the US, 17 U.S.C. § 102(b) says copyright doesn't cover ideas, procedures, systems, or methods of operation. TRIPS Article 9(2) says the same internationally. EU software law says the ideas and principles behind interfaces aren't protected by copyright, and the CJEU held in SAS Institute v World Programming that functionality isn't expression. Nobody owns the basic pattern of a usable community chat interface.

A comparison image showing similar community chat layouts across older apps. — Source: Imgur, "Whenever someone says Discord's UI is revolutionary."

Changing the layout only because people might compare it to Discord would make the app harder to use. Fluxer changes things where it actually improves the app; forcing people to relearn where messages, channels, servers, and voice calls live just adds friction.

I've tried several different takes on the UX, and they ended up messy. I've also tried newer apps that recreate the Discord experience while trying too hard to feel new, and so have many people I've spoken to. They're harder to use than they need to be.

Is Discord's UX perfect? Of course not, and parts of it have got worse over time. But the older Discord model is still one of the easiest ways to understand a modern community chat app. Most open source options fail because they neither feel familiar enough to switch to nor complete enough to replace what people already use. The result may be principled, but it feels worse to most people. Classic Discord also feels nostalgic for many of us longtime users, from before the redesigns. Fluxer can improve the details while keeping a working mental model people already understand.

Fluxer will go its own way over time. As self-hosting, public web publishing, multi-backend support, federation, moderation tooling, voice and video, and client customisation get better, Fluxer becomes more clearly its own thing. It starts from something familiar and changes where it has a better answer.

Fluxer also lets you fully customise your client's look with custom CSS, and UI experiments are welcome when they improve usability.

Why the name Fluxer, and why Plutonium?

The honest origin is simple: Back to the Future is my favourite film series.

In the film, the flux capacitor is the thing that makes time travel possible. The DeLorean needs to hit 88 mph and draw 1.21 gigawatts, first from a plutonium-powered reactor. Fluxer and Plutonium are both little nods to that. Yes, naming your subscription after fictional nuclear fuel is a bit silly, which is part of the fun.

There's a more literal meaning too. Flux means change, movement, fluctuation. Chat is constantly moving: new messages, new people, new context, old conversations becoming something else over time. A chat app is almost never in a fixed state.

The logo comes from the same idea. The approximately-equal sign fits something in flux: recognisable, but always changing.

The name also points at the broader goal: a better path for community chat.

How long did Fluxer take to build?

The first version started around 2020, while I was still in high school during the pandemic. It became my graduation project, then a long-running side project tested by friends while I studied and worked on other things.

The final run-up to public release began after I finished my bachelor's thesis in summer 2025. The private beta opened in October 2025, and Fluxer was publicly released on 2 January 2026.

The launch was quiet at first. Then Discord IPO news and Discord's age-verification announcement on 9 February 2026 put Fluxer in front of far more people than I expected. The hosted instance grew to around 195,000 users, with a peak of about 11,000 concurrent connections, while the team was still effectively one full-time engineer. The team is larger now, but still small.

Why build a chat app at all?

Community chat has been my focus for years. I've been deep in Discord's world since 2017: testing, reading engineering posts, following architecture discussions, reporting bugs, and talking to people who understand that world.

Fluxer started as a technical challenge but became about more than code over time. I wanted a modern community chat app without one company controlling the app, data, network, and business model. Self-hosters, technical communities, open source projects, and creators all need software they can trust, customise, and move away from.

Fluxer preserves the parts of this kind of chat that work, makes the software free and open source, and builds towards decentralisation so the future is no longer decided by one company.

I've built a Discord bot. Will it work on Fluxer?

Partly. Fluxer's HTTP API and WebSocket Gateway API are heavily inspired by Discord's and, in many cases, directly wire-compatible with it. That means you can reuse existing Discord libraries and abstractions in many languages.

For example, you can use the core libraries from discord.js directly. It's a bit more low-level, but enough for many bots, and the Fluxer API docs guide you through a quick start with this approach. Adapting existing Discord libraries can also work. Or build your own community-maintained Fluxer SDK and email me (hampus@fluxer.app) to get it featured in the docs, or submit a pull request in the GitHub repository.

The API and self-hosting docs are being cleaned up in public after the 15 June 2026 repository sync. If something is unclear, file an issue or email me.

Slash commands and similar features are still coming. If you want that work to happen sooner, Plutonium and donations help buy the time to build and publish it properly.

Why do attachments expire?

Because storage costs money, and Fluxer has no venture capital funding.

Large media adds up quickly. If every image, video, and random file stayed forever, the hosted instance would become free cloud storage with a chat app attached, which breaks the economics of a bootstrapped app trying to stay independent.

Expiry is based on file size. Small files last much longer, with the smallest lasting about three years, and files can be renewed a little when they're accessed. The exact behaviour is documented in how attachment expiry works.

Attachment expiry keeps storage under control and also protects privacy; most attachments have no reason to live forever. If you self-host Fluxer, the policy is yours to configure, including whether expiry is enabled and how much storage your instance allows.

Will Fluxer become like Discord?

Fluxer's structure is meant to keep exits open. Fluxer.app funds the shared codebase through hosted revenue, including Plutonium. Its role is to improve the software for people who use the hosted instance and people who run it elsewhere. The software is intended to be self-hostable, and the long-term plan includes self-hosting, data portability, multiple backends in one client, and federation.

Open source makes trust easier because running your own instance is possible.

Why monetise Fluxer?

Because running a real-time chat app costs real money, and so does maintaining the open source version people can run themselves. Compute, storage, bandwidth, monitoring, safety tooling, payment processing, support, and people's time all have to be paid for somehow.

The question is who the app has to answer to. Venture capital can make an app look free for a while, but it usually comes with pressure to grow faster, extract more, and eventually answer to investors before users.

The model is to keep a generous free tier, charge for higher limits on the hosted instance, accept donations from people who want Fluxer to keep going, and keep self-hosting free. Hosted revenue should buy time to improve the shared codebase, with public development at the centre of the work.

Is Fluxer free and open source?

Yes. Fluxer is free and open source. The public repository is github.com/fluxerapp/fluxer, and the goal is that the hosted Fluxer.app service and self-hosted instances share the same useful base. The hosted instance pays for the work and tests it with real traffic, while instance operators get the tools they need to run Fluxer themselves.

Until 15 June 2026, the public repository lagged because the growth spike forced urgent anti-abuse and production work while I kept Fluxer.app stable. The sync separated Fluxer.app deployment settings from instance settings other people can use, and moved the remaining operator work into the open.

Pull requests are open, and Fluxer is open by default.

Will self-hosting cost money?

No. Running your own Fluxer instance requires no licence key, paid tier, or special enterprise unlock. You're responsible for hosting, uptime, moderation, safety, and legal duties, but the software itself is free to run.

The Operator Pass is planned for when the docs and setup guides are solid. It's 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 docs stay public.

Federation?

Federation remains a major goal, 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.

The self-hosting path starts with account switching for custom backends in the Electron desktop app. The next client step is simultaneous connections to multiple backends without making you switch between workspaces. The goal is one client that can show several instances together before Fluxer has the unified identity and authentication model that full federation needs.

True federation can come after that, with OAuth2-based authentication against remote instances and a clearer model for where identity and data live.

How does moderation work?

Each Fluxer instance is responsible for its own moderation. Fluxer Platform AB operates the hosted Fluxer.app instance, so that's where the company is responsible for reports, safety enforcement, legal compliance, and abuse prevention.

The 15 June 2026 repository sync also separated moderation, abuse-prevention, and operator tooling from Fluxer.app-specific settings. Instance operators should get the full toolset in a form they can actually use, with the remaining work happening in public.

Fluxer Platform AB is also a registered electronic service provider (ESP) with access to the CyberTipline Reporting API from the National Center for Missing & Exploited Children (NCMEC).

Once federation exists, moderation stays local to the instance enforcing it. A ban on one instance stays local unless other instances choose to share or honour that signal.

Why do you follow local laws in my country or state?

For self-hosted instances, this is the responsibility of the person running the instance. If you run your own instance, you decide where you provide service and what legal risk you accept.

For the hosted Fluxer.app instance, Fluxer has to follow the law where it serves traffic. Some recent age-verification laws are invasive enough that I'd rather restrict access than collect government IDs or biometric data from everyone.

As of 24 May 2026, Fluxer restricts NSFW access in the United Kingdom and Brazil. In the UK, Fluxer can offer a less invasive optional adult check through a $0.00 credit card authorisation. Brazil currently lacks a private enough path I'm comfortable with. Mississippi requires age verification for access to the whole service, so the hosted Fluxer.app instance blocks access from Mississippi instead.

The current details are kept in regional restrictions and minimum age requirements.

Where does Fluxer run?

Fluxer.app currently runs in US East on Vultr. That location gives good connectivity to both North America and Europe, which helps message loading and real-time delivery.

I'm paying attention to the global legal and data issues. The US CLOUD Act and questions about where data lives are real. Longer term, federation makes it possible to separate accounts and communities by region, including EU-only hosting, and moving more systems to Europe remains an option.

Voice and video are already more distributed. Current RTC regions include Sydney, São Paulo, Santiago, Frankfurt, Stockholm, Warsaw, Madrid, Mumbai, Singapore, Seoul, Johannesburg, Newark, Atlanta, Dallas, Seattle, and Los Angeles.

What happens when Google shuts down Tenor?

Fluxer currently relies on Tenor for GIF search in the app, and Google is shutting down the current Tenor API on 30 June 2026. Fluxer already has KLIPY support in the codebase. KLIPY was built by former Tenor people and is the planned replacement when the current Tenor API stops working.

GIFs are proxied through Fluxer either way, so the privacy promise stays the same: providers don't see your IP address just because you searched for or viewed a GIF through the app.

End-to-end encryption?

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

Hacker News

Most people want a Discord alternative they can use day to day: fast clients, search, profiles and statuses, custom emoji, roles and permissions, voice and video, and moderation tools. Fluxer's priorities are there first. Adding E2EE to text messaging makes the app much harder to build and maintain, and Fluxer is focusing first on a stable community chat app that covers the basics people expect.

Text on Fluxer has no end-to-end encryption today. Optional E2EE is still planned where it fits: personal notes, calendar data, DMs, and small groups. E2EE for large communities is out of scope.

Voice is further along. Canary already uses LiveKit's built-in E2EE support for voice and video in testing communities that have it turned on. It rolls out to everyone soon, then becomes required as supported clients catch up.

Native mobile app?

Yes. The native app is built with Flutter for iOS and Android. As of 15 June 2026, the iOS app is in a limited TestFlight beta with a small group of Plutonium subscribers, since TestFlight slots are capped, and the Android app is available now as an APK from github.com/fluxerapp/flutter_client. Both are early alphas, with a public release to follow.

The Flutter app can also target desktop later, making it an alternative to Electron for low-end devices. For now, iOS and Android come first.

The canary PWA has improved in the meantime. To use the newest client work before stable, try canary.fluxer.app/download or web.canary.fluxer.app.

Can I help localise Fluxer?

Yes. 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

Localisation matters. Fluxer shouldn't assume everyone speaks English, and it needs to feel usable internationally whether English is your first language or not.

Because the app changes quickly and the team is small, many translations are drafted and kept up to date with LLM help. 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 and helps non-English speakers get a better app sooner.

That first pass only gets Fluxer started. Native speakers catch what a model can miss: tone, terminology, awkward phrasing, and cultural details. People have told me the current localisation is already usable in many languages, but I still want native speakers involved before treating it as something people can rely on.

Localisation is moving 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.

Do you have a Contributor Licence Agreement?

No. Fluxer had a CLA early on, mostly because the expected path at the time looked more like self-hosting support and companies running Fluxer themselves. A CLA would have made it easier to offer a separate commercial licence to organisations whose policies prohibit AGPLv3 software.

After Fluxer took off as a hosted app for regular users, that deal stopped making sense. The CLA is gone now that pull requests are open and the public repo has caught up.

Where's the roadmap?

Closing thoughts

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.

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

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. Fellow independent, bootstrapped, privacy-first alternatives and press inquiries are welcome too.

Fluxer should become a real alternative to Discord without losing why it was started.

See you in the Fluxerverse!

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