Six Small Infrastructure Projects: AltSql, BareProxy, KeyValueStore, Precomputing, Preconfiguration and VPN Works
This page covers six small open infrastructure projects that each do one job: an embedded database for connected devices, a reverse proxy, browser tools for key-value stores, a policy language that keeps answers ready as data arrives, a setup compiler for AI coding agents’ machines, and a network sandbox for agents. They’re separate projects, each with its own site and repository. What they share is an old habit. SQLite showed that a database can be one file linked into a program; nginx showed that a web server can be small and fast. Software in that tradition is easier to read, test and replace.
All six are early, and the sites say plainly what has and hasn’t been tested. Everything below reflects the sites and repositories as of October 2026.
At a glance
| Project | What it is | Language / platform | License | Site |
|---|---|---|---|---|
| AltSql | Embedded key-value and SQL database for IoT devices and gateways | C (single C99 file) | Apache 2.0 | altsql.com |
| BareProxy | Small web server and reverse proxy that explains its routing | Go, Linux | Apache 2.0 | bareproxy.com |
| KeyValueStore | Eight browser tools for Redis, Valkey and DynamoDB | JavaScript, browser plus Node.js CLI | Apache 2.0 | keyvaluestore.com |
| Precomputing | Policy language that keeps answers current in a SQLite file | Go and SQLite, Linux binaries | Apache 2.0 | precomputing.com |
| Preconfiguration | Compiles one spec into setup files for AI coding agents | Go, Linux/macOS/Windows binaries | Apache 2.0 | preconfiguration.com |
| VPN Works | Network sandbox and policy for AI agents, plus four related engines | Go, Linux | Apache 2.0 | vpnw.com |
AltSql: key-value and SQL over the same records
AltSql is an embedded database for connected products, built as a native hybrid of key-value and SQL. The problem is familiar to anyone who has shipped sensors. A device stores readings in one format, the gateway wants them in another, and someone writes glue code to translate between the two. The device usually can’t query its own data either, so it sends everything upstream and stalls when the link drops.
AltSql’s answer is one set of records from the sensor to the gateway. A device keeps the key-value side: get and put go straight to a record, which is all a sensor needs and small enough for its chip. The site puts that side at about 15 KB of code compiled for a Cortex-M4. The records travel byte for byte to the gateway, where AltSql DB opens both doors onto the same store. A get/put and a SQL statement can sit in the same transaction, so related changes are saved together or not at all, and the same code checks types and keys whichever door a change comes through. The gateway build, with both doors, is about a sixth of SQLite’s code.
Add-on modules each add one capability. Ask sends a SQL question out to many devices and brings back only the answers; Vector, Wave, Mesh, Realtime and Instant handle vibration patterns, compressed waveforms, gateway-free sync over lossy radio, hard deadlines and power loss. Live demos run the real engines compiled to WebAssembly, with simulated devices. The project is candid that everything so far runs in simulation; real chips are the next step. Code is on GitHub at github.com/AltSql/altsql.
Who it suits: device makers and IoT teams who want a device and its gateway to agree on data without a translation layer. Gateways in these setups are often Linux boards of the kind covered in our Raspberry Pi guide.
BareProxy: a reverse proxy that tells you why
BareProxy is a small web server and reverse proxy written in Go. Its starting point is that most sites use a thin slice of what a full proxy offers: TLS, a folder served as a site, routing by host and path, spreading requests over backends that are up, config changes that don’t drop traffic, and some way to find out what happened to a request when things break.
The core does exactly those seven things (static files, proxying, TLS, routing, backend health, config changes and request tracing) and nothing else. Its distinguishing feature is that it explains itself. The explain command walks the routing rules for a request and says which rule matched and why the others didn’t. The why command takes a request’s ID and shows which backends were tried and what each returned. The plan command previews a config change against the running config and lists which requests would behave differently, before apply makes it live. Older versions are kept for rollback.
Everything beyond the core is meant to be a module. The site lists eight planned ones, among them compression, rate limits, canary splits, caching, auth and OpenTelemetry export, and says plainly that none is built yet; the 0.1 Alpha is the core alone. A browser demo runs the real code compiled to WebAssembly so you can try explain, why and plan without installing anything. Linux binaries and source are at github.com/BareProxy/bareproxy.
Who it suits: people running a few sites who want to see a config change’s effect before it ships.
KeyValueStore: browser tools for Redis, Valkey and DynamoDB
KeyValueStore is a collection of eight free tools for people who run key-value stores. Each tool is one JavaScript file with no dependencies, runs entirely in the browser and sends nothing anywhere, which matters when you’re pasting production keys or snapshot files.
The tools cover jobs that come up in real operations work:
- Hash Slot Calculator finds which Redis or Valkey cluster slot a key lands in and catches CROSSSLOT errors.
- Consistent Hashing Playground shows how many keys move when you add a server under different hashing schemes.
- Keyspace Map turns SCAN output into a picture of what’s actually in the store.
- Mass Insert Builder converts CSV or JSON into bulk-load files.
- Snapshot Viewer opens RDB snapshots from Redis 2.8 through Valkey 9.1.
- Traffic Analyzer reads MONITOR output for cache hit-rate patterns.
- Typed JSON Converter moves between DynamoDB’s typed JSON and plain JSON.
- Value Inspector decodes Python pickles, serialized Java objects and PHP sessions.
The tools were checked against real Valkey 9.1.2 and Redis 8.10.2 servers, and each tool’s folder in the repository also holds a Node.js command-line version and its tests. The site is independent of Redis, Valkey and AWS. Code: github.com/Keyvalue-Store/tools.
Precomputing: answers kept ready as data arrives
Precomputing is a small policy language for streams of events, with two runtimes that keep its answers current in a SQLite file. The site’s own analogy is the clearest: most software that collects data works like a shop owner with a shoebox of receipts, adding them up again every time someone asks. Precomputing keeps a running total next to the till instead, so a question is answered by reading one number.
A policy is a short text file. It names the event streams you have, the answers to keep ready (counts, sums, percentiles, samples, anomalies) and how long each level of detail survives. One runtime compiles the policy into plain SQLite triggers that run in any SQLite 3.35 or later with math functions, browsers included. The other is a Go binary with SQLite built in that runs the same policy faster and recovers cleanly after a crash. Both write the same file format with the same values.
Apps sit on top. Meter counts usage for billing, handling retries and late reports. Logs keeps a log dashboard’s answers ready while the raw lines stay on site. An MCP server gives AI agents five read-only tools for asking about precomputed answers (see our Model Context Protocol guide for how MCP works). Traces condenses coding-agent call data and masks secrets. Live demos include one that counts every change across Wikipedia’s live stream in the browser. Version 0.1.1-alpha ships with Linux binaries at github.com/precomputing/precomputing; the project notes it has been checked on simulated data, not anyone’s production traffic.
Preconfiguration: one spec for every coding agent’s machine
Preconfiguration prepares the machine an AI coding agent works on before the agent starts. The problem is mundane and expensive: a team using two or three agents writes the same setup two or three times, and an agent that hits a missing dependency burns time installing things by trial and error.
You describe what the project needs once, in a preconfig.yaml file. Preconfig Core compiles that spec into setup files for five targets: dev containers, GitHub Copilot, Cursor, cloud-init and a plain setup script. It also checks existing setup files against the spec to catch drift, and it can prove a setup on a clean machine. Preconfig Doctor reads a failed setup’s log, names the cause and, when the cause is in the spec, writes the fix there. After that the tool gets out of the way; it produces plain files and nothing keeps running while the agent works.
The code is Go with no dependencies beyond the standard library, with binaries for Linux, macOS and Windows (the site notes the Linux x86-64 build is the one that has actually run). The browser demo runs the alpha’s code compiled to WebAssembly: you can edit a spec and watch the generated files change, or paste an existing Copilot or Cursor config and check it. Code: github.com/Preconfiguration/preconfig.
Who it suits: teams running more than one coding agent, and platform teams looking after many repositories. Anyone putting agentic AI to daily use knows the setup step is where quiet failures pile up.
VPN Works: a network of its own for each agent
VPN Works keeps network access narrow and on the record. Its main engine, Agent, gives each AI agent a network of its own on Linux. It seals the agent in, sends its connections down the path you choose, checks each one against a policy and records it.
The agent runs in a private network namespace with only loopback and no route anywhere, plus a seccomp filter, so its only way out is through vpnw. Policies decide in a fixed order: deny rules on names, deny rules on resolved addresses, a private-address check, allow rules, then a default. Every connection is logged with its decision, as text and JSON Lines, while data, URL paths, headers and passwords are deliberately left out. The commands are run, trace, learn, guard, doctor and version, and when vpnw can’t enforce a policy it refuses to run the program at all. It needs a kernel that allows unprivileged user namespaces.
Four more engines sit alongside Agent: Scope learns which internal systems each person on a company VPN actually uses and writes rules for just those, Lab tests VPN apps for leaks when the network misbehaves, Ledger seals connection records so any edit shows, and Exit gives agents fixed exit addresses with policy checked again at the far end. The demo replays an agent trying to leak a deploy token, then lets you edit the policy and rerun it in the browser. Code is Go with no third-party modules, at github.com/VPNWorks/vpnw; there are no packages or prebuilt binaries yet. The same instinct behind putting smart home devices on a separate network applies here, scaled down to a single program.
Who these suit
None of the six is a platform you adopt wholesale. Each is a small piece you can try in a browser demo first and then drop into one corner of a system. They suit engineers who’d rather understand a component than configure one: embedded developers (AltSql), people running their own web front door (BareProxy), Redis and Valkey operators (KeyValueStore), teams drowning in logs or metrics they keep recomputing (Precomputing), and anyone giving AI agents real machines and real network access (Preconfiguration and VPN Works).
Treat them as early software to test on your own data. The roadmap page on each site shows what’s next, and the thing to watch is which ones move from simulation to real hardware and real traffic.