Fluxer combines community chat with voice and screen sharing
Fluxer is built for the same social shape as Discord: friends or communities gather in channels, exchange messages, and join voice or video sessions. The repository spans the web application, desktop client, API, gateway, media handling, static assets, administration, and support services. That breadth makes it more convincing than a chat-interface mockup. It also means operators inherit many moving parts that users of the hosted service never see.
The public README is only 936 bytes and gives a one-sentence description, project links, license, and screenshot. Practical information lives in the separate operator documentation. That guide explains how to bring up a self-hosted instance with the web app, API, gateway, admin dashboard, uploads, search, storage, and LiveKit signaling behind one hostname. Reading the README alone badly understates both the capability and the work.
Self-hosting starts with a multi-service Compose stack
The operator guide requires Linux, Docker Engine 24 or newer, Compose v2, a hostname, and either public ports 80 and 443 or a Cloudflare Tunnel. Its minimum is 2 vCPU, 4 GB RAM, and 20 GB disk; a small active community is directed toward 4 vCPU and 8 GB RAM or more. The stack idles at a few gigabytes of memory, with startup described as the heaviest period.
Configuration is not a one-password form. The supplied environment file needs Postgres, Meilisearch, object-storage, gateway, media-proxy, admin, and LiveKit secrets, plus VAPID keys. Caddy handles the public hostname and certificates. Email starts disabled and needs SMTP settings. The first accepted registration receives wildcard admin access, so registration timing and firewall exposure matter on the first boot.
What happened when we ran it
Our sandbox installed 1,761 pnpm packages in 71 seconds and occupied 1,630 MB. The source tree at commit 8649715 was already 435.3 MB, with 13,919 files and about 1,187,165 source lines. This is the largest kind of application monorepo: contributors need Node tooling plus Rust and WebAssembly pieces before they reach the product behavior they intended to change.
The build ran for 176 seconds and failed. Rust reported that it could not find the crate for core, noted that the wasm32-unknown-unknown target might be absent, and suggested rustup target add wasm32-unknown-unknown. Cargo exited 101, which caused the fluxer_app workspace build and the recursive pnpm command to exit 1. The log supports a missing target diagnosis; it does not show another compiler defect.
Tests also exited 1 after 77 seconds. The lab's headline vitest measurement recorded 15 passed and 0 failed out of 15. The recursive tail showed other workspaces too: Hono had 186 passing tests and the SMS package had 34, while fluxer_app reported 1,767 passed and 2 failed out of 1,769. The named failures were VoiceVolumeUtils.test.ts and RouterCore.test.ts; 8 of 211 app test files were marked failed.
Those results make the source path materially rougher than using published images. Our scan found 24 CI workflow files and pnpm workspaces, but no Dockerfile or top-level tests directory in the checkout. The operator stack downloads service images, so a self-hoster can avoid compiling this monorepo. Contributors and security-conscious operators who build their own artifacts cannot.
Voice requires public media ports or a TURN server
Caddy proxies LiveKit's HTTP and WebSocket signaling, but WebRTC media follows a different network path. The guide calls for 7882/udp as the normal media route and 7881/tcp as fallback. Port 7880 remains private for signaling. A Cloudflare Tunnel can carry the web application and signaling, yet it does not carry normal LiveKit voice and video media. NAT or restrictive networks may require TURN.
This distinction should decide whether a trial reaches production. Test calls between different networks, mobile carriers, corporate firewalls, and each supported desktop platform. Current reports include broken Windows 11 screen-share audio in issue #1822, gray Windows-to-Linux screen sharing in #1107, and codec-selection trouble in #2019. These are user reports rather than universal findings, but they identify the exact paths a community should exercise before migration.
Self-hosted desktop access has another firm limit. The operator guide says the desktop client cannot connect to self-hosted instances yet and directs users to the web app. It says work is underway, but that wording is not a shipped feature. Groups whose members require a desktop wrapper, native notifications, or a managed app experience should test the web-only constraint with real users first.
Backups span Postgres, object storage, and secrets
The guide tells operators to preserve .env, postgres-data, and seaweedfs-data. It provides a cold-backup procedure that stops application services and archives the volumes, while recommending a Postgres-native dump plus object-storage backup for production. Restoring only the database would leave uploaded media behind; restoring data without the environment secrets could break service-to-service access.
Upgrades pull the configured image tag and recreate services. The default v1 tag follows the latest compatible release, while FLUXER_IMAGE_TAG can pin a specific release. Old images accumulate by a few gigabytes over time. Pinning, reading release changes, and rehearsing a restore are sensible for a communication service whose database, files, and credentials must stay in sync.
August releases are fast, while maintenance is concentrated
GitHub recorded the last push on August 27, 2026, and 102 combined issues and pull requests. The latest returned release was an app-proxy build published the same day. Reports and changes were moving quickly across mobile, desktop, voice, packaging, and self-hosting. Issue #1808 adds important context: one person says they currently maintain the open-source repository, backend infrastructure, and both clients.
Fluxer has the product scope to serve a real community, but its operational and staffing risks are visible. Our failed build and app tests do not make the published service unusable; they do make source-based adoption a hands-on job. The best trial is a small private community using the web client, with voice tested across hostile networks and backups restored before invitations widen.