Some days ago I wrote about Gnoke-Database — a self-hosted Firebase alternative that runs on any PHP host with SQLite. The response was more than I expected, so I wanted to follow up with what actually exists now, not just the idea.
What shipped
v3 is a street-beta. That means the core engine is frozen and deployed on a real server. Not a demo. Not a prototype. A working backend that a courier company is currently running on.
The file layout settled into something clean:
/api ← PHP + SQLite backend (frozen)
/scripts ← Frontend engine modules (frozen)
/app ← Your app lives here
/tools ← Configurator + setup helpers
Two files to edit per deployment. Everything else is frozen.
The thing I'm most proud of
The data layer genuinely works offline-first. You write a record — it lands in localStorage instantly. No waiting for a network response. When the connection returns, the sync engine pushes the queue silently. When a teammate saves something on their device, the pull leg brings it down and your UI re-renders. Nobody coordinated that. The engine did.
The developer contract is simple enough to write on a napkin:
GnokeStore.define('ledger', { scope: 'user' });
GnokeStore.onChange('ledger', render);
GnokeStore.save('ledger', { title: 'Rice', amount: 5000 });
That's it. Local write, automatic sync, reactive UI.
What I intentionally left out
No OAuth. No file uploads. No real-time WebSockets. No admin dashboard for business users.
Those aren't gaps — they're the point. Gnoke is not trying to be Supabase. It's trying to be the thing that works on a ₦5000/month shared host when your team is 50 people and you need data to sync reliably between field devices.
The auth is PIN-based. Staff register with a phone number or email, set a PIN, and the engine handles the rest. If someone loses their device or forgets their PIN, an admin generates a one-time recovery code. Simple. No SMS API required.
What's still in progress
-
gnoke-secure.jsandgnoke-restore.js— the built-in login UI helpers — are being simplified. The current version has some rough edges around how the client builds the device identity hash. I'm ironing that out. - The admin panel is intentionally minimal right now — staff list and OTP generator only. It's a developer tool, not a business dashboard.
- Documentation is thin. The README is honest about this: the code is the truth for now.
To the person who asked about WordPress
You can run Gnoke-Database on the same server as WordPress. They share the same PHP host, same file system. Your WordPress site and your Gnoke-powered app are just two separate folders. No conflict. They plug into the same wall outlet — they don't have to merge.
The repo
Still early.. The README has the full context..
github.com/edmundsparrow/gnoke-database
If you're building something where Firebase feels like overkill — or where the bill is becoming a problem — give it a look.
MIT License. Your own Firebase, on your own server.
If I can think, I can breathe. If I can breathe, I can win.
Top comments (7)
Shipping v3 feels great. I'm working on a self-growing brand database (cache-miss AI enrichment with Claude) — v1 went live last week, and the messy data is teaching me a lot.
What was the biggest "wish I'd done this in v1" lesson?
I wish I made it GPLv3 😂
Haha, license regret is real! What pulled you back from GPLv3 originally?
Mass adoption.
"Mass adoption" — that's the GPL paradox in two words. Now I'm rethinking the license for my own pattern. What did you land on instead?
MIT — I chose permissive licensing for easier adoption. 😊