DEV Community: Mirko Stahnke

Bring Your Own Key: Building an AI Portal That Never Touches the Billing

Mirko Stahnke — Sun, 23 Aug 2026 18:47:18 +0000

Bring-your-own-key, not another subscription

Every few months another "all AI models in one place" product shows up, and almost all of them work the same way: you pay them a subscription, and they resell access to Claude, GPT-4, Gemini and friends at a markup. That's a reasonable business, but it's not the only way to build this, and it's not the way ai.findnix.eu works.

AI Hub is a bring-your-own-key portal: you paste in your own Anthropic, OpenAI, Google, Mistral, Stability AI, ElevenLabs and Runway keys, and the portal just gives you one consistent interface — chat, image generation, text-to-speech, a code assistant, video generation — over whichever of those you've connected. Billing happens directly between you and the provider. The portal itself charges nothing for API usage, because it never touches the money side at all.

Keys are the one thing that has to be paranoid

The whole trust model of a BYOK product rests on one thing: can users believe their API keys — which are effectively bearer tokens for their own paid accounts — are safe. Every key is encrypted with AES-256-GCM before it touches the database, with a unique nonce per key (so two identical keys never produce identical ciphertext, which matters for preventing pattern analysis against the stored blobs). The master key lives in a config file that's explicitly blocked from direct HTTP access at the nginx level, as a second layer independent of PHP actually executing the file correctly.

function encryptApiKey(string $plaintext): array {
    $key   = hex2bin(MASTER_KEY);
    $nonce = random_bytes(12);
    $tag   = '';
    $cipher = openssl_encrypt($plaintext, 'aes-256-gcm', $key, OPENSSL_RAW_DATA, $nonce, $tag, '', 16);
    return ['enc' => base64_encode($cipher . $tag), 'nonce' => base64_encode($nonce)];
}

Nothing exotic — GCM gives you authenticated encryption for free, so a tampered ciphertext fails to decrypt rather than silently returning garbage.

Two identities, one login, no forced choice

AI Hub is a sibling project to findnix.eu, a GDPR-focused EU search engine, and that created an actual product question: should AI Hub have its own user accounts, or piggyback on findnix.eu's existing ones?

The answer ended up being both, deliberately. At signup you choose: a standalone AI Hub account, or one linked to your findnix.eu account with a shared login. Existing findnix.eu users don't have to fill out a second registration form at all — a link in their findnix.eu account silently provisions a linked AI Hub identity and drops them straight into the dashboard, authenticated.

That "silently provisions" step runs over a short-lived, single-use signed token rather than any shared session or cookie trickery between the two domains:

function consumeSsoToken(string $token): ?int {
    $row = /* look up token, reject if used or older than 60s */;
    mark token used;
    $aiUserId = /* look up existing linked account for this findnix user */;
    if ($aiUserId) return $aiUserId;
    // first time: silently create a linked AI Hub account, no form involved
    return createLinkedAccount($row['fnx_user_id']);
}

For linked accounts, password checks go straight to findnix.eu's own password hash rather than a duplicated one — one password, one source of truth, even though the two products keep separate account tables.

Least privilege, even between your own apps

Because AI Hub and findnix.eu now share a physical database (AI Hub's tables live in the same schema with their own prefix, rather than a separate database), it would have been easy to just reuse findnix.eu's own full-access database credentials for AI Hub too. Instead AI Hub gets its own MySQL user, scoped to SELECT, INSERT on the shared users table (enough to look up and create linked accounts) and full access only to its own tables. It's internal plumbing nobody using the product will ever see, but it means a bug in a comparatively young, less-battle-tested part of the stack can't reach past its own tables into the main product's data.

What's next

The provider list — Claude, GPT-4o, Gemini, Mistral, DALL-E, Stability AI, ElevenLabs, Runway — covers the obvious ground, but "bring your own key" as a model scales naturally to whatever shows up next; adding a provider is a new small API wrapper file and an entry in a provider list, not a pricing renegotiation.

If the BYOK model is something you'd rather use than another flat-rate AI subscription: ai.findnix.eu.

Building a Community Wiki Around a Privacy-First Search Engine

Mirko Stahnke — Sat, 22 Aug 2026 23:05:42 +0000

The problem: a search engine needs more than a search box

findnix.eu is a EU-based, privacy-first search engine — "Find alles, speichere nix" (find everything, store nothing) is the tagline. Once real users started using it, the support questions started too: how does the spam filter work, why isn't my site indexed yet, what data do you actually store, how do I report a fake shop I found in the results?

Answering the same questions over email doesn't scale, and a single flat FAQ page doesn't either once you also want space for longer-form, kid-safe explainer articles and general knowledge entries contributed by the community. So instead of bolting a FAQ page onto the main site, we split it out into its own project: wiki.findnix.eu.

Three categories, one wiki

The wiki is organized into three top-level groups, each with its own short-link in the header:

FAQ findnix — how the search engine, the spam filter, the DNSBL cross-check, and the points/rewards system work
Kids findnix — safe, curated explainer content that doubles as background material for kids.findnix.eu
Wiki findnix — general knowledge entries submitted by the community, reviewed before they go live

Every entry goes through a submit.php form and lands in a moderation queue with status='approved' as the gate — nothing is public until someone actually looks at it. That single status column is doing a lot of quiet work: it's the difference between "anyone can publish anything" and "anyone can propose something."

Translation without an embedded widget

The wiki needs to serve an EU-wide audience, and hard-coding 20+ language files for community-submitted content isn't realistic for a small team. The pragmatic fix: a language dropdown that builds a one-time link to Google's translate.goog proxy for the current page, entirely client-side, on click:

function wikiGoTranslate(lang) {
  if (!lang) return;
  var host = location.hostname.replace(/\./g, '-');
  var path = location.pathname + location.search;
  var target = 'https://' + host + '.translate.goog' + path
    + (location.search ? '&' : '?')
    + '_x_tr_sl=de&_x_tr_tl=' + lang + '&_x_tr_hl=de';
  location.href = target;
}

No translation script is embedded or running in the background on the page itself — it's a single click handler that computes a URL and navigates. That turned out to matter more than expected: an earlier version embedded Google's live translation widget directly on the page, and it collided with the sticky header (the widget would inject its own top bar and push the layout around). Moving to a proxy-link model instead of an embedded widget removed an entire class of layout bugs, and it means one less third-party script running continuously against visitors' browsers.

Old links still have to work

Categories used to be addressed by numeric ID (?cat=12). Once the wiki grew nice slug-based URLs (?cat_slug=faq-findnix), old bookmarks and inbound links with the numeric form still needed to resolve — so the numeric path does a lookup and issues a real 301 redirect to the slug URL rather than silently rendering the same content on two different URLs:

if ($catId && !$catSlug) {
    $lookup = db()->prepare('SELECT slug FROM categories WHERE id=?');
    $lookup->bindValue(1, $catId, SQLITE3_INTEGER);
    $row = $lookup->execute()->fetchArray(SQLITE3_ASSOC);
    if ($row && $row['slug']) {
        header('Location: /k/' . $row['slug'], true, 301);
        exit;
    }
}

Small detail, but it's the difference between a wiki that quietly accumulates duplicate/dead URLs over years and one that doesn't.

What's next

The wiki is deliberately simple: SQLite-backed, PHP, no JS framework, no build step. That's a feature, not a limitation — it means the barrier to contributing an entry, or to reading the code and understanding exactly what happens to a submission, stays low. As findnix.eu grows, the plan is to keep leaning on the community to write the FAQ and knowledge entries rather than trying to centrally author everything — the people hitting an edge case are usually the best people to explain it to the next person who hits it.

If you want to see it in action (or contribute an entry), it's live at wiki.findnix.eu.

Building a Search Engine for Kids That Doesn't Track Them

Mirko Stahnke — Sat, 22 Aug 2026 23:05:15 +0000

Search engines for kids usually mean one of two things

Either a heavily filtered wrapper around a big commercial index (which still leaks through things a filter didn't anticipate), or a walled garden with a handful of hand-picked links that goes stale in a month. kids.findnix.eu is an attempt at a third option: build and maintain our own curated index, specifically for kids and teenagers, as a companion project to the main findnix.eu search engine.

The homepage states the promise plainly: "no data is stored, and we only try to present vetted, educationally valuable content." Two mascots, Uli and Nele, sit on either side of the search box — which sounds like a small detail, but user testing with actual kids made clear that a friendly, recognizable interface matters as much as the filtering underneath it.

Curation is a crawling problem, not a filtering problem

Rather than filtering an existing general-purpose index after the fact, kids.findnix.eu runs its own dedicated crawlers:

kids_page_image_crawler.php / kids_page_video_crawler.php — pull images and videos specifically from sources already cleared for the kids index
crawl_sitemap_articles.php, crawl_topic_pages.php, crawl_wissenskarten.php — walk sitemaps and topic pages of vetted educational sites
crawl_wp_generic.php — a generic crawler for WordPress-based educational sites, since a huge share of school/educational content in German-speaking countries runs on WordPress
classify_sonstiges_llm.php — an LLM-assisted classification pass for the long tail of content that doesn't fit a hand-written rule

The result, shown live on the homepage, is a running count rather than a marketing number: pages indexed, images, videos, links. It updates because the crawlers keep running, not because someone typed a number into a template once.

The search box is only half the product

What's easy to miss from the name is that kids.findnix.eu isn't just a search box with a filter — half the site is interactive, kid-facing tools built around learning:

Flag Quiz (flaggenquiz.php) — geography, gamified
Secret Code Workshop (geheimcode_werkstatt.php) — classic ciphers, taught by building them
Riddle Challenge (knobel_challenge.php) — logic puzzles
Train your own AI (ki_trainer.php) — a hands-on, simplified intro to how machine learning classification actually works, aimed at demystifying "AI" rather than treating it as magic
Code Adventure (code_abenteuer.php) — a first, gentle introduction to programming

None of these need the search index at all — they're standalone reasons to visit the site directly rather than only arriving via a search query, which matters for a product whose whole pitch is "safe corner of the internet for kids," not just "safe search results."

Accessibility gets its own crawler, too

a11y_crawler.php checks the site's own HTML structure for accessibility issues — worth calling out specifically because it's easy for a "kids" product to over-index on colorful UI and under-index on actually being usable by kids with different needs. Running the accessibility check as its own recurring job, rather than a one-time manual pass, keeps it from silently rotting as pages get added.

No data stored means no data stored

The "no data stored" line on the homepage isn't just copy — visit counting, for example, is deliberately coarse: one cookie-gated counter per visit session (30 minutes), not a log line per page view, and no data ends up tied to an individual beyond a hashed IP used only to avoid double-counting the same visit:

if (!isset($_COOKIE['kids_visited'])) {
    kids_db()->prepare(
        "INSERT INTO fnx_kids_stats (type, referrer, url, ip_hash, lang, user_agent)
         VALUES ('visit', ?, ?, ?, ?, ?)"
    )->execute([...]);
    setcookie('kids_visited', '1', time() + 1800, '/', '', false, true);
}

That's the whole point of building a dedicated kids product instead of just adding a "kids mode" toggle to the main search engine: every default — logging, cookies, what gets shown, what gets stored — gets re-examined for a young audience specifically, instead of inherited from an adult product and only trimmed down after the fact.

kids.findnix.eu is live at kids.findnix.eu, EU-hosted, and — like the rest of the findnix.eu family — built to be small enough that you can actually read the whole thing and know what it does.

findnix.eu: A GDPR-Compliant Search Engine Built From Scratch

Mirko Stahnke — Wed, 19 Aug 2026 23:23:57 +0000

Introduction

Every major search engine today runs on the same trade: you get results, they get your data. findnix.eu is an attempt to break that trade — a search engine built in the EU, for the EU, that doesn't track you, doesn't build a profile of you, and doesn't sell what it doesn't collect in the first place.

This isn't a pitch deck. It's a working search engine, built and run by one person, and this post is a quick tour of what it actually does.

What you can search

findnix.eu isn't just web search. Over time it's grown into a set of focused search verticals, each with its own index:

Web — general search, combining multiple sources with a preference for sites that submit their own sitemap (a small way to give independent sites a fairer shot than they'd get elsewhere)
News — pulled directly from public-broadcaster media libraries across the EU (ARD, ZDF, Arte, ORF, SRF and more), with a built-in video player — no detour through the broadcaster's own site
Podcasts — full show and episode search via the Podcast Index API, with direct in-browser playback
Images & Videos — licensed, freely usable media
Science — open-access papers via OpenAIRE and BASE
Firmen (Companies) — a growing local business index
Kultur — European cultural heritage via Europeana

There's also a companion site, kids.findnix.eu, built specifically for child-safe search — same philosophy, different audience.

No tracking, stated plainly

No tracking cookies, no IP logging, no cross-session profiling. Search history lives in your browser's local storage only, never on the server. Ads (yes, there are ads — servers cost money) are flat-rate and clearly labeled, not auction-based, and capped at 3 per page.

What's newest

The latest addition is a small marketplace feature: a domain valuation and sale tool. You get a free (unbinding, heuristic) valuation of a domain based on TLD, length, and structure, and can list it for sale for a small amount of points — findnix's internal currency, earned through site activity. Inquiries land in an in-app inbox rather than exposing your email address publicly.

Why build this

Mostly because the alternative — accepting that "free" search always means being the product — never sat right. findnix.eu won't out-scale Google. It doesn't try to. It's trying to be a genuinely different deal: you search, we don't remember, and the site stays funded through ads you can actually see and understand, not ones built on a profile of you.

If that sounds like your kind of search engine, give it a try: findnix.eu