Nextflux is a React front end for a Miniflux server

A front end, with a specific backend and no others

Nextflux is described as a modern RSS reader client for Miniflux built with React and Vite, and the project description is blunt about the category, calling itself yet another web-based frontend for Miniflux. The one-server constraint is the defining fact, and the FAQ says it directly: there are no plans to support the Fever or Google Reader APIs, because for now the author is all in on the Miniflux API. That is a narrow scope, and it is worth understanding before you install anything, because it means the app is not a general aggregator client that happens to work well against one server. It is a purpose-built front end for a specific backend, and the compose file and the Docker instructions both assume you have or will run Miniflux alongside it. The last push was on 2026-10-16 and the project publishes no GitHub releases.

Running one container, or three of them

The standalone Docker path is a single command:

docker run -d --name nextflux -p 3000:3000 --restart unless-stopped electh/nextflux:latest

The compose route is the other one, and the file in the repository brings up three services rather than one. Miniflux runs from the miniflux/miniflux:latest image with port 80 mapped to 8080, a DATABASE_URL pointing at Postgres with RUN_MIGRATIONS and CREATE_ADMIN enabled, and a healthcheck that runs the miniflux binary with a healthcheck argument. The database is postgres:17-alpine with its own volume and a pg_isready healthcheck on a ten second interval. Nextflux itself is the third service, depending on Miniflux being healthy before it starts. The compose file ships with example credentials, since the README says to copy it and replace the passwords, and the admin password in the example is literally test123.

The image is two stages ending in Caddy

The Dockerfile shows what the container actually is. The build stage is node:20-bookworm-slim, which copies package.json and package-lock.json, installs with npm ci, copies the rest of the source and runs npm run build. The runtime stage is caddy:2-alpine, and it copies the built assets out of the builder stage with COPY --from=build /app/dist /srv, so the shipped image contains no Node runtime and no source. The Caddyfile from the repository root is copied to /etc/caddy/Caddyfile, the container exposes port 3000, and the command is caddy run with the caddyfile adapter. So the image is a static build served by a web server, and the whole front end runs in the browser. That is also why the app can be deployed to Cloudflare Pages instead, since the output is the same dist directory either way.

Multiple accounts with separate caches

The account model is the part that goes beyond a plain client. You can save several Miniflux accounts and switch between them, using the account menu at the bottom of the sidebar with the Add account option, and each account can authenticate with a username and password or an API token, against the same server or different servers. The separation is thorough. Articles, feeds, icons and sync progress are cached separately for each account, while appearance and app preferences are shared. Existing logins and their cached data are migrated automatically, and logging out removes only the current account's saved credentials and local cache, then selects another saved account if one is available. When you switch accounts the app reloads at the home page and other open tabs follow the selected account, which is a detail that matters if you have several windows open on different feeds.

The reading features, and the parts that are polish

The feature list is where you can see the author's priorities. There is automatic background sync on configurable intervals, OPML import, OPML export with settings backup and restore, category organisation, feed hiding, feed discovery and search, and advanced options for feed management. The reading experience itself includes custom font settings, an image gallery with touch gesture support, and saving an article to third party services. Keyboard shortcuts are there, mark as read on scroll is there, and a light and dark mode with multiple theme options is there. The interface is built with HeroUI, previously called NextUI, and the README is candid about the influence, saying in the FAQ that the design resembles Reeder because the author's own design skills are about as good as a potato's and Reeder's UI style was the inspiration. The mobile note is equally direct, that the app is primarily designed for desktop and that native readers will give a better experience on the go.

The dependency list explains the offline story

The package.json shows how the offline behaviour is achieved, and it is not with a service worker alone. Dexie and dexie-react-hooks provide IndexedDB, and nanostores with @nanostores/persistent provides the persistent store layer, so the cache is a real client-side database rather than a pile of localStorage entries. That is why per-account caching is possible at all, and why the app can hold articles offline with a service worker for the shell. The rest of the stack is a large React 19 application: react-router-dom for routing, framer-motion for animation, react-virtuoso for virtualised lists, which matters for a feed with thousands of entries, react-photo-view for the image gallery, html-react-parser to render article HTML, i18next with react-i18next and a browser language detector for the four translations, axios for the API calls, dayjs for dates, and lucide-react plus the icons pack for the icon set. Tailwind CSS 4 with the typography plugin handles the styling, and there are packages for HLS and YouTube video playback through videojs, plus sonner for toasts and canvas-confetti for effects. The scripts are minimal, with dev, build, lint, test running node --test, and preview.

Where Nextflux is the wrong choice

Three cases. The first is a reader migrating from another aggregator, because the author has ruled out Fever and Google Reader support and the only way to change that is to ask for it. The second is anyone whose library is not in Miniflux, since the app is a client for one server and the compose file shows the intended pairing. The third is a team with a compliance or procurement requirement, because the licence is a sentence rather than a grant, the README telling you to do whatever the heck you want with it and adding that you should not come crying if it messes up your stuff, and the recorded licence field for the project is left as unknown. Against the browser interface that Miniflux itself ships, the difference in approach is that Nextflux is a separate single-page application with its own persistent local database, its own sync loop and its own account model, whereas the built-in interface shares the server's own session and has none of that local state.

Editorial conclusion

Nextflux is a good fit for someone who self-hosts Miniflux and wants a reading interface they can run themselves, host on Cloudflare Pages, and put behind their own domain, and who is willing to accept that Miniflux remains the only backend it speaks to. It is a poor fit for a reader who wants to move from Fever, Google Reader or another aggregator, and it is a poor fit for mobile-first reading, since the README says the app is primarily designed for desktop and points to native apps instead. Check three things before you deploy it: that you already have, or can run, a Miniflux server, since the app requires one and needs a server URL plus an API token or a username and password, that you are comfortable with the deployment options on the table, whether that is a single Docker container, a Cloudflare Pages fork or the compose file that brings up Miniflux and Postgres alongside it, and that you read the licence, because the README phrases it as do whatever the heck you want with it rather than as a standard grant, and the recorded licence field for the project is left as unknown.

Frequently asked questions

Official sources

1. electh/nextflux on GitHub
2. Issues
3. Project website
4. README