Arivu Is Simpler to Self-Host Now
Arivu now runs as a low-dependency Go application with embedded frontend assets, SQLite persistence, and fewer services to operate.
Arivu is moving in a simpler direction.
The app is now rebuilt around one Go application that serves the web UI, API, background workers, CLI commands, and migration tooling. The shipped frontend is embedded into the binary. Persistence is SQLite. Provider integrations use direct HTTP calls. The result is a self-hosted Arivu that has fewer pieces to run, fewer dependency trees to audit, and a clearer operational model.
This does not change the product goal. Arivu is still about saving web pages, turning them into useful knowledge, searching by meaning, resurfacing forgotten links, and keeping your research under your control. The change is in how much machinery you need to run to get there.
One App to Run
The self-hosted path is now easier to understand: build or run the Arivu application, point it at a SQLite database, set a small set of environment variables, and open the app in your browser.
That matters because self-hosting should not feel like operating a small platform. Every extra service adds another health check, another upgrade path, another backup concern, and another place where configuration can drift. Arivu still does serious work in the background, but the runtime shape is much smaller.
What this means for you: Local testing is faster, production deployment is easier to reason about, and backups center on the SQLite database and its related files.
A Smaller Dependency Surface
The new frontend ships as first-party browser assets embedded in the app. There is no npm application dependency tree in the deployed frontend. The backend uses the Go standard library heavily, with a small set of justified dependencies for SQLite, cryptography, and HTML parsing.
This is not a promise that software becomes risk-free. It means there are fewer packages to track, fewer transitive updates to review, and fewer places where supply-chain issues can enter the deployed app.
What this means for you: Arivu is simpler to audit. Security work becomes more focused because the dependency surface is smaller.
Security Without Extra Ceremony
The rewrite keeps the security work practical: audience-scoped sessions, CSRF protection for browser mutations, safer outbound fetching, sanitized archived HTML, encrypted provider secrets, and direct provider integrations. Those controls are part of the app rather than a pile of sidecars and glue code.
We are keeping the public explanation high level on purpose. The important point for self-hosters is that Arivu now has a smaller runtime shape and a smaller dependency footprint while keeping the features that make it useful.
What this means for you: You get the same product direction with a deployment model that is easier to maintain and easier to trust.
What Stays the Same
Arivu still saves pages, generates summaries, supports search, imports bookmarks, syncs X bookmarks when configured, and works with the browser extension. The CLI remains part of the workflow. Existing legacy data has a migration path.
The difference is that the app now fits better with the way people actually self-host: fewer services, clearer files, less ceremony, and a codebase that is easier to inspect.
That is the direction from here: keep the product powerful, make the operating model boring.