Arkeion ἀρχεῖον
Cloud
Post

Protecting what’s yours

Everything we build starts from one idea: your data is yours. The engine is open, the file is yours, and the first-class way to run Arkeion is to run it yourself. We don’t say that because a regulation makes us — we say it because it’s the right way to build. This post is the long version of what that means in practice, and how we help you expose a database to the world without handing it to the world.

Self-host is the default, not the fallback

Most databases are a server you talk to over a network. You run a process, open a port, manage users, and your application connects to it as a client. That model made sense when a database was a shared mainframe; it makes less sense when the “server” is a container next to your app doing nothing but answering one service.

Arkeion is different: it is an embedded engine. cargo add arkeion and the database lives inside your application as a library, reading and writing a single file. There is no port to open, no second process to babysit, no network hop between your code and your data. The database is a function call away.

your application your code Arkeion (library) db.arkeion one process · one file · no network vs. client / server app db server socket a port, always listening
Embedded: the engine is a library inside your process, touching the file directly. Nothing is listening on a socket until you decide it should.

That last sentence is the whole security story in miniature. An embedded database has no attack surface of its own — there is nothing to reach over the network, because there is no network. The moment you decide other machines should talk to your data, you open that door, deliberately, and you decide what stands in it.

The moment a database faces the internet

Plenty of real systems do need a database reachable from outside: a mobile app syncing to a backend, an internal tool exposed to a team, an API that serves data to partners. The instant an endpoint is public, it stops being a quiet file and becomes a target. The attacks are not exotic; they are constant and automated:

  • Rate abuse and denial of service — a single client hammering you until you fall over, or a botnet doing it on purpose.
  • Malicious payloads — injection attempts, oversized bodies, malformed requests probing for a crash.
  • Credential stuffing — reused passwords sprayed against your auth, thousands per second.
  • Scraping — slow, patient harvesting of everything you’ll hand out.
the internet rate abuse / DoS injection payloads credential stuffing scraping exposed database nothing in front of it
An endpoint with nothing in front of it takes every request at face value — including the ones that want to hurt it.

Here is the design principle we keep coming back to: that defensive work does not belong inside the database. A query engine’s job is to answer queries correctly and quickly, not to guess which callers are hostile. Bolt rate-limiting and payload inspection into the engine and you get a slower engine and a weaker shield. The shield belongs in front, as its own layer, where it can drop bad traffic before it ever costs you a query.

quoxy puts quota in front

That front layer is quota: rate-limiting, a WAF, an API shield, analytics, and an edge network — the machinery of a hardened public endpoint, without you building it. quoxy is the piece that joins the two worlds: it connects your self-hosted Arkeion to quota so that every request from the outside passes through quota first, and only clean, allowed traffic reaches your database over a secure connection.

Internet quota · edge global points of presence filters + observes quoxy connector TLS arkeiond your file outside traffic never reaches arkeiond directly — only quoxy does
The public address belongs to quota, not to your database. quoxy is the only thing that talks to arkeiond, over TLS, from a place you control.

Because the public address is quota’s and not your database’s, your Arkeion never has to be directly reachable at all. It listens only for quoxy. The blast radius of a mistake shrinks accordingly: there is no open database port on the internet to find, only an edge that is built to be found.

What each layer actually does

The value is in the order things happen. A request runs a gauntlet, and each stage can end its journey:

  • Rate-limiting — per-key and per-route budgets. A caller gets a fair share and no more; a flood is shed at the edge, far from your engine, before it can become load.
  • WAF — payload inspection. Known-bad shapes — injection strings, malformed bodies, oversized uploads — are dropped on sight.
  • API shield — authentication and schema validation before the database. A request without a valid key, or with a body that doesn’t match the contract, never becomes a query. Your engine only ever sees well-formed, authorized calls.
  • Analytics — you see the traffic: who is calling, how often, what’s being blocked and why. Protection you can’t observe is protection you can’t trust.
  • Edge — all of the above runs close to your users, so the shield adds a hop measured in single-digit milliseconds instead of a round trip across the planet.
request rate-limit budget? WAF payload ok? API shield auth + schema Arkeion too many malicious unauthorized every request runs the gauntlet — only clean, authorized calls reach the engine dashed = dropped here, before it costs a query
Bad traffic is shed as early as possible. By the time a request is a query, it has already proven it deserves to be one.

Why we build it this way

These are not marketing reasons. They are the reasons:

  • You own it. Your database is a file. You can copy it, export it, back it up, and walk away with it whenever you like. There is no hostage data — nothing of yours that only works while you keep paying us.
  • You can leave. The engine is MIT/Apache. That licence is a promise we cannot revoke: whatever we build on top, the thing underneath stays yours and stays free.
  • Protection is a default, not an upsell. Exposing a database with nothing in front of it is a footgun, and we don’t think the safe path should be the expensive one. quoxy exists so that “put it on the internet” and “protect it” are the same decision, not two.

Self-host first. Protected by default. Yours, always. That’s the whole idea — and it’s the same idea underneath everything else we make.