Vibrefy — a media server that doesn't watch you back

I finally open-sourced something I've been running for myself for a while: Vibrefy, a lightweight, self-hosted media server. Code's up on GitHub: github.com/peprasetya/Vibrefy.

The short version: it streams video from a local library, or from your own cloud storage (currently support: Google Drive, OneDrive, pCloud, or FileLu account), straight to the browser. The server proxies everything, so nothing but the video itself ever leaves it.

Why build another one, when Plex/Jellyfin/Emby already exist?

Two opinions I couldn't shake:

No database. Every media server I've used runs a database in the background — cataloguing, indexing, building a profile of what you watch. Vibrefy doesn't. Configuration lives in one JSON file, and the only per-user state is a small encrypted file that remembers where you left off in something, so it can resume it. That's it. No schema, no service to babysit, no "backup strategy" beyond copying a folder. You can move the whole install by dragging it to another disk.

The honest trade-off: there's no watch history, and nothing being collected to guess what you'll like next. If you want a recommendation engine, this isn't it. If you want something you can fully understand and hand to a friend without explaining a database schema, that's the whole point.

Landscape covers. Every media server inherits the vertical movie-poster look, because that's what DVD boxes and cinema posters happened to be shaped like. It's a strange default for something rendered on a screen. Vibrefy generates its thumbnails in 16:9, matching the video itself — so browsing looks like a shelf of screens, not a shelf of posters.

What it actually does:

• Browse and stream a local library, with resumable playback per file
• Mount your own cloud storage (currently support: Google Drive, OneDrive, pCloud, FileLu) and browse it exactly like a local folder
• Auto-play the next episode of a series
• Subtitles pulled straight out of the video container
• Cast to AirPlay, fullscreen, or Picture-in-Picture straight from the player
• OpenID login, first-run setup, no manual account provisioning, no password.

It's Java EE under the hood — Jakarta Servlets, JSP, vanilla JS, no framework sprawl — MIT licensed. Feedback, issues, and PRs welcome.

JWebDBAdmin, 21 Years Later: I Finally Reinvented It

 

Some background

Back in 2010 I wrote about a project I'd already called "very outdated" — a little web-based SQL runner I built in 2005 because I was tired of juggling database clients for every engine my company touched. I said then: "there is no more development."

That was true for sixteen more years.

The old JWebDBAdmin never actually died, though. It kept quietly running in production the entire time. I still used it weekly. I just stopped touching the code — except for the occasional patch nobody wrote a blog post about, like swapping the login screen from a plain username/password form to Google sign-in, back when that became the sane thing to do instead of storing another password nobody would rotate.

This year I finally reinvented it. Not a patch this time — a full rewrite, from a blank editor, but built on top of two decades of "I should really fix that" notes I never had time to act on in 2005. Everything got a second chance to be done right.

Why bother, 21 years later?

Honestly — because I could finally build the version I wanted in 2005 but didn't have time for. And because AI coding assistants make "let me just rewrite this properly" a weekend project instead of a quarter.

I also gave myself one hard rule this time: zero dependencies. No Maven, no Spring, no npm, no CSS framework, no JS library. Just plain Java servlets and plain HTML/CSS/JS. Partly discipline, partly spite toward every project I've inherited that needed forty transitive dependencies to render a table.

What's actually new

• SQL autocomplete that knows your schema. Not just keywords — it knows your tables, your columns, and resolves aliases. Type a. after ... FROM agents a and it lists agents' columns. Type Sele and hit tab, it hands you SELECT * FROM [table] WHERE with your cursor already in the right slot.
• Edit results in place. Double-click a cell in a single-table SELECT with a primary key, change the value, hit Enter. No separate "edit mode."
• Favorites your non-technical coworkers can actually use. Save a query with {{param}} placeholders and they render as input boxes. Nobody has to know what a WHERE clause is.
• An AI assistant that's actually useful, not a gimmick. Point it at any OpenAI-compatible endpoint — including a local Ollama, so your schema and data never leave your network. It knows your table structure, your indexes, your current query. Ask it a question in plain English and read-only queries just run; anything that changes data comes back as a suggestion you review and send to the editor yourself. It never executes a write on its own. And when a query fails, it looks at the error and offers a fix without you having to ask.
• A destructive-query guard that's actually enforced server-side — DELETE/DROP/TRUNCATE are off by default, and turning them on is a config change, not a UI toggle someone can click by accident.
• Login through Google, no passwords at all. Nothing to store, nothing to leak, nothing for someone to reuse from another breach. You're pre-registered by email and that's the whole account system.
• Dark mode that follows your OS, because I got tired of every "dark theme" secretly being navy blue.
• Still a one-file drop-in deploy. Same database schema as always — your existing users, favorites, and history just work. If you're one of the three people who used the original: nothing to migrate.

Try it

Source, MIT licensed: github.com/peprasetya/jWebDBAdmin

First release, tagged and ready to drop into Tomcat: v20260720 release

The original 2005 project stays up on SourceForge as an archive — this is where it actually lives now.

If you've got a Tomcat instance lying around and five spare minutes, it's a two-file deploy: drop in the WAR, drop in a properties file. Would genuinely like to know if it's useful to anyone besides me — that's most of the point of putting it on GitHub this time instead of leaving it running quietly for another 21 years.