Hemera — A Lightweight Bridge for Local & Cloud AI Models

Running local LLMs often means dealing with moving targets. Runtimes like llama.cpp move at a breakneck speed—sometimes releasing multiple builds in a single day. While that pace brings support for new quantizations immediately, an engine update today can easily break or regress a model that ran perfectly yesterday.

On top of that, managing different GPU backends (CUDA, ROCm, Vulkan), missing dynamic libraries, and setting up models for different client tools usually means juggling multiple local setups.

If you want to run local GGUF models—or route to cloud providers—without worrying about an engine update breaking your setup, you quickly run into friction.

That's why I came with idea of Hemera—a flexible local AI engine manager, wrapper, and proxy router written in Java.

The Spirit of the Project

The philosophy behind Hemera is simple: unify your AI tooling into one quiet, self-contained service.

Instead of juggling different local wrappers or hardcoding provider-specific integrations into your apps, Hemera sits in the middle. It acts as both a local engine orchestrator and a multi-dialect API translator.

I wanted a tool that:

• Doesn't force a framework on you: Zero external dependencies—no Maven, no Gradle, no heavy web frameworks, and no npm build step. Just JDK 21+ and a single 112 KB JAR file.

• Never deletes what worked: Engine builds live side-by-side. Updating llama.cpp never removes older versions, so if a new build misbehaves, you can roll back or pin a model to a previous tag in one click.

• Handles local & remote natively: Reads local GGUF files directly, manages backends (CUDA, ROCm, Vulkan) per model, and makes remote models (DeepSeek, OpenAI, Gemini, Claude) look like local endpoints.

Key Features

• One Endpoint, Three Dialects: Supports Ollama, OpenAI, and Anthropic Claude endpoints on a single port (12434). Every tool in your stack—from the native ollama CLI to Claude Code—can drive your models.

• Engine Versioning & Rollbacks: Keep multiple engine releases and GPU backends (ROCm, CUDA, Vulkan, SYCL, CPU) installed simultaneously without interference.

• Smart GPU Discovery (ELF Header Inspection): If a GPU build is missing vendor dynamic libraries, it often quietly falls back to CPU execution at a crawl. Hemera reads ELF headers on startup, detects missing .sodependencies, searches system paths, and automatically sets LD_LIBRARY_PATH for that process.

• Virtual Model Aliases: A single GGUF file can be configured as multiple named models—each with its own context size, GPU offload settings, chat templates, and environment variables.

• Native GGUF Inspection & Safe Deletion: Built-in direct GGUF header reading (GgufReader.java) parses metadata without external CLI tools. Deleting a model in the UI only drops the configuration, keeping expensive GGUF files safe.

• Minimalist Web Dashboard: An embedded, zero-framework web UI (vanilla HTML/CSS/JS) that follows your OS light/dark theme for monitoring running models, engine PIDs, and proxy settings.

Under the Hood (Architecture)

Hemera’s codebase is structured around a few core modules inside ing.aether.hemera:

ing.aether.hemera
├── api         # API dialects (OpenAI, Claude, Ollama) & Proxy Dispatcher
├── engine      # Engine downloaders, ELF/Tar handling, Instance lifecycle
├── model       # Bare-metal GGUF reader & Model Registry
├── http & json # Custom HTTP router & lightweight JSON engine
└── web         # Admin REST API endpoints & static dashboard assets

1. The Proxy & API Layer (hemera.api): Intercepts incoming requests, normalizes payloads via ProxyDispatcher, translates between protocols on the fly, and routes requests to local processes or cloud APIs while preserving Server-Sent Events (SSE) streaming.

2. The Engine Orchestrator (hemera.engine): Manages executable runtimes. It resolves required native shared libraries (LibraryResolver.java), handles binary archives (Tar.java), and manages the lifecycle of local engine processes (InstanceManager.java).

3. The Model Registry (hemera.model): Instead of relying on external CLI tools to inspect files, ModelScanner searches local directories and uses GgufReader to parse tensor metadata directly from binary headers to feed the central registry.

4. Core Infrastructure (hemera.http & hemera.json): Powered by a custom hand-rolled JSON parser and HTTP router running on Java's virtual threads for maximum efficiency.

Check out the code on GitHub: github.com/peprasetya/hemera

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.

Introducing urlNeXT v2.0.0 – The Ultimate Sequence Navigator Upgraded to Manifest V3

It has been quite a while since I first built urlNeXT, but I recently decided to dust off this old project and give it a modern overhaul. Today, I am excited to announce the release of urlNeXT version 2.0.0!

If you frequently browse web galleries, documentation, forum threads, or multi-page search results, this extension was built to save you a ton of clicks.

Here is a breakdown of what’s new, how it works under the hood, and why this version is lighter and faster than ever.

What is urlNeXT?

At its core, urlNeXT is a universal sequential navigation utility. It helps you jump to the "next" or "previous" page automatically without needing to hunt down the page's native pagination links.

It works using a two-tier strategy:

1. Smart DOM Detection: It scans the web page for native pagination anchors (like Google, Bing, or Yahoo search pages, Blogger pages, or standard rel="next" / rel="prev" tags).

2. Intelligent URL Sequencing (Fallback): If the website doesn't have explicit next/prev links, urlNeXT parses the active URL string, finds numeric sequences (e.g., page=1, 001.jpg), and mathematically increments or decrements that number to transition you forward or backward.

What's New in Version 2.0.0?

1. Full Migration to Manifest V3 (MV3)

Google is phasing out older extension formats, so urlNeXT has been completely "rewritten from scratch" (a.k.a: writing prompt from scratch to Gemini to do the upgrade 😜) to adhere to modern Manifest V3 architecture. The extension now relies on a streamlined service worker structure that keeps background memory usage close to zero when you aren't actively navigating.

2. Lightweight & In-Memory Operation

urlNeXT is designed to have a near-zero footprint on your system resources. It doesn't bloat your browser or hog memory because it handles all logic dynamically. No data is ever written to your disk, and no persistent logs are kept. All active tab states are processed temporarily in-memory and completely vanish the moment you close the tab or your browser session.

3. Expanded Out-of-the-Box Pagination Support

The content scanning engine has been refined to instantly support major search providers and publishing layouts:

• Google Search: Seamless tracking using Google's native pagination targets (pnnext/pnprev).

• Bing & Yahoo Search: Direct support for native pagination classes and element layouts.

• Blogger / Blogspot: Automatic extraction of older/newer post navigation paths.

• Standard Web Standards: Universal parsing for explicit rel="next", rel="prev", and textual indicators (like Next > or « Prev).

How to Use urlNeXT

⌨️ Keyboard Navigation

If you prefer keeping your hands on the keyboard, you can navigate without touching your mouse using these global shortcuts:

• Next Page: Alt + Shift + Ctrl + Right Arrow

• Previous Page: Alt + Shift + Ctrl + Left Arrow

• Force Re-Scan: Alt + Shift + Ctrl + O (forces a refresh scan of the current page's links)

🔬 Single-Click Action Overlay

Clicking the extension icon in your toolbar will immediately execute the default directional navigation. When a page transition triggers, a clean, high-contrast animated arrow overlay renders on screen, indicating exactly which direction you are flipping through the sequence.

🎛️ Tab-Bound Configuration

If a URL features multiple numeric sequences (for example, website.com/chapter-05/page-001.html), you can open the extension's Options Page to customize your experience.

The options window will display a visual split of your current URL. You can simply click on the specific number block you want to target (e.g., locking onto the page number instead of the chapter number) and configure whether the default click action moves you forward (+1) or backward (-1). Remember: these settings are non-persistent and uniquely bound to that specific tab session.

Privacy & Security Commitment

Because everything runs 100% locally within your browser code package, urlNeXT does not track, collect, or transmit a single byte of your browsing data. There are absolutely no third-party analytic trackers, no external network requests, and zero remote code payloads.

Check out the updated code, give it a spin on your favorite multi-page forums or image galleries, and let me know your thoughts or feedback in the comments below!