DEV Community: Andrea Debernardi

Database drivers as external processes

Andrea Debernardi — Wed, 24 Jun 2026 09:00:00 +0000

About three months ago I added external database drivers to Tabularis. Not dynamic libraries, not WebAssembly modules: ordinary processes that speak JSON-RPC over stdin/stdout.

Enough time has passed for the design to be less theoretical. It has survived real drivers, timeouts, a headless server mode, and one security bug that was hiding in what looked like normal registry code. So this is not a launch post. It is a short retrospective on the shape of the implementation and the places where the shape mattered.

Tabularis still has three database drivers compiled into the application: MySQL, PostgreSQL and SQLite. They use sqlx, implement the same Rust trait, and ship with the binary. This is the comfortable case.

The interesting case is the fourth database.

There are many databases I will never run myself, and a few I have not heard of yet. Compiling a client library for each of them into the core binary is not realistic. It also feels wrong: a database GUI should not have every possible vendor SDK, Python runtime, OAuth stack, TLS oddity and transitive dependency in the same address space as the rest of the application.

Still, "it does not support the database I use at work" is a valid reason to close a database GUI and never open it again. So Tabularis needed plugins.

That sounds like a solved problem until you ask what a plugin is, exactly, for a Rust desktop application. In practice I saw three choices: load a dynamic library, run WebAssembly, or start another process. The implementation that shipped chose the least clever one.

The two options I didn't take

Dynamic libraries. Load a .so, .dylib or .dll, find a symbol, call into it. This is the traditional native plugin model, and on paper it is the fastest one. A query method becomes a function call.

There are two problems with it here.

The first one is Rust. Rust does not have a stable ABI, so a plugin compiled with one toolchain cannot safely pass a String, Vec or trait object to a host compiled with another one. In practice a Rust plugin ABI becomes an extern "C" interface: raw pointers, owned buffers, explicit frees, error codes, and a driver author thinking about FFI before thinking about the database.

The second problem is more important. A dynamic library lives in the host process. If the driver segfaults, Tabularis segfaults. If it corrupts memory, the crash can surface later in unrelated code. If a panic crosses an FFI boundary incorrectly, the behavior is not something I want in user crash reports. The fastest plugin boundary is also the boundary with the worst failure mode.

WebAssembly. WASM is attractive for the opposite reason. It gives a real memory sandbox, and if the main problem was running hostile code, it would be the first thing to evaluate seriously.

But a database driver is mostly I/O. It opens sockets, negotiates TLS, speaks a binary protocol, and often wants to reuse a vendor SDK or a mature client library that already exists in some language. For this use case WASM does not just sandbox the driver; it removes a lot of the ecosystem the driver author would naturally want to use.

I am not saying WASM is a bad plugin technology. It is probably the right answer for many plugin systems. But for database drivers, the practical constraint is not CPU isolation. The practical constraint is: can somebody write a driver quickly, using the tools that already speak to that database? If the answer is no, the plugin system will be beautiful and mostly empty.

The boring option

A Tabularis plugin driver is a separate program. It reads requests on stdin, writes responses on stdout, and exits when the host is done with it.

This idea is old enough to be boring. Language servers work like this. Unix tools work like this. CGI worked like this. The reason this shape keeps coming back is that it gives a useful amount of isolation without inventing much:

The driver can be written in any language. Rust, Python, Go, Java, a shell script if that is really what the database deserves. If it can read a line and print a line, it can be a driver.
If the driver crashes, the host sees EOF on a pipe. That is a normal error path, not memory corruption in the GUI process.
The driver brings its own dependencies. The CSV driver is Python. The Google Sheets driver is Rust with an OAuth dependency I do not want in the core application. Both are fine because neither one is linked into Tabularis.

The cost is serialization. Every call is encoded, written through a pipe, read on the other side, decoded, and then the response takes the same trip back.

For a database client, this is a good trade. The thing behind the driver is usually a database server over the network, or at least disk. A bit of JSON framing is not where the time goes. When it does matter, the answer is usually to page or stream the result set, not to put a third-party driver into the main process.

The wire

The protocol is JSON-RPC 2.0, one message per line. The whole definition lives in src-tauri/src/plugins/rpc.rs, and it is small enough to show:

#[derive(Serialize, Deserialize, Debug)]
pub struct JsonRpcRequest {
    pub jsonrpc: String,
    pub method: String,
    pub params: Value,
    pub id: u64,
}

#[derive(Serialize, Deserialize, Debug)]
#[serde(untagged)]
pub enum JsonRpcResponse {
    Success { jsonrpc: String, result: Value, id: u64 },
    Error { jsonrpc: String, error: JsonRpcError, id: u64 },
}

Line-delimited JSON is intentionally unsophisticated. I could have used Content-Length framing like LSP does. Instead a Python driver can do this:

for line in sys.stdin:
    request = json.loads(line)

and be done with framing. A JSON serializer escapes newlines inside strings, so a physical newline is a message boundary. This is not the most general protocol in the world. It is the one that makes the first driver take an afternoon instead of a week.

One detail that paid for itself: the child's stderr is inherited, not piped. Driver logs and panics go to the same console as the app logs. I did not build a logging protocol because the operating system already had a useful one.

The method surface is the database trait flattened into strings: test_connection, get_databases, get_tables, execute_query, insert_record, get_create_index_sql, and so on. There are a bit more than thirty methods. The scaffolder generates stubs for all of them, so a driver author fills in behavior rather than copying protocol boilerplate.

At the boundary, params and result are serde_json::Value. Immediately above the boundary they become real types again. This is important: dynamic data at the process boundary is fine; dynamic data spread through the application would not be.

The part that is actually hard

The phrase "JSON-RPC over stdin/stdout" hides the annoying part: there are two byte streams and many callers.

When a connection opens, the sidebar may ask for schema information while the grid asks for the first page of rows and a background task pings the driver to see if the connection is still alive. Those calls are concurrent. The child process, however, has one stdin and one stdout.

So two things must be true:

Writes must be serialized. Even if small pipe writes often appear atomic, relying on that would make the protocol depend on an implementation detail.
Responses must be routed by id. The fast schema request can finish after the slow row request or before it. Order is not a contract.

The way to get both properties is to stop letting callers touch the pipes. One Tokio task owns the child process. Everyone else sends that task a command and waits on a one-shot channel.

The caller side looks like this:

enum PluginCommand {
    /// Dispatch a request; route the response back via the sender.
    Call(JsonRpcRequest, oneshot::Sender<Result<Value, String>>),
    /// Drop the pending entry for `id` because the caller stopped waiting.
    Cancel(u64),
}

The owner holds the only stdin, the only stdout, and the map of outstanding requests. It waits for three things: a shutdown signal, the next command from the application, or the next line from the plugin.

let mut pending: HashMap<u64, oneshot::Sender<Result<Value, String>>> = HashMap::new();

loop {
    tokio::select! {
        _ = &mut shutdown_rx => { let _ = child.kill().await; break; }

        msg = rx.recv() => match msg {
            Some(PluginCommand::Call(req, resp_tx)) => {
                pending.insert(req.id, resp_tx); // remember who's waiting
                let mut line = serde_json::to_string(&req).unwrap();
                line.push('\n');
                stdin.write_all(line.as_bytes()).await?; // serialized: only this task writes
            }
            Some(PluginCommand::Cancel(id)) => { pending.remove(&id); }
            None => { let _ = child.kill().await; break; } // all callers gone
        },

        line = reader.read_line(&mut buf) => match line {
            Ok(0) => break, // EOF: the plugin died
            Ok(_) => {
                match serde_json::from_str::<JsonRpcResponse>(&buf) {
                    Ok(JsonRpcResponse::Success { result, id, .. }) => {
                        if let Some(tx) = pending.remove(&id) { let _ = tx.send(Ok(result)); }
                    }
                    Ok(JsonRpcResponse::Error { error, id, .. }) => {
                        if let Some(tx) = pending.remove(&id) { let _ = tx.send(Err(error.message)); }
                    }
                    Err(e) => log::error!("bad response from plugin: {e}"),
                }
                buf.clear();
            }
            Err(e) => { log::error!("read error: {e}"); break; }
        },
    }
}

This is the PluginProcess management task in src-tauri/src/plugins/driver.rs. The request id is a monotonic counter. Responses can arrive in any order, because each one finds its waiting caller through pending. Writes are serialized because there is exactly one writer.

The external shape is concurrent. The internal shape is a single owner of a resource that should not be shared. That is the main trick.

A call becomes:

let (tx, rx) = oneshot::channel();
self.sender.send(PluginCommand::Call(req, tx)).await?;
match tokio::time::timeout(PLUGIN_CALL_TIMEOUT, rx).await {
    Ok(Ok(result)) => result,
    Ok(Err(_)) => Err("plugin did not respond".into()),
    Err(_) => { /* timed out */ }
}

At this point the design looks clean. In my experience, that is a good time to look for the state the code forgot to model.

Two bugs that showed up

The actor loop was the right abstraction, but two bugs fell directly out of its shape during the first rounds of testing.

The leak. A caller waits at most 120 seconds for a reply. If the plugin is slow or wedged, the caller gives up and returns an error.

But the owner still has an entry in pending. It contains a oneshot::Sender whose receiver is gone. The entry is removed only when a response arrives, and in this case the response may never arrive. So every timeout leaks one map slot. A bad plugin can slowly grow that map for the lifetime of the application.

That is what Cancel(id) is for. When a call times out, the caller also tells the owner to forget the request:

Err(_) => {
    let _ = self.sender.send(PluginCommand::Cancel(id)).await;
    Err(format!("plugin call '{method}' timed out after {}s", timeout.as_secs()))
}

This is a small fix, but it is the kind of small fix that is easy to miss because the happy path never needs it. The actor owns the child process, so it must also own the cleanup for abandoned calls.

The zombies. Tabularis can also run headless as an MCP server. In that mode a subprocess starts, registers plugins, serves requests, and exits when its stdin reaches EOF.

The first time I tested that path, ps still showed plugin processes after the parent had gone away. The owner task was the only place that called child.kill(), but Tokio tasks are cancelled when the runtime is torn down. The task that was supposed to clean up the child could be dropped before it reached the shutdown branch.

The fix is one line at spawn time:

.kill_on_drop(true)

Dropping the child handle is enough to terminate the process. This is a better invariant than "the async task will always get a chance to run one more branch before the runtime disappears", because that invariant is not true.

The registry bug

This is the bug that changed how I think about the registry.

Registering a driver, built-in or plugin, eventually meant inserting it into a map keyed by driver id:

registry.insert(manifest.id, driver);

The built-in drivers have the ids "mysql", "postgres" and "sqlite". A plugin declares its id in manifest.json.

Nothing stopped a plugin from declaring this:

{ "id": "mysql" }

Install that plugin and the map insert shadows the built-in MySQL driver. From that point, an existing MySQL connection can be routed to the third-party process that claimed to be MySQL. Tabularis resolves the password from the OS keychain and hands it to "the MySQL driver". The attacker does not need a memory corruption bug. The attack is a manifest entry.

I caught this during the original implementation, before it shipped, but it was close enough to be uncomfortable. The fix in src-tauri/src/plugins/manager.rs is deliberately boring:

const BUILTIN_DRIVER_IDS: [&str; 3] = ["mysql", "postgres", "sqlite"];
if BUILTIN_DRIVER_IDS.contains(&config.id.as_str()) {
    return Err(format!(
        "Plugin id '{}' collides with a built-in driver and was refused",
        config.id
    ));
}

A plugin that claims a built-in id is refused at load time.

The lesson is not that this particular denylist is clever. It is that an identity namespace shared by trusted and untrusted code is a security boundary. The HashMap looked like plumbing. In practice it was deciding which process received credentials from the keychain.

That is a useful class of bug to remember: the dangerous code is not always the code that parses packets or runs SQL. Sometimes it is the code that chooses who gets to run.

About the word "sandboxed"

It is tempting to call this sandboxing. I have used that word myself, but it needs qualification.

Running a driver as a separate process gives Tabularis two things:

Fault isolation. A crash becomes EOF on a pipe, not a corrupted heap in the GUI.
Dependency isolation. A plugin can bring its own runtime and packages without linking them into the application.

It does not make an untrusted plugin safe. The plugin process runs as the user. It can read files the user can read, open network connections the user can open, and do the normal things any program on the machine can do. A pipe is not a jail.

Real containment against hostile code needs operating-system mechanisms: seccomp, pledge/unveil, the macOS sandbox, Windows job objects and AppContainer-style boundaries, or something equivalent. Tabularis does not have that layer yet.

So the honest trust model is the same one you already use for packages, editor extensions and database client plugins: you are trusting the plugin author. The credential-shadowing fix above solves a narrower problem. It prevents Tabularis from automatically handing credentials to a plugin just because it chose a privileged name. That is worth doing even before a stronger sandbox exists.

Installing a plugin

The registry is a JSON file in the repo on GitHub, fetched by src-tauri/src/plugins/registry.rs. Installing a plugin, in src-tauri/src/plugins/installer.rs, fetches a ZIP over HTTPS, unpacks it into a temporary directory, checks that manifest.json exists and parses, and then atomically renames the directory into place:

fs::rename(&tmp_dir, &final_dir) // .tmp-<id> -> <id>, atomically
    .map_err(|e| format!("Failed to finalize plugin installation: {e}"))?;

The atomic rename matters because the loader should never see half of a plugin. Either the install finished and the directory has a valid manifest, or there is no plugin.

Three months later, this is still the weakest part of the install story: no signatures, no checksum pinning. The trust chain is "you trust the registry review, and you trust GitHub over HTTPS to deliver the ZIP". Signing is on the roadmap. Until then, it is better to describe the chain as it is than to imply more security than exists.

What held up

The part that held up is the original reason for doing this: I do not need to know about your database for Tabularis to speak to it.

Because a driver is just a process that reads a line and writes a line, the CSV driver can be Python, the Google Sheets driver can be Rust with OAuth dependencies, and a future driver can use whatever client library its database community already trusts. The Tabularis core does not need that code in its build, in its address space, or in its release cycle.

This is not a sophisticated plugin architecture. That is the point. The sophistication is in the edges: one owner for the pipes, request ids for out-of-order responses, cancellation for abandoned calls, process cleanup that survives runtime teardown, and an explicit boundary between trusted built-in ids and plugin ids.

The code is in the Tabularis repo, mostly under src-tauri/src/plugins/. If you want to read a real driver instead of the trait in the abstract, the Google Sheets plugin is the one I would start with.

The database has to be a defensive boundary again

Andrea Debernardi — Wed, 13 May 2026 08:46:09 +0000

For two decades the database has been able to outsource trust to the application layer. The app authenticated users, sanitized inputs, enforced business rules, and the DB just executed whatever came through the connection pool. That worked because the caller was almost always software written by someone, reviewed by someone, and shipped on a release train.

Agents don't fit that picture.

Once an LLM with tool access holds a live connection to your production database, the assumptions behind the application-as-perimeter model stop being true:

Connections aren't short-lived anymore. A tool-using agent can keep a session open across a long reasoning loop, with the SQL emerging one token at a time.
The caller isn't deterministic. Two runs of the same prompt can produce different queries. Sometimes very different ones.
Writes aren't intentional in the way a human commit is. An agent will issue an UPDATE without a WHERE clause if its plan says so.
Failures don't surface loudly. An exception that would have woken up a developer can be absorbed by the model and rationalized into the next step.

Short version: the application layer used to be the boundary. With agents in the loop, it isn't. The database has to defend itself again.

That's most of the reason the MCP safety work in Tabularis looks the way it does. The MCP server is the actual surface where an agent and a real database meet, and that surface needs guarantees the model can't talk its way around.

A few of the pieces we shipped:

Read-only connections. Not "the agent promises not to write" — the connection itself rejects writes. If the agent's plan calls for an UPDATE on a read-only connection, it fails at the boundary, before the row is gone. The classifier strips strings, comments and quoted identifiers before scanning the keyword, and treats anything ambiguous as a write. Fail-closed is the safer default when the alternative is a corrupted production table.

Approval gates with pre-flight EXPLAIN. Before a write (or a heavy read) actually runs, we surface the statement together with the planner's view of it for human approval. EXPLAIN turns out to be the right unit here: it shows the model's intent translated into what the database will really do, and that's often where the divergence between "what the agent said" and "what would have happened" shows up. You can fix the WHERE clause inside the modal, then approve. Both the original and the edited query are kept, linked by the same approval id.

Query audit logs. Every statement an agent issues is stored locally — one line of JSON per call — with its prompt context, the connection it used, the rows it touched, and the outcome. When something goes wrong (and with agents, something goes wrong) the audit log is how you reconstruct what actually happened, not what the model claims it did.

Full MCP activity tracing. Tool calls, results, errors, timing: the whole exchange between the agent and Tabularis is observable. Events can be flat-filtered or auto-grouped into sessions by inactivity gaps, and any session can be exported as a SQL notebook you can replay, diff against another run, or attach to a PR. When a model starts improvising, you can usually pinpoint the exact tool call where it happened.

None of these ideas are new. DBAs have wanted half of them for years. We could get away without them because the application layer was a decent proxy for "someone reasoned about this before it ran."

That proxy is gone. Putting the guarantees back inside the database itself is cheap compared to finding out, after the fact, that an agent dropped a column at 3am because its context window was full of stale documentation.

"Trust the application layer" was a fine default. With agents in the loop, it stops being one.

I Built an Open Source GitHub Dashboard Because My Repositories Were Becoming Unmanageable

Andrea Debernardi — Mon, 04 May 2026 13:19:08 +0000

A few weeks ago I started building something called gh-dashboard, a local-first dashboard for developers juggling too many GitHub repos at once.

What began as a tiny weekend tool to reduce tab overload quietly turned into something I now open every single morning. This post is about why I built it, the workflow problem behind it, and why I think a lot more developers are dealing with the same thing than we admit.

We're all learning how to ship more side projects. If you're "in the bubble" it can feel like everyone is repo-maxxing. Shipping weekly. Spinning up agents to scaffold full apps overnight. New OSS dropped every Friday. The reality I see with most developers is much more normal:

They have six or seven repos sitting in various states of half-attention.

A side project from last year that still gets an issue every couple of months. A library someone mentioned in a thread once. A fork they meant to upstream. The repo they pinned on their profile that hasn't seen a commit since November. Most people I know don't have a "repo factory" problem. They have an I have no idea what's going on across my own GitHub anymore problem.

I've roasted plenty of developers for letting their projects rot. This year I realized I had been doing the same thing, just with more discipline pretending otherwise. Six GitHub tabs open on a Sunday morning, clicking between them, trying to figure out what actually needed me that week.

My maintenance routine suddenly felt... less of a routine.

The Web Version Of Copy/Paste

The data was always there. The interface just made me click for it.

Anything new since yesterday? Which repo is going stale? Whose PR have I been ignoring? Is anyone actually using the latest release? Each one lived behind a different tab, a different filter, a different page. Cheap individually, expensive in aggregate.

I use a normal-ish setup. VS Code, the gh CLI, a couple of PATs, a folder with too many cloned repos. Nothing fancy. And every morning I'd ferry context between tabs the same way junior devs ferry errors between VS Code and ChatGPT — manually, slowly, badly.

The obvious fix is: use GitHub Projects. The less obvious problem is: Projects is built for working inside a repo, not across all of them at once. It shows you what a single project thinks you should care about, not what you actually need to triage across your whole footprint.

I didn't want more from GitHub. I wanted less of it, arranged differently.

A Weekend Hack I Kept Opening

The first version was rough. A single React page hitting the API directly, no caching, no backend, the token sitting in localStorage where it absolutely shouldn't have been. Built on a weekend.

But I kept opening it every morning. That is the only signal that ever matters with an internal tool — whether you reach for it without being reminded.

So I rewrote it properly, then posted about the idea on Reddit, mostly to check if I was alone with this.

I was not. The replies were almost all variations of yes, this, exactly. Maintainers of small libraries. Indie devs with a graveyard of side projects. Tiny teams who didn't want a full Projects setup but needed an overview. People quietly assuming this was a personal failing.

That thread is the reason this is open source instead of a script in ~/dev/tools/.

Local Means Local

The naive version of my project was easy: spin it up as a SaaS, ask people for a GitHub token, host it somewhere, slap a Pro tier on it. And call it a day.

Except... tokens and security are a thing. I already play it too fast and loose with my own credentials. I'm trying to be better about that. I've also been on the other side of that ask too many times to put someone else through it. I needed local-first visibility, not "give a stranger read access to every repo you touch."

That became the design constraint for gh-dashboard: it runs on your machine, the OAuth app belongs to you, and the token never reaches the browser.

GitHub As The Data, Your Machine As The Trust Surface

The project is a small Node backend plus a React frontend.

The backend is the GitHub-facing part. It handles OAuth Device Flow, talks to REST and GraphQL, caches responses, and exposes JSON to the frontend.

The frontend is the human-facing part. Repository overview ranked by triage value, cross-repo issues and PRs in one list, a Kanban board for triage sessions, per-repo deep dives, and a daily digest of what changed — with optional AI-generated narrative if you plug in an OpenAI key.

I did not want consent hidden inside a hosted dashboard somewhere. I wanted separate surfaces. GitHub is the data layer. Your machine is where the token lives and where you actually look.

That feels like the right boundary.

The v1 surface is intentionally boring. List repos, list issues, list PRs, summarize what changed, flag stale stuff. That is enough to stop me from clicking through six tabs every morning.

Not GitHub Itself

I'm not naive to the fact that this overlaps with things GitHub already does. Notifications exist. Projects exist. The mobile app exists.

I am not trying to replace any of them. I am trying to make my normal triage routine less sloppy.

The goal is for the easy path to be the focused path: one place, no push notifications, attention-first, quiet when there is nothing actually demanding me. That already feels better than tab-juggling chaos.

More To Do

I still have plenty to do on this project. It's a rough first pass. Smarter health scoring. Daily digests that adapt to what you actually read. Saved filters. Lightweight team workflows that don't bloat into a project tracker. Smoother first-run.

But the direction feels right and I think it solves a real problem that I imagine other folks have.

I'm gonna keep using it and iterating on it for my workflow. Feel free to check it out!

https://github.com/debba/gh-dashboard

I built a Claude Code skill that turns negative competitor reviews into a roadmap

Andrea Debernardi — Sun, 26 Apr 2026 08:37:49 +0000

Picking what to build next is the part of running a side project I'm worst at. Open the issue tracker, stare at it, close the issue tracker. Repeat next weekend.

A few weeks ago I tried something different: instead of asking myself, I asked the people who already left a competitor. There's a specific kind of useful buried in a 1-star G2 review — someone took the time to write down what they wanted and didn't get. That's a roadmap. The problem is reading hundreds of them.

So I built GapHunter, a Claude Code skill that does it for me.

You run it like this:

/gaphunter DBeaver TablePlus

It searches G2, Capterra, TrustRadius, Reddit, GitHub Issues and Hacker News in parallel, clusters near-duplicate complaints (so "no dark mode" and "lacks dark theme" collapse into one finding), then reads your own repo : package.json, Cargo.toml, the src/ tree — and cross-references the gaps against what you've already shipped.

The output is two paired files in docs/: a JSON sidecar and a self-contained HTML report you just double-click. Tabs for Summary, Quick Wins (high priority × small effort, the obvious place to start), a Comparison matrix if you ran it against multiple competitors, and a Plan tab that lists implementation steps and the files in your repo to touch for each finding.

It's not perfect. Sources occasionally 403, the semantic clustering still groups things it shouldn't sometimes, and it can't see private repos of the competitors (oviously). But the first time I ran it I had a one-page list of things people are actively complaining about not having in tools I compete with — annotated with which ones I'd already implemented. A couple of hours of manual research, one command.

The skill itself, the HTML viewer, the CSS: all of it was written inside Claude Code. MIT licensed if you want to fork it or steal the template.

Repo: https://github.com/debba/gaphunter-skill

Databases Are Not Becoming Chatbots

Andrea Debernardi — Fri, 17 Apr 2026 11:30:38 +0000

Over the last two months, while building a database tool and adding AI features to it, I started realizing that I was not just shipping product work. I was bumping into a larger question: what happens to databases when software no longer just reads and writes records, but also interprets schema, suggests queries, explains plans, preserves context, and collaborates with language models?

My current view is simple: databases are not becoming chatbots.

The real change is happening in the layer around the database.

Databases still matter because structured truth still matters. LLMs do not replace the need for schemas, constraints, transactions, and systems of record. If anything, they make those things more valuable.

What AI changes is interpretation, navigation, and action around the database.

That became very concrete to me while building Tabularis, especially once AI, notebooks, visual explainability, MCP, and plugins started living in the same workflow.

Here are the main bets I find myself making:

AI should not become the source of truth
AI should stay optional
preserved context matters more than one-shot generation
the future is probably composable

And here are the mistakes I think I may be making:

using AI where better UX would be enough
overestimating generation and underestimating control
underestimating auditability and reproducibility
designing too much for the future

I wrote the full version here, with more detail on the technical decisions and the mistakes behind them:

Read the full article on tabularis.dev

From 0 to 1,000 GitHub Stars in 10 Weeks: What Actually Worked

Andrea Debernardi — Tue, 14 Apr 2026 07:24:09 +0000

Ten weeks ago I pushed the first binary of Tabularis to GitHub. A cross-platform database client built with Tauri (Rust + React/TypeScript). One person, a late-night frustration, and a SQL editor.

Last week the repo crossed 1,000 stars. Today there are 1,086 stars, 70 forks, 15 contributors, 41 releases, and a plugin ecosystem that didn't exist eight weeks ago.

No marketing budget. No growth hacks.

I wrote a detailed post about what actually worked, what didn't, and what I'd do differently. Here are the highlights.

Ship fast, ship broken

The first week produced fifteen releases. Some were embarrassing. I shipped anyway. Nobody remembers your v0.3.0. People remember whether the tool was useful when they tried it, and whether it got better when they came back.

Build an extension point early

The decision that changed the trajectory: shipping a plugin system (language-agnostic JSON-RPC protocol) at the one-month mark. Within two weeks the community had added Redis, ClickHouse, CSV, and a Hacker News plugin. It turned users into builders.

The AI factor

I need to be honest: Tabularis would not exist without AI-assisted development. Specifically, Claude Code.

41 releases in eleven weeks, one person. That math doesn't work without a force multiplier. But AI doesn't replace experience. It amplifies it. Claude Code didn't design the plugin architecture or decide that JSON-RPC was the right protocol. Those decisions came from years of building software.

What AI did was collapse the distance between a decision and its implementation. Once I knew what to build, I could build it in hours instead of days.

The numbers at week 11

The 1,000-star milestone landed at week ten. Here's where things stand today, one week later:

Metric	Week 4	Week 10	Week 11 (today)
Stars	~270	1,000	1,086
Contributors	5	14	15
Releases	17	39	41
Forks	—	65	70
Plugins	1	7	7
Languages	2	4	4
Issues	—	~70	81
Pull Requests	—	~35	41
Downloads	—	~6,000	7,100+

72 countries and counting

One thing that surprised me: where those stars come from. About half of our stargazers have a public location on their GitHub profile, and they span 72 countries across every continent.

The United States and China lead, but what stands out is the long tail: South Korea, Germany, France, Brazil, Indonesia, Vietnam. Tabularis isn't a tool for one market. It's a tool for developers, and developers are everywhere.

Read the full story

The full post covers every phase week by week, what didn't work, and advice for anyone starting an open source project today.

Read the full post on tabularis.dev

GitHub repo

Join the Discord

If you're building something in the open, I'd love to hear your story. Drop a comment or find me on X or Discord.

I am building a Notebook Environment for SQL Inside a Database Client

Andrea Debernardi — Fri, 03 Apr 2026 06:42:43 +0000

This post is also available on tabularis.dev.

You know the drill. Write a query, get a table. Need to build on that result? Copy-paste into the next query. Need a chart? Export CSV, open a spreadsheet. Want to document the analysis? Paste SQL into a doc and pray nothing drifts.

I got tired of this loop, so I'm building Notebooks into Tabularis — a cell-based SQL analysis environment that lives inside the database client. No Jupyter, no Python runtime, no context switching. Just SQL + markdown cells, inline charts, and a few features that make multi-query analysis way less painful.

It's still in development, but the core works. Here's what it looks like and how it's shaping up.

How It Works

A notebook is a sequence of cells — SQL or markdown. SQL cells run against your database and show results inline with the same data grid from the query editor (sorting, filtering, resizable panels). Markdown cells are for documentation between queries.

Cell References via CTEs

This is the part I'm most excited about.

Any SQL cell can reference another cell's query with {{cell_N}}. At execution time, it gets resolved as a CTE:

-- Cell 1: Base query
SELECT customer_id, SUM(amount) AS total
FROM orders
GROUP BY customer_id

-- Cell 3: References Cell 1
SELECT * FROM {{cell_1}} WHERE total > 1000

Becomes:

WITH cell_1 AS (
  SELECT customer_id, SUM(amount) AS total
  FROM orders
  GROUP BY customer_id
)
SELECT * FROM cell_1 WHERE total > 1000

No temp tables, no copy-paste. Change the base query, re-run downstream cells, everything stays in sync. You can chain across multiple cells and every intermediate result stays visible.

Inline Charts

Any result with 2+ columns and at least one row can be charted — bar, line, or pie — directly in the cell. Pick a label column and value columns, done. Config is saved with the cell.

Not meant to replace BI tools. It's for when you're exploring and want a quick visual check before writing the next query.

Parameters

Define once, use everywhere:

@start_date = '2024-01-01'
@end_date   = '2024-12-31'
@min_amount = 500

Every SQL cell with @start_date gets it substituted before execution. Change the value, re-run — all queries pick it up. Great for monthly reports, cohort comparisons, anything where the logic stays the same but inputs change.

Parallel Execution

Not every cell depends on the previous one. Mark independent cells with the lightning bolt icon and they run concurrently during "Run All" instead of waiting in sequence. For notebooks with heavy queries against different tables, this makes a real difference.

Run All + Stop on Error

Ctrl+Shift+Enter runs every SQL cell top to bottom. Stop on Error controls whether it halts at the first failure or keeps going. After execution, a summary card shows succeeded/failed/skipped counts — click a failed cell to jump straight to it.

Multi-Database in One Notebook

Each SQL cell can target a different database connection. Pull from production PostgreSQL in one cell, compare with your analytics SQLite in the next. Works across MySQL, MariaDB, PostgreSQL, and SQLite.

Execution History

Every cell keeps its last 10 runs — timestamp, duration, row count. You can restore any previous query version. Useful when you've been iterating and need to go back.

AI Assist

Each SQL cell has AI and Explain buttons — describe what you want, get SQL back, or break down an existing query. There's also an auto-naming feature: click the sparkles icon and AI generates a cell name based on the content. Named cells show up in a notebook outline for navigation.

Organization

Collapse cells to show just headers
Drag and drop to reorder
Cell names (manual or AI-generated) for identity
Markdown cells as section dividers

Import / Export

.tabularis-notebook — JSON with cells, parameters, charts. No result data. Share it, import it, connect to a different DB, run it.
HTML export — self-contained document with rendered markdown, syntax highlighting, embedded result tables. Dark-themed.
Individual results export as CSV or JSON.

What's Not Done Yet

Being honest about rough edges:

Large notebooks (30+ cells) need better virtualization
Circular reference detection is missing — needs a dependency graph
Chart customization is minimal (no axis labels, no color palettes)
Keyboard navigation between cells is partially implemented
Notebook-level undo/redo doesn't exist yet (cell-level works via Monaco)

Why Build This?

Database clients haven't really evolved beyond "connect, query, see table." Analysis tooling moved forward — Jupyter, Observable, dbt — but the DB client stayed behind.

Notebooks in Tabularis bet that the database client is the right place for exploratory SQL analysis. You already have the connection, the schema, autocomplete, query history. Cells, charts, references and parameters on top of that means the whole workflow — first query to shareable report — happens without switching tools.

It's not a Jupyter replacement. No Python, no R. It's purpose-built for SQL, and for the kind of work most people actually do with their database every day — ad-hoc exploration, report building, data validation, performance investigation — that focus is a feature.

Landing soon. If you want to try it, check out Tabularis.

One Month Building in Public — Here's What I Shipped

Andrea Debernardi — Thu, 26 Feb 2026 09:32:38 +0000

Tabularis was born on the night of January 25th, 2026. A solo project — one person, a frustration turned into code, a binary pushed to GitHub.

Today is exactly one month since that first release. And in one month, it stopped being a solo project.

I believe deeply in what this can become. Not just as a database tool, but as proof that a small team — or even a single person — can build something genuinely useful, genuinely open, and genuinely worth growing. That belief hasn't wavered for a single day. If anything, watching people show up and contribute has made it stronger.

A lot has happened.

The Numbers

~280 stars. 5 contributors. Around 1,000 downloads. Around twenty issues opened by people who actually tried the product, pull requests reviewed, bugs squashed.

For a one-month-old open source project, that's not nothing — that's a community. And communities don't happen by accident. They happen because people show up.

So: thank you. Genuinely.

What We Built

A month ago, Tabularis could connect to PostgreSQL, MySQL, and SQLite. It had a SQL editor, a data grid, and not much else.

Since then, we've shipped:

Plugin System — the biggest release of the month. A language-agnostic JSON-RPC protocol that lets anyone build a new database driver without touching the core app. The first plugin, tabularis-duckdb-plugin, was ready on day one. This is the feature that changes what Tabularis can become: not a tool that supports three databases, but a platform that can support any database.
AI Assistant — generate SQL from natural language, get explanations for complex queries. Integrated with OpenAI, Anthropic, OpenRouter, and Ollama for those who want to keep everything local.
Visual Query Builder — build JOINs and filters without writing a line of SQL.
SSH Tunneling — connect to remote databases through SSH with key and password auth.
Split View — work with two connections simultaneously, side by side.
Schema Management — ER diagrams, inline column editing, table creation wizards.
MCP Server — expose your database to Claude and other AI agents via the Model Context Protocol.
10+ Themes — because your tools should feel good to use.

One month. That's the velocity the community made possible.

The Wiki Is Open

Starting today, the Tabularis Wiki is live and open for contributions. Every page has an Edit on GitHub link.

This is intentional. Documentation written only by the maintainers reflects only the maintainers' perspective. If you've figured out a non-obvious workflow, found a gotcha during setup, or have a tip that saved you time — the wiki is the right place for it.

What's Next

The plugin ecosystem is still young. We want drivers for ClickHouse, CockroachDB, and more. We want the registry to grow. We want the community to build things we haven't thought of yet.

On the core side: better query history, smarter autocomplete, a more complete ER diagram, and performance improvements are all in flight.

Get Involved

GitHub: github.com/debba/tabularis
Discord: discord.gg/YrZPHAwMSG
brew install --cask tabularis
Snap: snap install tabularis
AUR: yay -S tabularis-bin

If Tabularis has been useful to you — tell someone. Open source lives and dies by word of mouth.

Here's to month two.

Building Tabularis: A Developer's Database Tool That Doesn't Suck

Andrea Debernardi — Mon, 09 Feb 2026 09:56:35 +0000

I've been managing databases for years, and I'm tired of the same two options: heavyweight enterprise tools that feel like flying a 747 to get groceries, or stripped-down CLI utilities that make even simple tasks a chore. There had to be a middle ground—something fast, clean, and actually enjoyable to use.

So I built Tabularis, starting from a vibe-coding session with Claude Code, and then it evolved as I really put my mind into it.

The Problem With Database Tools

Like everyone else, I spent years bouncing between phpMyAdmin, MySQL Workbench, DBeaver, and whatever else was popular that quarter. They all had the same issues:

Too heavy: Enterprise tools pack in features I'll never touch, eating RAM and taking forever to start
Poor UX: Clunky interfaces designed by committee, not for actual daily use
Vendor lock-in: Tools optimized for one database, awkward for others
Missing modern features: No AI assistance, no visual query building, no MCP integration

The real frustration came when I just wanted to quickly check production data or test a query—it shouldn't require launching a 500MB Electron app and waiting 30 seconds for it to connect.

What Makes Tabularis Different

Tabularis is what I actually wanted to use every day. It's built with Tauri (not Electron), so it's genuinely lightweight—the entire app is under 20MB. Starts in under a second. Feels native because it is native.

But being lightweight doesn't mean being limited. Here's what actually matters:

Connection Management That Makes Sense

SSH tunneling with automatic readiness detection. No more "is the tunnel up yet?" guessing games. Secure password storage in your system keychain, not some custom encrypted file. Clone connection profiles instead of manually recreating them.

The Database Explorer I Always Wanted

A proper tree view that shows everything—tables, views, stored procedures, functions, foreign keys, indexes. Not hidden in submenus or separate windows. Right-click context actions for common operations. Want to see the row count? It's one click, not three windows deep.

The ER diagram generator is particularly useful. It's not trying to be a full diagramming tool—it just shows your schema interactively. Pan, zoom, select specific tables. When you're debugging a complex query join, being able to visually trace the relationships saves real time.

Visual Query Builder (That Actually Works)

Most visual query builders are toys. They work for SELECT * FROM users and fall apart at the first JOIN. I needed something that could handle real queries—multiple joins, aggregates, WHERE clauses, HAVING filters.

The builder uses ReactFlow for drag-and-drop table connections. Create visual relationships between tables, and it generates proper JOIN syntax. Add filters, aggregates, sorting—all visually—and watch the SQL update in real-time. When you need to switch to the SQL editor, you're not starting from scratch.

AI Integration (Optional, But Useful)

This is where it gets interesting. I didn't want to force cloud AI on anyone—privacy matters—so Tabularis supports multiple AI providers:

OpenAI, Anthropic, OpenRouter for cloud options
Ollama for completely local inference
OpenAI-compatible APIs (Groq, Perplexity, LocalAI, etc.)

The AI features are straightforward: text-to-SQL generation and query explanation. Type "show me users who signed up last week" and get working SQL. Or paste a complex query and get a plain-English explanation of what it's doing.

But here's the part I'm most excited about: MCP Server support.

The MCP Server: Exposing Databases to AI Agents

Tabularis includes a built-in Model Context Protocol (MCP) server. Run tabularis --mcp and your database connections become available to any MCP-compatible AI agent—Claude Desktop, Cursor, or custom tools.

This means AI agents can query your databases directly. Not through screenshots or copy-paste, but actual programmatic access. I've been using it with Claude Desktop to analyze production data, generate reports, and debug queries—all without leaving my chat window.

The architecture is simple: Tabularis runs as an MCP server, exposes your saved connections through a standard protocol, and handles authentication and query execution. The AI agent just sees a set of available databases and can query them like any other data source.

It's surprisingly powerful. I recently had Claude help me optimize a slow query by letting it inspect the actual table structures, existing indexes, and query execution patterns—all through MCP. It generated three optimization strategies, I tested them, and cut query time by 60%. That workflow wasn't possible with traditional database tools.

Building It All

I started Tabularis about six months ago, mostly as a weekend project to scratch my own itch. The tech stack choices were deliberate:

Tauri v2 instead of Electron (smaller bundle, better performance, native feel)
React 19 with TypeScript (familiar, fast development)
Tailwind CSS v4 (rapid UI iteration without CSS bloat)
Rust backend with SQLx (type-safe queries, excellent performance)

The Rust backend handles all database operations through SQLx, which provides compile-time verification of SQL queries. No more runtime surprises about typos in column names. SSH tunneling is handled with native Rust libraries, not shelling out to external processes.

One interesting challenge was supporting multiple database types (MySQL, PostgreSQL, SQLite) with a unified interface. SQLx helps here with its database-agnostic query builder, but each database has quirks—MySQL's information_schema differs from PostgreSQL's pg_catalog, and SQLite is its own thing entirely.

The solution was a trait-based provider system in Rust. Each database implements a common DatabaseProvider trait that defines operations like "fetch tables," "execute query," "get foreign keys." The frontend doesn't care which database it's talking to—it just calls methods on the trait.

Using Tabularis

Getting started is intentionally simple:

macOS (Homebrew)

brew tap debba/tabularis
brew install --cask tabularis

Arch Linux

yay -S tabularis-bin

Everyone Else

Download from releases for Windows, Linux (AppImage), or macOS (DMG).

Connect to your database, start exploring. The interface is designed to be obvious—if you've used any database tool before, you'll figure it out in 30 seconds.

All configuration lives in ~/.config/tabularis/ (or your OS equivalent)—connections, saved queries, themes, settings. Plain JSON files, easy to back up or edit manually if needed.

What's Next

Tabularis is fully functional today, but there's more to build:

Better PostgreSQL & SQLite support: MySQL is solid, but Postgres and SQLite need more love
Query history: Track and revisit past queries across sessions
Performance monitoring: Built-in query profiling and execution plan visualization

The code is on GitHub, Apache 2.0 licensed. It's built by a developer, for developers. No telemetry, no accounts, no subscriptions. Just a tool that works.

If you're tired of database tools that feel like they're fighting you instead of helping you, give Tabularis a try. It's what I wish I had years ago.

Download: tabularis.dev | Source: github.com/debba/tabularis

Run tabularis --mcp to enable MCP server mode and start connecting your databases to AI agents.

I was tired of database tools — so I started building my own

Andrea Debernardi — Tue, 27 Jan 2026 12:04:22 +0000

Repo url: https://github.com/debba/debba.sql

At some point, I realized I was spending more energy fighting my database tools than actually working with databases.

Most of the popular DB managers are:

closed source
heavy as hell
UX-wise… questionable
clearly not built with Linux developers in mind

And yes, some of them look nice (👀 DataGrip), but they feel like bringing a tank to open a bottle of water.

So one night, instead of complaining on Twitter or Discord, I did the most dangerous thing a developer can do:

I started vibe coding my own DB manager.

It started as a hack (literally)

This wasn’t a “vision”, or a “startup idea”.

It was:

late at night
Rust open in my editor
Tauri + React on the side
a strong feeling of “how hard can it be?”

I just wanted:

something fast
something local
something that doesn’t feel like a bloated enterprise product
something I can actually understand end-to-end

No roadmap.

No design doc.

Just hacking.

From vibe coding to “wait, this might actually work”

After the first hacky prototype, something unexpected happened.

I kept adding things.

Slowly.

Incrementally.

Scratching my own itch.

What started as:

“Let me just connect to a DB”

became:

multi-database support (SQLite, Postgres, MySQL…)
a cleaner mental model
better performance than I expected
an app that feels mine

At that point I thought:

ok, either I stop now… or I open-source it and see what happens.

debba.sql (name pending 😅)

The project is currently called debba.sql — debba is my nickname and, conveniently, contains db.

Is the name final?

Probably not.

Is the project done?

Absolutely not.

Right now it’s:

🧩 a side project
🦀 written in Rust
🖥️ wrapped with Tauri
⚛️ frontend in React
🐧 built with Linux devs in mind
🌍 open source, repo public

No company.

No monetization (for now).

Just a tool I actually want to use.

This is not a manifesto (yet)

I’m not claiming this will “replace” anything.

I’m not claiming it’s better than your favorite tool.

I am saying:

dev tools should feel empowering
open source matters
UX is not optional
Linux users deserve first-class experiences

And sometimes, the best way to stop complaining…

is to build.

I want your feedback

This is the part where I shut up and listen.

If you:

have strong opinions about DB tools
build dev tools yourself
care about open source UX
are tired of bloated software

I’d love your feedback.

Issues, comments, brutal honesty — all welcome.

This started as vibe coding at night.

Let’s see where it goes.

🧪🔥

Repo url: https://github.com/debba/debba.sql

From VS Code to Zed: building a FreeMarker extension because I needed one

Andrea Debernardi — Thu, 15 Jan 2026 12:37:57 +0000

From VS Code to Zed: building a FreeMarker extension because I needed one

A few months ago, I switched from VS Code to Zed.

Not because VS Code is bad — it’s still an amazing editor — but because it slowly became… heavy.

My setup had turned into a Frankenstein monster of freemium extensions, background processes, upsells, and “just one more helper” that somehow made everything slower.

I wanted something:

fast
open-source
opinionated
boring in the best possible way

Zed checked all the boxes.

Until I had to start working with FreeMarker.

FreeMarker is still very much alive

If you work in Java or enterprise environments, you already know this.

FreeMarker isn’t trendy.

It’s not on Hacker News every week.

But it’s everywhere.

In my case, I’m using it in a project that integrates Keycloak, where FreeMarker templates are still a core part of the customization flow.

So yes — FreeMarker is old.

And yes — it’s still critical.

Which made this part a bit painful:

👉 Zed had no FreeMarker support.

No syntax highlighting.

No understanding of directives.

Nothing.

The “fine, I’ll do it myself” moment

Zed is fast enough that once you get used to it, going back feels… wrong.

So instead of switching editors again, I thought:

“How hard can it be to write a FreeMarker extension?”

(Last words before opening a tree-sitter grammar.)

I already knew that:

Zed uses tree-sitter
Syntax highlighting is grammar-driven
Extensions are lean and explicit

I also had a starting point:

a FreeMarker extension for VS Code.

The idea was simple:

reuse what I could
adapt what I had to
learn the Zed extension model along the way

With some help from vibe-coding and a lot of trial & error, I started porting it.

The actual journey (a.k.a. tree-sitter reality check)

Some things were easier than expected:

Zed’s extension model is refreshingly clean
Tree-sitter forces you to think properly about structure
No magic, no hidden layers

Some things were… not:

FreeMarker syntax is flexible in annoying ways
Directives, interpolations, nested expressions
Edge cases you only notice after breaking everything

Porting from VS Code wasn’t a copy–paste job.

It was more like translating between two different mental models.

But honestly?

That’s what made it fun.

The result: early, but usable

The extension is live here:

👉 https://github.com/debba/zed-freemarker

What it supports today:

FreeMarker syntax highlighting
Directives
Interpolations
A solid base for further improvements

Is it perfect? No.

Is it production-grade? Not yet.

Is it good enough to work daily without hating your editor? Absolutely.

And for an editor like Zed, that already feels like a win.

Thoughts on Zed and niche tooling

Zed feels like an editor for people who:

enjoy understanding how their tools work
prefer fewer abstractions
don’t mind building missing pieces themselves

Writing this extension reminded me of something important:

Open source doesn’t move forward only with big features —

it also grows through small, boring, niche tools that solve real problems.

FreeMarker isn’t cool.

But someone still has to maintain it.

What’s next?

Possible next steps:

better grammar coverage
error handling
maybe an LSP in the future (no promises)

If you:

use FreeMarker
use Zed
enjoy hacking on developer tools

Feedback, issues, and PRs are more than welcome.

Sometimes the best extensions start with a simple need:

“I just want my editor to understand this file.”

And that’s exactly how this one was born 🚀

Building AuthPress: From Simple Telegram 2FA to Extensible WordPress Security Platform

Andrea Debernardi — Tue, 16 Sep 2025 12:50:53 +0000

How I evolved a single-provider WordPress 2FA plugin into a comprehensive, developer-friendly authentication system

The Problem 🔐

WordPress powers 43% of the web, but most sites still rely on password-only authentication. While there are 2FA plugins available, they're often:

Limited to specific providers
Hard to extend or customize
Not developer-friendly
Missing modern authentication methods

The Journey 🚀

AuthPress started as a simple idea: "What if I could get my WordPress 2FA codes via Telegram?" Three years and multiple iterations later, it's become a comprehensive authentication platform.

Version 4.0: The Extensible Platform

Now it supports multiple providers through a clean architecture:

// Modern extensible system
abstract class Abstract_Provider {
    abstract public function send_code($user_id, $code);
    abstract public function verify_code($user_id, $code);
    abstract public function render_user_settings($user_id);
}

// Register custom providers
add_filter('authpress_register_providers', function($providers) {
    $providers['my_sms'] = 'MyPlugin\\SMS_Provider';
    $providers['push_notification'] = 'MyPlugin\\Push_Provider';
    return $providers;
});

Technical Architecture 🏗️

Core Features

Multi-Provider Support: Telegram, Email, TOTP, Recovery Codes
Extensible API: Clean interfaces for custom providers
Professional Logging: WordPress-native admin tables
Security First: Rate limiting, encrypted storage, brute force protection

The Provider System

Each authentication method is a provider class:

class Telegram_Provider extends Abstract_Provider {
    public function send_code($user_id, $code) {
        // Telegram API integration
        return $this->send_telegram_message($user_id, $code);
    }

    public function verify_code($user_id, $submitted_code) {
        // Validate against stored code
        return $this->validate_stored_code($user_id, $submitted_code);
    }

    public function render_user_settings($user_id) {
        // User configuration interface
        include 'templates/telegram-settings.php';
    }
}

Developer Experience 👨‍💻

Creating Custom Providers

Want SMS via Twilio? Here's how simple it is:

class Twilio_SMS_Provider extends Abstract_Provider {
    private $twilio_client;

    public function __construct() {
        $this->twilio_client = new Twilio\Rest\Client($sid, $token);
    }

    public function send_code($user_id, $code) {
        $phone = get_user_meta($user_id, 'phone_number', true);

        return $this->twilio_client->messages->create($phone, [
            'from' => '+1234567890',
            'body' => "Your WordPress login code: {$code}"
        ]);
    }

    public function verify_code($user_id, $code) {
        return parent::verify_stored_code($user_id, $code);
    }
}

WordPress Integration

Follows WordPress best practices:

Uses hooks and filters extensively
Proper nonce verification
WP_List_Table for admin interfaces
Standard WordPress coding standards

What's Next? 🔮

Working on:

Passkey/WebAuthn integration (already in beta)
Hardware token support (YubiKey, etc.)

Open Source & Community 💝

AuthPress is GPL-licensed and available on:

WordPress.org: Official plugin directory
GitHub: dueclic/authpress

Contributing

We welcome contributions! Especially:

New provider implementations
Security audits
Documentation improvements
Translation updates

Lessons Learned 📚

Start simple, architect for growth - The extensible design saved massive refactoring
Security can't be an afterthought - Built-in from day one
Developer experience matters - Clean APIs lead to better ecosystem
WordPress standards exist for a reason - Following them made everything easier

Try AuthPress on your WordPress site and let me know what custom providers you'd build! The extensibility system makes it possible to integrate with virtually any authentication service.

What 2FA method would you want to see next? Drop your ideas in the comments! 👇

WordPress #2FA #Security #PHP #OpenSource