Proxelar 0.5.0: Sessions, Rules, and More Ways to Capture Traffic

Unknown — Wed, 22 Jul 2026 00:00:00 +0000

Disclosure: this post was written with the assistance of an LLM. The release, the code, and the technical decisions behind it are my own work, and I have reviewed and edited everything below.

Proxelar 0.5.0</a> is out.

This release got a bit out of hand. I started with one annoyance, captures disappearing when the proxy stops, and ended up adding sessions, HAR import/export, a real filter language, content-aware body views, declarative rules, a headless API, addon packages, and four new capture modes.

A flat feature list wouldn't help much, so this post follows a workflow instead: get traffic into Proxelar, find the exchange you care about, understand the body, change or replay it, and keep the result for later.

Captures Finally Survive a Restart</h2>
The most obvious missing piece was persistence. Until now, closing Proxelar meant losing the session.
You can now save the complete capture when Proxelar shuts down cleanly:
proxelar --save-session checkout-debug.proxelar.json</code></pre> Press Ctrl+C when you're done. The file contains completed HTTP flows, WebSocket connections and frames, observed raw TCP chunks, DNS exchanges, UDP datagrams, stable flow IDs, and body-truncation metadata. Load it on the next run:
proxelar \ --load-session checkout-debug.proxelar.json \ --save-session checkout-debug-continued.proxelar.json</code></pre> The old flows appear immediately, and new traffic is appended to the same in-memory session. This is what I wanted when a bug takes three attempts to reproduce and you don't want three unrelated screenshots pretending to be one timeline. The native format is versioned JSON, and I kept it readable on purpose. It's large, but you can inspect it, diff it, or write a small conversion tool without depending on an opaque database. One thing to watch: native sessions are not redacted. They preserve the capture exactly, so they can contain cookies, authorization headers, tokens, and request bodies. Treat them like credentials and don't commit them.
HAR, curl, and Raw HTTP</h2>
The native format is the best representation of a Proxelar session, but it's not always the format you need. 0.5.0 can import HAR and export three interoperable forms:
proxelar \ --import-har browser-capture.har \ --export-har cleaned.har \ --export-curl replay.sh \ --export-raw raw-flows/</code></pre> HAR carries HTTP requests and responses. The curl export writes one command per request. Raw export writes request/response file pairs while preserving repeated headers instead of flattening them into a map. Common secrets are redacted from these exports by default:

Authorization</code> and Proxy-Authorization</code></li>
Cookie</code> and Set-Cookie</code></li>
common token and secret query parameters</li> </ul> You can opt out with --export-secrets</code>, and the flag is loud about it on purpose. Exported captures have a way of ending up in issue trackers, chat messages, and temporary repositories, so redaction is the safer default. HAR can't represent everything in a native session. Raw TCP chunks, DNS/UDP data, and some WebSocket metadata stay native-only. In practice I use HAR when another tool needs the HTTP traffic, curl when I want a reproducible request, and the native file when I might need the full capture later.
Filters Became a Language</h2> The old column:value</code> filter was fine for status:404</code>. It got awkward the moment I wanted something like "POST requests that failed, except health checks". Filters now support boolean operators, parentheses, negation, and body/header matching:
method:POST & status:500 host:api.example.test & !path:/health (status:401 | status:403) & header:authorization type:json & response_body:error proto:wss | proto:https</code></pre> Adjacent terms are an implicit AND, so this works too: method:POST host:api.example.test status:4</code></pre> The available fields are host:</code>, method:</code>, status:</code>, type:</code>, body:</code>, header:</code>, request_body:</code>, and response_body:</code>. Matching is substring-based rather than regular-expression-based, which keeps the common cases readable without much quoting. The same parser backs the TUI, web GUI, session API, and cross-protocol match endpoint, so a filter doesn't mean one thing in the terminal and something slightly different in the browser. Bodies Are More Than a Byte Count</h2> Clicking a JSON response and seeing one long escaped string wasn't useful. The new content layer decodes transport and content encodings, then picks a view based on the media type. JSON, XML, HTML, forms, multipart bodies, CSS, and JavaScript are formatted for inspection. Declared character sets are decoded. gzip</code>, Brotli, zstd, and deflate bodies are decompressed before display. Safe raster images can render directly in the web interface. Binary data stays binary. Invalid UTF-8 request bodies open as hexadecimal bytes instead of being mangled through a replacement-character string. Protobuf messages can be viewed and edited as wire fields without a schema, and JSON-shaped MessagePack values get a structured editor. There are limits. Protobuf without a schema gives you field numbers, not meaningful names. Multipart is split into readable parts, but it isn't a full structured multipart editor. A body capped by --body-capture-limit</code> is marked as truncated and can't be reconstructed from the captured prefix. When an intercepted or replayed body changes, Proxelar drops stale transfer/content encodings and recalculates Content-Length</code>. That sounds minor, but an editor that leaves Content-Encoding: gzip</code> on a plain JSON body creates bugs that look nothing like the edit you just made. Rules for the Things That Don't Need Lua</h2> Lua is still the flexible option, but I kept writing tiny scripts for jobs that are really configuration: map this asset directory, point this API prefix at localhost, return a fixed health response. Two common mappings can now live on the command line: proxelar \ --map-local 'https://app.test/assets/=./fixtures/assets' \ --map-remote 'https://api.test/v1/=http://127.0.0.1:3000/'</code></pre> For anything more involved, use a JSON rules file: { "rules": [ { "action": "set_request_header", "url_prefix": "https://api.test/", "name": "x-debug-client", "value": "proxelar" }, { "action": "mock", "url_prefix": "https://api.test/health", "method": "GET", "status": 200, "headers": [{ "name": "content-type", "value": "application/json" }], "body": "{\"ok\":true}" } ] }</code></pre>proxelar --rules rules.json</code></pre> Rules run in file order. Header changes can accumulate; the first matching rule that creates a response wins. The available actions are map_local</code>, map_remote</code>, redirect</code>, mock</code>, set_request_header</code>, and remove_request_header</code>. Map-local paths are constrained to the configured directory, and ../</code> traversal and symlink escapes are rejected. A development convenience shouldn't turn into a file server for the rest of your machine. Roughly: rules for static routing, Lua when the decision needs code, interactive intercept when it's one request. A Headless API</h2> The web interface already needed a server for live events and commands, so 0.5.0 exposes the useful parts as a documented JSON API: export PROXELAR_TOKEN='local-development-token' proxelar -i api --api-token "$PROXELAR_TOKEN"</code></pre> Every request needs a bearer token: curl \ -H "Authorization: Bearer $PROXELAR_TOKEN" \ 'http://127.0.0.1:8081/api/v1/flows?filter=method:POST%20%26%20status:500'</code></pre> The API can read the session, query flows, fetch decoded content views, replay requests, clear traffic, toggle intercept mode, and resolve pending intercepts with forward/drop/modify decisions. Binary modified bodies can be sent as byte arrays, and headers can be represented as an ordered list when duplicate order matters. Shell scripts and local test harnesses become straightforward, which is what I was after. It's still a local developer API. There are no user accounts, TLS termination, rate limits, or multi-tenant permissions. Keep it on loopback, and if it has to cross a network, put it behind an authenticated TLS tunnel and treat the token as a credential. The browser GUI uses a separate login token. Proxelar opens a URL with the token in the fragment, exchanges it for an HttpOnly</code>, SameSite=Strict</code> cookie, and removes the fragment from browser history. The API token isn't embedded in the downloadable JavaScript. More Ways to Get Traffic In</h2> Forward and reverse proxy modes are still the normal choices, but some clients can't be configured with an HTTP proxy at all. 0.5.0 adds four narrower capture modes for those cases. SOCKS5</h3> proxelar -m socks5 -p 1080 curl --socks5-hostname 127.0.0.1:1080 http://example.com/</code></pre> The SOCKS5 listener accepts IPv4, IPv6, and domain CONNECT targets. HTTP is inspected, TLS goes through the normal local-CA flow, and unknown protocols are recorded as directional raw TCP chunks. There's no SOCKS authentication yet, so bind it to loopback. DNS</h3> proxelar -m dns -p 5353 \ --dns-upstream 1.1.1.1:53 \ --dns-map api.example.test=127.0.0.1</code></pre> DNS mode records UDP queries and responses, forwards normal lookups to the configured resolver, and can synthesize A/AAAA answers. I use it to point a real client at a local API without touching the client's hostname configuration. It's plain UDP DNS, not DNS-over-HTTPS. Fixed-Target UDP</h3> proxelar -m udp -p 9001 --target upstream.example:9000</code></pre> This mode forwards each incoming datagram to one known upstream and records both directions. It's request/response-oriented by design: one target, at most one response per request, and a five-second no-response result. Good for small known UDP protocols, not a general UDP router. WireGuard</h3> This is the mode I'm happiest with. If an app has no proxy setting but can use a VPN profile, nothing else in Proxelar could reach it before. proxelar -m wireguard -b 0.0.0.0 -p 51820 \ --wireguard-endpoint 192.168.1.10:51820</code></pre> On first start, Proxelar writes an owner-only client configuration to ~/.proxelar/proxelar-wg.conf</code>. The empty TUI and authenticated web GUI show the same profile as a QR code, and terminal mode prints it at startup. Scan it from the WireGuard app or import the file directly. The QR disappears from the interactive interfaces after the first captured event. The proxelar-wg</code> name has to be short because Android caps WireGuard interface names at 15 characters. The QR contains the client private key, so only show it on a trusted screen. TCP is reconstructed in userspace and then follows the normal HTTP, TLS, WebSocket, or raw-stream paths. Port 53 uses the DNS configuration and overrides described above. For now it generates one client identity per CA directory, UDP forwarding is still aimed at request/response traffic, and QUIC/HTTP/3 interception isn't supported. Chaining Through Another Proxy</h2> Outbound connections can go through an HTTP CONNECT or SOCKS5 proxy: proxelar --upstream-proxy http://proxy.example:8080 proxelar --upstream-proxy socks5://127.0.0.1:9050 proxelar --upstream-proxy http://proxy.example:8080 \ --upstream-proxy-auth 'user:password'</code></pre> Chaining applies to ordinary forwarding, reverse mode, and replay. Credentials passed on the command line may be visible to local process inspection, so use a dedicated low-privilege account rather than your important password. Lua Addons Instead of Loose Folders</h2> Loose --script</code> files are still the fastest way to iterate. They now hot-reload when the entrypoint changes, keeping the last working version if the new script has an error. WebSocket frames can also pass through an optional Lua hook for modification or dropping. For something I want to keep or share, there's now an addon package format: proxelar addon verify ./header-tagger proxelar addon install ./header-tagger proxelar addon list proxelar --addon header-tagger</code></pre> An addon has an init.lua</code> entrypoint and a versioned proxelar-addon.json</code> manifest. The manifest declares its version, hooks, requirements, and a SHA-256 digest for every file. Installation rejects traversal, symlinks, undeclared files, and digest mismatches before copying the package into the local catalog. No online marketplace, no registry. It's an inspectable package boundary for Lua code you already have on disk, which is as far as I want to take it for now. Launching a Browser Without Changing System Settings</h2> For browser-only debugging, this is the shortest path: proxelar -i gui --launch-browser</code></pre> Proxelar finds a Chromium-family browser and starts an isolated profile configured to use the proxy. Your normal profile, extensions, cookies, and proxy settings stay untouched, which saves you from remembering what to undo afterwards. A Few Things That Changed Underneath</h2> Some smaller changes that matter even without their own button: generated leaf certificates now use distinct ECDSA private keys instead of reusing the CA key</li> replay and edited bodies reconcile stale encoding and length headers</li> proxyapi</code> keeps #![forbid(unsafe_code)]</code>, and addons remain portable pure Lua</li> release artifacts include SHA-256 checksums, SPDX SBOMs, and provenance attestations</li> the repository now documents the session compatibility policy, capture topology, architecture, and threat model</li> </ul> And the limits worth knowing up front: HTTP/2 clients are accepted, but inspected requests are currently normalized and forwarded upstream as HTTP/1.1. HTTP/3 isn't intercepted. Certificate-pinned applications will reject the generated certificates, and Android applications have to explicitly trust user-installed CAs. I'd rather write those down than hide them behind a "supports HTTPS" bullet. Getting Started</h2> Install or update Proxelar: brew upgrade proxelar # or cargo install proxelar</code></pre> For a quick browser session with persistence: proxelar -i gui --launch-browser \ --save-session debug.proxelar.json \ --export-har debug.har</code></pre> For a quick SOCKS test: proxelar -i gui -m socks5 -p 1080 curl --socks5-hostname 127.0.0.1:1080 http://example.com/</code></pre> For a local API with a static mock: proxelar -m reverse \ --target http://127.0.0.1:3000 \ --rules rules.json \ --save-session local-api.proxelar.json</code></pre> The full documentation is at proxelar.micheletti.io</a>, and the complete changelog is on GitHub</a>. I'd start with sessions and the filter language. They're the least dramatic features in the release, and they're the ones that changed my day-to-day use the most. Capture something once, narrow it down without scrolling through 500 rows, and keep the useful part for tomorrow.

Proxelar 0.4.0: Intercept & Modify Traffic

Unknown — Sat, 04 Apr 2026 00:00:00 +0000

I'm happy to release Proxelar 0.4.0</a>, which delivers the feature I teased at the end of the 0.3.0 post</a>: intercept mode. You can now pause any HTTP or HTTPS request mid-flight, inspect it, edit whatever you want — method, URI, headers, body — and then choose to forward it or drop it entirely.

Until now, Proxelar could capture and display traffic, and with scripting it could modify traffic programmatically. But there was no way to reach in and change a specific request by hand, on the fly, without writing a script first. Intercept mode fills that gap. You see the request frozen in front of you, exactly as the client sent it, and you decide: forward it as-is, modify it first, or drop it entirely.

How Intercept Mode Works</h2>
When intercept is off, traffic flows through normally — captured, displayed, forwarded. When intercept is on, every request is held. Nothing reaches the upstream server until you act on it. The proxy is paused, waiting for your decision.
TUI</h2>
Toggling Intercept</h3>
Press i</code> to enable intercept. The status bar shows a red INTERCEPT</code> badge so you always know whether you're in capture-only mode or actively intercepting.
Press i</code> again to turn it off. Any requests that were pending at that moment are forwarded immediately — clients never hang waiting for a response.

Acting on a Request</h3> When a request arrives while intercept is on, it appears in the request list as a ⏸</code> row instead of the usual status code. Navigate to it with j</code>/k</code> and choose what to do: Key</th> Action</th></tr></thead> f</code></td> Forward the request to the upstream server</td></tr> d</code></td> Drop — returns a 504 Gateway Timeout to the client</td></tr> e</code></td> Open the inline editor</td></tr> </tbody></table> The Inline Editor</h3> Press e</code> and the full raw HTTP request appears in an editor panel. Every part of the request is editable — the request line, headers, blank separator, and body, exactly as they would be written on the wire: POST /api/login HTTP/1.1 host: example.com content-type: application/json authorization: Bearer old-token {"user":"alice","pass":"secret"}</code></pre> Change anything. Replace the URL, swap the method, add or delete a header, rewrite the body. The editor supports full cursor navigation: Key</th> Action</th></tr></thead> Arrow keys / Home / End</td> Move the cursor</td></tr> Enter</td> Insert a new line</td></tr> Backspace / Delete</td> Delete characters</td></tr> Esc</code></td> Finish editing — request stays held, ready to forward</td></tr> f</code></td> Forward with your edits applied</td></tr> d</code></td> Drop</td></tr> Esc</code> (again, when not typing)</td> Discard your edits</td></tr> </tbody></table> The design is a two-step flow: edit freely, then Esc</code> to stage your changes, then f</code> to forward. This lets you review your edits before committing. If you change your mind and want to discard everything, press Esc</code> again from the idle-in-editor state. If the request line you wrote is malformed — wrong format, missing HTTP version, unrecognized method — the editor stays open and the border turns red. Fix the line and try forwarding again. The proxy never sends a request it can't parse. Binary bodies — if the original request body is not valid UTF-8, the editor shows a ⚠ warning. The content is displayed lossily; edits may corrupt binary data, so forward binary-bodied requests without edits or drop them. A future patch will preserve the original bytes when only the method, URI, or headers are changed. </blockquote> Here is a complete session: a login request caught mid-flight, the token replaced, forwarded to the server: # Original: POST /api/login HTTP/1.1 host: api.example.com content-type: application/json {"user":"alice","pass":"wrong-password"} # Edited (in the TUI inline editor): POST /api/login HTTP/1.1 host: api.example.com content-type: application/json {"user":"alice","pass":"correct-password"} # After pressing f: → server receives the corrected request → client receives the real response → TUI shows the completed exchange as a normal row</code></pre> No script, no configuration, no restart. You caught it, changed it, forwarded it. Web GUI</h2> The web GUI gets the same capabilities with a point-and-click interface. Toggling Intercept</h3> Click the ⏸ Intercept: OFF</code> button in the toolbar to enable intercept. It turns red and starts displaying a count of pending requests — ⏸ Intercept: ON (2)</code> — so you can tell at a glance how many clients are waiting. Click it again to turn intercept off. All pending requests are forwarded immediately. Acting on a Request</h3> Pending requests appear in the table with an amber left border to distinguish them from completed exchanges. Click a row to open the editor panel. The panel shows four editable fields: Method — text field, e.g. GET</code>, POST</code>, DELETE</code></li> URI — the full request URI</li> Headers — key/value pairs, one per line</li> Body — free-form text area</li> </ul> Edit whatever you need, then: Click Forward to send the request (with any edits applied)</li> Click Drop (504) to block the request and return a 504 to the client</li> Press Ctrl+Enter as a keyboard shortcut for Forward</li> Press Esc or click × to close the panel without acting — the request stays pending in the table</li> </ul> Here's a typical flow in the web GUI: you're testing an API that reads a user ID from the URL. You intercept a GET /api/users/1</code> request, change the ID to 99</code>, and forward it to see what the server returns for a user you don't have credentials for. Two clicks, no tooling. Practical Scenarios</h2> Testing Authorization Logic</h3> You want to verify that your API correctly rejects requests with an expired token. With intercept on, catch a normal request, replace the Authorization</code> header with an expired JWT, and forward: GET /api/profile HTTP/1.1 host: api.example.com authorization: Bearer eyJ... (expired token)</code></pre> The server returns 401. You've confirmed the token validation is working — without touching any client code or adding test infrastructure. Overriding Request Parameters</h3> Your frontend sends a request with a hardcoded value you can't easily change without recompiling. Intercept it, replace the value in the body, forward it: # Original body: {"plan": "free", "user_id": 42} # Edited: {"plan": "enterprise", "user_id": 42}</code></pre> You just tested the premium code path from your existing client session. Catching and Blocking Specific Requests</h3> Sometimes you want to know what happens when a request doesn't go through. Drop a specific request mid-session — the client gets a 504, and you observe how it handles the failure without shutting anything down. Replaying a Request with Modifications</h3> Intercept is complementary to Lua scripting. A script is the right tool when you want a rule that applies to every request matching a pattern. Intercept is the right tool when you want to make a one-off decision for a specific request, inspect the result, and move on. Under the Hood</h2> Intercept mode is built around two new types exported from proxyapi</code>: pub struct InterceptConfig { pub enabled: bool, } pub enum InterceptDecision { Forward(ProxiedRequest), Drop, }</code></pre> When intercept is enabled, the CapturingHandler</code> emits a RequestIntercepted</code> event with the request and a oneshot channel instead of forwarding immediately. The interface layer — TUI or web GUI — receives the event, holds the request in a pending list, and waits for the user's decision. When the user acts, an InterceptDecision</code> is sent back through the channel and the proxy forwards or drops accordingly. The RequestIntercepted</code> event carries the same stable ID that the eventual RequestComplete</code> event will use, so the interface can correlate the pending row with the completed exchange after the request goes through. Turning intercept off drains the pending queue by sending InterceptDecision::Forward</code> for each waiting request. This is why clients don't hang: the proxy never leaves a oneshot receiver without a sender. One edge case worth knowing: if a client times out while its request is pending, it drops the TCP connection. The row stays in the UI — the proxy has no way to know the client gave up. If you then forward, the upstream response has nowhere to go and the write fails silently. The proxy handles this gracefully, but the pending row will linger until you act on it or toggle intercept off. The parse-error path in the TUI editor validates the edited request before forwarding. If the request line doesn't parse — wrong number of parts, unrecognized method, bad HTTP version — the editor returns an error and the border turns red. The forward is not attempted until the input is valid. Two bugs were fixed in this release along the way: XSS in the web GUI header editor — the header editor was previously building the DOM using innerHTML</code>, which would execute arbitrary HTML in header values. It now uses proper DOM construction methods.</li> Multi-value header loss — both the TUI and web editors were using insert</code> when writing edited headers back, which silently dropped all but the last value for headers like Set-Cookie</code>. They now use append</code>.</li> </ul> Getting Started</h2> Update Proxelar: cargo install proxelar</code></pre> Run the proxy: proxelar # TUI (default) proxelar -i gui # Web GUI at localhost:8081</code></pre> In the TUI, press i</code> to toggle intercept. In the web GUI, click the intercept button in the toolbar. Browse normally — or point curl</code> at the proxy with --proxy http://127.0.0.1:8080</code> — and watch requests arrive as ⏸</code> rows. The full documentation for intercept mode is at proxelar.micheletti.io/intercept.html</a>. The complete changelog is on GitHub</a>. What's Next</h2> Intercept mode closes the gap between passively watching traffic and actively controlling it. The remaining items from the 0.3.0 roadmap</a> are still the priority: Traffic replay — resend any captured request from the UI, or serve recorded responses as a mock server. The data is already there; this is about building the UI to use it.</li> Save / load / export — persist captured sessions to disk. Export to HAR, curl commands, or raw HTTP. No more losing everything on shutdown.</li> HTTP/2 interception — full MITM for HTTP/2 connections instead of falling through to raw TCP tunneling.</li> WebSocket inspection — decode and display individual WebSocket frames with message-level granularity.</li> Content views — auto-detect and prettify JSON, XML, HTML, Protobuf, and form data with syntax highlighting across all interfaces.</li> </ul> Proxelar 0.3.0: Lua Scripting for HTTP Traffic Unknown — Sun, 29 Mar 2026 00:00:00 +0000 I'm happy to release Proxelar 0.3.0</a>, which adds the feature I've wanted since the beginning: Lua scripting. You can now write simple scripts that intercept, modify, block, or mock HTTP traffic as it flows through the proxy. Until now, Proxelar could capture and display traffic, but it couldn't change it. That made it a viewer, not a tool. With scripting, Proxelar becomes programmable — you can inject headers, block ad domains, mock API endpoints, rewrite responses, strip cookies, and anything else you can express in a few lines of Lua. This is the single biggest feature since the 0.2.0 rewrite</a>. How It Works</h2> Create a Lua script that defines on_request</code> and/or on_response</code> — both are optional. Pass it to Proxelar with --script</code>: proxelar --script my_script.lua</code></pre> That's it. The proxy loads the script at startup, and every request and response flows through your hooks before being forwarded. Here's the full API: -- Called before forwarding the request to the upstream server. -- Return the request table to forward it (modified or not). -- Return a response table to short-circuit (the request never reaches upstream). -- Return nil to pass through unchanged. function on_request(request) -- request.method "GET", "POST", ... -- request.url "https://example.com/path?q=1" -- request.headers { ["host"] = "example.com", ... } -- request.body string (may contain binary data) end -- Called before returning the response to the client. -- Return the response table (modified or not), or nil to pass through. function on_response(request, response) -- response.status 200 -- response.headers { ["content-type"] = "text/html", ... } -- response.body string end</code></pre> The design is deliberately minimal: two hooks, plain Lua tables, no framework to learn. If you've ever written a line of Lua (or even if you haven't — the syntax takes about five minutes to pick up), you can start scripting your proxy immediately. And if five minutes still sounds like too much effort, just describe what you want to an LLM and paste the output. Why Lua</h2> Scripting is the feature that turns a proxy from a debugging tool into a development platform. For a Rust project, I wanted a scripting language that could be embedded with zero system dependencies. Lua checks every box. It's the standard scripting language for networking tools — nginx, HAProxy, nmap, Redis, and WireGuard all use it. The runtime is tiny, fast (script calls take microseconds), and the mlua</a> crate provides safe Rust bindings with vendored compilation. When you cargo install proxelar</code>, Lua 5.4 is compiled from source alongside everything else. No Python installation, no PATH issues, no version conflicts. Scripting is behind a scripting</code> feature flag (enabled by default), so if you need a minimal build without Lua, --no-default-features</code> gives you exactly the same proxy as before. Real Examples</h2> Let me walk through a few practical scenarios. Each one is a complete, working script. Blocking Domains</h3> The simplest use case: prevent requests from reaching certain hosts. local blocked = { "ads%.example%.com", "tracker%.analytics%.com" } function on_request(request) for _, pattern in ipairs(blocked) do if string.find(request.url, pattern) then return { status = 403, headers = { ["Content-Type"] = "text/plain" }, body = "Blocked by Proxelar: " .. request.url, } end end end</code></pre>$ curl -x http://127.0.0.1:8080 http://ads.example.com/banner.js Blocked by Proxelar: http://ads.example.com/banner.js $ curl -x http://127.0.0.1:8080 http://example.com/ <!doctype html>... # passes through normally</code></pre> When on_request</code> returns a table with a status</code> field, Proxelar treats it as a response and sends it back directly — the request never leaves the proxy. Return nil</code> (or nothing) and the request passes through untouched. Mocking API Endpoints</h3> During frontend development, you often need a backend endpoint that doesn't exist yet. Instead of setting up a mock server, point your app at the proxy and let the script handle it: function on_request(request) if request.method == "GET" and string.find(request.url, "/api/user/me") then return { status = 200, headers = { ["Content-Type"] = "application/json" }, body = '{"id": 1, "name": "Test User", "email": "test@example.com"}', } end if request.method == "POST" and string.find(request.url, "/api/login") then return { status = 200, headers = { ["Content-Type"] = "application/json" }, body = '{"token": "mock-jwt-token-12345", "expires_in": 3600}', } end end</code></pre>$ curl -x http://127.0.0.1:8080 http://api.myapp.com/api/user/me {"id": 1, "name": "Test User", "email": "test@example.com"} $ curl -x http://127.0.0.1:8080 -X POST http://api.myapp.com/api/login {"token": "mock-jwt-token-12345", "expires_in": 3600} $ curl -x http://127.0.0.1:8080 http://api.myapp.com/api/products # passes through to the real server</code></pre> Unmocked endpoints pass through normally, so you can mix real and fake responses in the same session. Injecting Headers</h3> Need to test how your app behaves with specific headers? Inject them on every request: function on_request(request) request.headers["Authorization"] = "Bearer dev-token-12345" request.headers["X-Request-ID"] = tostring(os.time()) return request end</code></pre>$ curl -x http://127.0.0.1:8080 http://httpbin.org/headers { "headers": { "Authorization": "Bearer dev-token-12345", "X-Request-ID": "1743206400", "Host": "httpbin.org", ... } }</code></pre> This is particularly useful for testing authenticated APIs without modifying client code or storing credentials in app configuration. Adding CORS Headers</h3> Every frontend developer has hit CORS issues during local development. Instead of configuring the backend, let the proxy fix it: function on_response(request, response) response.headers["Access-Control-Allow-Origin"] = "*" response.headers["Access-Control-Allow-Methods"] = "GET, POST, PUT, DELETE, OPTIONS" response.headers["Access-Control-Allow-Headers"] = "Content-Type, Authorization" return response end</code></pre>$ curl -v -x http://127.0.0.1:8080 http://api.example.com/data < HTTP/1.1 200 OK < Content-Type: application/json < Access-Control-Allow-Origin: * < Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS < Access-Control-Allow-Headers: Content-Type, Authorization</code></pre> The CORS headers are injected into every response, regardless of what the upstream server returns. Point your browser at the proxy and the cross-origin errors disappear. Rewriting HTML Responses</h3> You can modify response bodies too. This script injects a visual indicator into every HTML page so you always know you're browsing through the proxy: function on_response(request, response) local ct = response.headers["content-type"] or "" if not string.find(ct, "text/html") then return end local banner = '<div style="position:fixed;top:0;left:0;right:0;' .. 'background:#ff6b35;color:white;text-align:center;' .. 'padding:4px;z-index:99999;font-size:12px;">' .. 'Proxied by Proxelar</div>' response.body = string.gsub(response.body, "<body>", "<body>" .. banner, 1) return response end</code></pre> Every HTML page now shows an orange bar at the top. Non-HTML responses (images, JSON, CSS) pass through untouched because the function returns nil</code> early. Stripping Tracking Cookies</h3> Remove known tracking cookies from your outgoing requests while keeping functional ones intact: local tracking = { "_ga", "_gid", "fbp", "fr", "datr" } function on_request(request) local cookie = request.headers["cookie"] if not cookie then return end local kept = {} for pair in string.gmatch(cookie, "([^;]+)") do pair = string.match(pair, "^%s*(.-)%s*$") local name = string.match(pair, "^([^=]+)") local dominated = false for _, tc in ipairs(tracking) do if name == tc then dominated = true; break end end if not dominated then table.insert(kept, pair) end end if #kept > 0 then request.headers["cookie"] = table.concat(kept, "; ") else request.headers["cookie"] = nil end return request end</code></pre># Original cookie header: # Cookie: session=abc123; _ga=GA1.2.123; lang=en; _gid=GA1.2.456 # After script: # Cookie: session=abc123; lang=en</code></pre>Logging Traffic</h3> For quick debugging, print a summary of every request and response to stdout: function on_request(request) print(string.format("[REQ] %s %s", request.method, request.url)) end function on_response(request, response) local ct = response.headers["content-type"] or "unknown" local size = #response.body print(string.format("[RES] %s %s -> %d (%s, %d bytes)", request.method, request.url, response.status, ct, size)) end</code></pre>$ proxelar -i terminal --script log_traffic.lua # (in another terminal: curl -x http://127.0.0.1:8080 http://example.com) [REQ] GET http://example.com/ [RES] GET http://example.com/ -> 200 (text/html; charset=UTF-8, 1256 bytes)</code></pre> Notice that both hooks return nil</code> (implicitly), so traffic passes through unchanged. The script is purely observational. Reverse Proxy + Scripting</h2> The examples above use forward proxy mode, where you configure your client to route through Proxelar. But scripting really shines in reverse proxy mode, where Proxelar sits in front of your service and you control the traffic between your clients and your backend. This is the setup you'd use at work — put the proxy in front of your local API, staging environment, or microservice, and let scripts handle the rest. Simulating Authentication in Development</h3> Your backend requires a JWT, but during local development you don't want to go through the login flow every time. Put Proxelar in front of your API and let the script handle auth: proxelar -m reverse --target http://localhost:3000 --script auth_dev.lua -p 4000</code></pre>-- auth_dev.lua -- Clients hit localhost:4000, Proxelar forwards to localhost:3000 with auth injected local DEV_USER = '{"sub": "user-42", "role": "admin", "name": "Dev User"}' function on_request(request) -- Skip if the client already sent a token if request.headers["authorization"] then return end request.headers["authorization"] = "Bearer dev-token" -- Inject the decoded user context that your middleware expects request.headers["x-user-context"] = DEV_USER return request end</code></pre># No token needed — the proxy injects it $ curl http://localhost:4000/api/admin/users [{"id": 1, "name": "Alice"}, {"id": 2, "name": "Bob"}] # If you pass your own token, the script leaves it alone $ curl -H "Authorization: Bearer real-token" http://localhost:4000/api/me {"id": 7, "name": "You"}</code></pre> Your frontend, Postman, or any HTTP client can hit localhost:4000</code> without worrying about tokens. The backend sees a properly authenticated request every time. Adding Security Headers to a Local Service</h3> Your staging environment fails security audits because the backend doesn't set the right headers yet. Instead of waiting for a backend fix, add them at the proxy layer: proxelar -m reverse --target http://localhost:3000 --script security_headers.lua -p 4000</code></pre>-- security_headers.lua function on_response(request, response) response.headers["Strict-Transport-Security"] = "max-age=31536000; includeSubDomains" response.headers["X-Content-Type-Options"] = "nosniff" response.headers["X-Frame-Options"] = "DENY" response.headers["Content-Security-Policy"] = "default-src 'self'" response.headers["Referrer-Policy"] = "strict-origin-when-cross-origin" return response end</code></pre>$ curl -v http://localhost:4000/ < HTTP/1.1 200 OK < Strict-Transport-Security: max-age=31536000; includeSubDomains < X-Content-Type-Options: nosniff < X-Frame-Options: DENY < Content-Security-Policy: default-src 'self' < Referrer-Policy: strict-origin-when-cross-origin</code></pre> Point the security scanner at localhost:4000</code> and the headers are there. When the backend team ships the real implementation, remove the proxy and nothing changes. Faking Errors to Test Resilience</h3> You want to verify that your frontend handles server errors gracefully — timeouts, 500s, rate limits. Instead of breaking your actual backend, make the proxy return errors for specific endpoints: proxelar -m reverse --target http://localhost:3000 --script chaos.lua -p 4000</code></pre>-- chaos.lua -- Simulate failures on specific endpoints to test client error handling function on_request(request) -- Simulate a 500 on the payments endpoint if string.find(request.url, "/api/payments") then return { status = 500, headers = { ["Content-Type"] = "application/json" }, body = '{"error": "Internal Server Error", "message": "database connection timeout"}', } end -- Simulate rate limiting on search if string.find(request.url, "/api/search") then return { status = 429, headers = { ["Content-Type"] = "application/json", ["Retry-After"] = "30", }, body = '{"error": "Too Many Requests", "retry_after": 30}', } end end</code></pre>$ curl http://localhost:4000/api/payments {"error": "Internal Server Error", "message": "database connection timeout"} $ curl http://localhost:4000/api/search?q=test {"error": "Too Many Requests", "retry_after": 30} $ curl http://localhost:4000/api/users # passes through to the real backend normally</code></pre> Edit the script, restart the proxy, and you have a different failure scenario. No mocking libraries, no environment variables, no code changes in your application. API Response Patching</h3> Your backend returns a response that's almost right, but you need to tweak a field to unblock frontend work. Instead of modifying the backend or hardcoding values in the frontend, patch it at the proxy: proxelar -m reverse --target http://localhost:3000 --script patch_api.lua -p 4000</code></pre>-- patch_api.lua -- Patch specific fields in API responses without touching the backend function on_response(request, response) local ct = response.headers["content-type"] or "" if not string.find(ct, "application/json") then return end -- The backend doesn't return feature flags yet, but the frontend expects them if string.find(request.url, "/api/config") then if string.sub(response.body, 1, 1) == "{" then response.body = string.gsub(response.body, "}$", ',"feature_flags":{"new_dashboard":true,"dark_mode":true}}') end return response end -- Override the environment label so the frontend shows "staging" if string.find(request.url, "/api/health") then response.body = string.gsub(response.body, '"env":"development"', '"env":"staging"') return response end end</code></pre>$ curl http://localhost:4000/api/config {"version": "1.2.0", "feature_flags": {"new_dashboard": true, "dark_mode": true}} $ curl http://localhost:4000/api/health {"status": "ok", "env": "staging", "uptime": 3600}</code></pre> The backend returns the real data, and the proxy patches only what you need. When the backend catches up, delete the script. How It's Built</h2> The scripting engine lives in proxyapi/src/scripting.rs</code>, behind a scripting</code> feature flag. A single Lua VM is created at startup, loaded with the user's script, and shared across all connections via Arc<ScriptEngine></code>. The VM is protected by a std::sync::Mutex</code> — not a tokio mutex, since Lua calls are synchronous and complete in microseconds. The hooks are injected directly into the existing CapturingHandler</code>, which already handles body collection and event emission. The request hook runs in handle_request()</code> after the body is collected but before forwarding. The response hook runs in collect_and_emit()</code> before the event is emitted to the UI. This means zero changes to the forward or reverse proxy modules — scripting is entirely transparent to the rest of the proxy. Script errors are caught, logged, and the request passes through unchanged. A buggy script can never crash the proxy. Getting Started</h2> Update Proxelar: cargo install proxelar</code></pre> Run with a script: proxelar --script examples/scripts/block_domain.lua</code></pre> The repository includes 13 example scripts</a> covering header injection, domain blocking, API mocking, CORS fixes, traffic logging, HTML rewriting, cookie stripping, and more. Each one is a standalone file you can use directly or adapt. What's Next</h2> Scripting was the most important missing piece, but there's still a long road ahead. Here's what I'm working toward, roughly in priority order: Interactive intercept mode — pause matching requests in the TUI, edit headers and body on the fly, then forward. Real man-in-the-middle editing, not just observation.</li> Traffic replay — resend captured requests from the UI, or serve previously recorded responses as a mock server. Essential for testing and debugging.</li> Save / load / export — persist captured sessions to disk. Export to HAR, curl commands, or raw HTTP. No more losing everything on shutdown.</li> HTTP/2 interception — full MITM for HTTP/2 connections instead of falling through to raw TCP tunneling.</li> WebSocket inspection — decode and display individual WebSocket frames with message-level granularity.</li> Content views — auto-detect and prettify JSON, XML, HTML, Protobuf, form data with syntax highlighting across all interfaces.</li> </ul> The full changelog is available on GitHub</a>. Cove 0.1.0: Six New Backends, Tabs, and Environments Unknown — Sun, 22 Mar 2026 00:00:00 +0000 I'm releasing Cove 0.1.0</a>, bringing the total number of supported databases from three to nine. MySQL, MariaDB, SQLite, MongoDB, Cassandra, and Elasticsearch join the original PostgreSQL, ScyllaDB, and Redis backends. This release also adds multiple tabs, connection environments, and encrypted credential storage. The DatabaseBackend</code> protocol from 0.0.0</a> made this straightforward — six new backends, roughly 5,000 new lines of Swift, zero changes to the UI layer. From Three to Nine</h2> The six new backends cover the databases I kept reaching for after the initial release: MySQL and MariaDB connect via mysql-nio</a> and mysql-kit</a>. Both support multi-database browsing — the hierarchy shows all databases on the server, each with its own tables, views, indexes, and triggers. MariaDB shares the wire protocol but gets its own backend with MariaDB-specific keywords and behavior. TLS fallback is handled automatically. SQLite is the only backend that doesn't need a server. Point it at a .db</code> file and Cove opens it directly, no configuration beyond the file path. It uses the system SQLite library through a lightweight Swift wrapper — no external dependencies. The hierarchy maps tables, views, indexes, and triggers from the sqlite_master</code> table. MongoDB speaks the MongoDB wire protocol via MongoSwift</a>. Instead of SQL, the query editor accepts shell-style commands (find</code>, insertOne</code>, aggregate</code>). Since MongoDB is schemaless, Cove samples documents from each collection and builds a merged column set to display in the data table. The hierarchy lists databases, collections, and inferred fields. Cassandra reuses the same swift-cassandra-client</a> driver as ScyllaDB but with its own keyword set and hierarchy tuned for Cassandra's replication model. If you already had ScyllaDB working, Cassandra is essentially free — the CQL protocol is the same, but keeping them separate means the autocomplete and highlighter are accurate for each. Elasticsearch operates differently from the other backends — no SQL, no tables, just indexes and REST-style queries. The query editor accepts JSON bodies that get sent as Elasticsearch search requests. The hierarchy discovers indexes and maps their field mappings into the familiar tree structure. It connects over HTTP via async-http-client</a>, so it works with any Elasticsearch-compatible API including OpenSearch. The DatabaseBackend</code> protocol didn't need a single change to accommodate any of these. Each backend implements the same ~20 methods — hierarchy browsing, data fetching, query execution, inline editing, SQL/command generation, and autocomplete keywords — and the UI treats them all identically. Multiple Tabs</h2> Cove now supports multiple independent tabs, each with its own connection, query editor, and data view. Cmd+T opens a new tab, Cmd+W closes the current one. Each tab maintains its own session state — the selected tree node, the query text, pagination position — so switching between tabs picks up exactly where you left off. Sessions are persisted per tab across app relaunches. Close Cove with three tabs open, relaunch it, and all three restore their previous state including the active connection and last query. Connection Environments</h2> Every connection is now tagged with an environment: Production, Staging, Development, or Local. The toolbar displays a colored indicator matching the active environment, so there's a constant visual reminder of where you're pointing. You can filter the connection rail by environment to keep things uncluttered. When switching between a local database and a production replica throughout the day, the colored indicator catches mistakes before they happen. Encrypted Credential Storage</h2> Passwords are no longer stored alongside connection configurations. Database passwords, SSH passwords, and SSH key passphrases are encrypted with AES-256-GCM via CryptoKit and stored in a separate .secrets</code> file. The symmetric key is generated once and saved with restricted permissions (0600</code>). The JSON config files in ~/Library/Application Support/Cove/</code> contain only non-sensitive fields. Bug Fixes</h2> Notable fixes in this release: TLS for PostgreSQL — cloud-hosted databases (Supabase, Neon, RDS) now connect properly. The TLS configuration was missing in 0.0.0, which meant only unencrypted local connections worked.</li> Completion engine cursor boundary — an off-by-one error caused the autocomplete to suggest completions one character too late in certain positions.</li> SSH tunnel assignment — fixed a race condition in the tunnel setup that could leave the connection in a half-initialized state.</li> </ul> Getting Started</h2> Download the DMG or ZIP from the GitHub release</a>, or build from source: git clone https://github.com/emanuele-em/cove.git cd cove xcodebuild -scheme Cove -derivedDataPath .build build open .build/Build/Products/Debug/Cove.app</code></pre> Requires macOS 15 (Sequoia) or later. What's Next</h2> Planned for upcoming releases: More database backends</li> Import/export (CSV, JSON, SQL dump)</li> Query history panel</li> Data filtering and search</li> Query explain/analyze visualization</li> SSL/TLS certificate configuration for all backends</li> </ul> Feedback and contributions are welcome on GitHub</a>. Cove: A Native macOS Database Client Unknown — Sun, 15 Mar 2026 00:00:00 +0000 I'm releasing Cove 0.0.0</a>, a native macOS database client built entirely in Swift and SwiftUI. It supports PostgreSQL, ScyllaDB, and Redis out of the box, with a pluggable architecture that makes adding new backends straightforward. No Electron, no web views — just a fast, lightweight, native app. Most database clients are either Electron apps that eat memory for breakfast, or legacy native apps that haven't been updated in years. DBeaver ships a new release every two weeks, which I find oddly comforting given that the experience has remained identical since 2013. I wanted something that feels like a proper macOS citizen — fast startup, native controls, Keychain integration — while supporting the databases I actually use. Let's walk through what's in this release. The DatabaseBackend Protocol</h2> I built Cove with contributions in mind from the start. Not just human contributors — LLMs too. The architecture had to be obvious enough that someone opening the project for the first time could add a new database backend without reading the entire codebase, and structured enough that an LLM could do the same given the right context. The result is a single Swift protocol — DatabaseBackend</code> — that every database driver implements. The protocol defines around 20 methods covering hierarchy browsing, data fetching, query execution, inline editing, SQL generation, and autocomplete. The UI code never checks which backend is active. Browsing a Redis instance feels the same as browsing a Postgres database: same tree navigation, same editing workflow, same query interface. Each backend is split into five focused files following a consistent pattern: Cove/DB/Postgres/ ├── PostgresBackend.swift # connection, keywords, pooling ├── PostgresHierarchy.swift # schema → table → column tree ├── PostgresDataOps.swift # fetchTableData, executeQuery ├── PostgresSQLGen.swift # UPDATE/INSERT/DELETE generation └── PostgresDecoders.swift # QueryResult parsing</code></pre> ScyllaDB and Redis follow the same structure. Adding a new backend — say, MySQL or MongoDB — means creating a new folder, implementing the protocol, and adding a case to the BackendType</code> enum. Zero UI changes required. A human can follow the pattern by looking at any existing backend. An LLM can do it with just the protocol definition and one example. That was the whole point. Three Backends (For Now)</h2> The first three backends are the databases I actually use every day at work. I built what I needed first. PostgreSQL connects via postgres-nio</a> with full SQL support, TLS connections, and per-database connection pooling. The keyword set covers DDL, DML, joins, window functions, and Postgres-specific types like JSONB</code> and UUID</code>. Client instances are cached per database with NSLock</code> for thread safety, so switching between databases in the same connection doesn't re-establish the link. ScyllaDB uses swift-cassandra-client</a> and speaks the native Cassandra protocol. CQL keywords power the syntax highlighter and autocomplete engine. The hierarchy maps keyspaces to tables to columns, matching ScyllaDB's data model. Redis is the odd one out — it's a key-value store, not a relational database. The backend organizes keys by data type (strings, hashes, lists, sets, sorted sets, streams) and presents them in the same tree structure. The query editor accepts Redis commands directly. Connection pooling is handled via NIO's EventLoopGroup</code>. The obvious ones are next. In the upcoming patch versions I plan to add MySQL, SQLite, MongoDB, MariaDB, and Cassandra support. The protocol-based architecture was designed exactly for this — each new backend is an afternoon of work — or a couple of hours with an LLM. Inline Editing with SQL Preview</h2> Cove wraps AppKit's NSTableView</code> in SwiftUI for native table performance and familiar macOS behavior — column resizing, sorting by header click, keyboard navigation with arrow keys. But the interesting part is inline editing. Click any cell to edit it. The cell turns orange to indicate a pending change. New rows show a green background, deleted rows turn red. None of these changes hit the database immediately. Instead, pressing Cmd+S opens a SQL preview sheet showing the exact UPDATE</code>, INSERT</code>, or DELETE</code> statements that will be executed. Only after confirmation do the changes commit. This gives full visibility into what's about to happen, which matters especially when pointing at a production database. Keyboard shortcuts cover the common operations: Cmd+C to copy a cell, Cmd+R to refresh, Tab/Shift+Tab to navigate between cells, Escape to discard edits, Return to commit. Pagination is configurable at 50, 100, or 500 rows per page. Query Editor with Syntax Highlighting and Autocomplete</h2> The query editor is built on NSTextView</code> with a custom tokenizer that colorizes SQL in real time. The tokenizer is a hand-written lexer that processes UTF-16 codepoints and recognizes keywords, string literals, numbers, single-line comments (--</code>), and block comments (/* ... */</code>). Each backend provides its own keyword set, so the highlighter adapts automatically — SQL keywords for Postgres, CQL keywords for ScyllaDB. Autocomplete is context-aware. The CompletionEngine</code> analyzes the cursor position and offers different suggestions depending on where you are in a query: After FROM</code> or JOIN</code> — table names</li> After WHERE</code> or in expressions — column names and functions</li> After a dot — columns of the referenced table or alias</li> </ul> The engine resolves aliases too. If you write FROM users u JOIN orders o</code>, then typing u.</code> completes with columns from the users</code> table. It handles comma-separated FROM clauses, all JOIN types, and basic subqueries. Suggestions pop up after a 100ms debounce, capped at 50 items, and you can navigate them with arrow keys or Tab to insert. The Runnable Range Indicator</h2> This is the feature I've wanted in every database client I've ever used, and none of them have it. When you have multiple SQL statements in the editor, a thin blue bar appears on the left margin highlighting the statement the cursor is currently inside. That's it. You always know exactly which query will run when you hit the execute button. No selecting text, no hoping you got the right semicolon boundary, no accidentally running a DROP</code> when you meant to run the SELECT</code> above it. Move the cursor to a different statement, and the bar follows. It sounds trivial, but after years of writing multi-statement scripts in database clients and second-guessing which statement is about to fire, this small piece of visual feedback changes the entire experience. I'm genuinely surprised no one else has done this. SSH Tunneling</h2> Connecting to databases behind firewalls is a first-class feature. Cove's SSH tunnel implementation uses Swift NIO's NIOSSH library with support for both password and private key authentication. For private keys, the loader handles multiple formats: OpenSSH, PEM (PKCS#8 and SEC1), and modern curves including Ed25519, P-256, P-384, and P-521. Encrypted keys are supported too — Cove detects the encryption, prompts for the passphrase, and decrypts via the system's ssh-keygen</code>. Error messages distinguish between wrong passphrases and unsupported key formats. The tunnel establishes a local TCP server on an auto-selected port, then bridges traffic bidirectionally between the local socket and the remote SSH channel using custom NIO ChannelDuplexHandler</code>s. A 10-second connection timeout prevents indefinite hangs, and a test channel verifies authentication before reporting success. Connection Management and Environments</h2> The connection rail — a vertical sidebar on the far left — shows all saved connections as color-coded pills. Each connection is tagged with an environment: Production, Staging, Development, or Local. The toolbar displays a colored dot matching the active environment, so there's always a visual reminder of where you're pointing. You can filter connections by environment via the toolbar picker. Connection details (name, backend, host, port, database, SSH configuration) are stored as JSON in ~/Library/Application Support/Cove/</code>. Passwords are excluded from the JSON entirely — they're stored in the macOS Keychain under the com.cove.app</code> service, bound to the user's login keychain via kSecUseDataProtectionKeychain</code>. Three credentials per connection are handled separately: database password, SSH password, and SSH key passphrase. There's also an automatic migration path: if Cove detects an older config file with plaintext passwords, it moves them to the Keychain and re-saves the JSON without credentials. Architecture</h2> The codebase is organized into four layers: DB — the DatabaseBackend</code> protocol, three backend implementations (15 files), SSH tunneling, connection configuration, and the autocomplete engine</li> State — @Observable</code> classes for app state, tree navigation, table display, query editor, and dialogs. Uses Swift 6's @Observable</code> macro for fine-grained reactivity without @Published</code> boilerplate</li> Store — JSON persistence with Keychain integration, session persistence per tab, saved queries per connection, and automatic migration from legacy formats</li> Views — 13 SwiftUI views covering the full interface: connection rail, sidebar tree, data table, row inspector, query editor with autocomplete popup, SQL preview sheet, and connection dialog</li> </ul> The whole thing is written in Swift 6 with structured concurrency, targeting macOS 15+. About 9,000 lines of Swift across 49 files, with a self-imposed ~300 line limit per file. Everything runs on @MainActor</code> with async/await — no blocking the UI thread. Getting Started</h2> Clone and build with Xcode: git clone https://github.com/emanuele-em/cove.git cd cove xcodebuild -scheme Cove -derivedDataPath .build build</code></pre> Or just open Cove.xcodeproj</code> in Xcode and hit Run. Requires macOS 15 (Sequoia) or later. What's Next</h2> This is an early release. The core browsing, editing, and query workflow is solid, but there's more to come: Import/export (CSV, JSON, SQL)</li> Multiple query tabs</li> Data filtering and search</li> Query history panel</li> SSL/TLS certificate configuration for all backends</li> Query explain/analyze visualization</li> </ul> Feedback and contributions are welcome on GitHub</a>. P.S. — Some of the screenshots show UI elements from future releases. I took them during development and didn't bother retaking them for the v0.0.0 announcement. Consider it a spoiler. Proxelar 0.2.0: A Complete Rewrite Unknown — Sat, 21 Feb 2026 00:00:00 +0000 I'm happy to release Proxelar 0.2.0</a>, a major milestone that completely reimagines the project from the ground up. What started as a Tauri desktop application is now a lean, modular CLI tool with three interface modes, a new proxy engine built on hyper 1.x, and both forward and reverse proxy support. This release touches virtually every part of the codebase — 96 commits spanning architecture, networking, TLS, CI/CD, and testing. Having Claude Opus 4.6</a> as a pair-programming partner made tackling a rewrite of this scale much more manageable. Let's walk through what's new. New Architecture: Three Crates, Three Interfaces</h2> The single Tauri application has been replaced with a clean 3-crate workspace: proxelar-cli</code> — the CLI binary, providing the entry point and interface layer</li> proxyapi</code> — the core proxy engine with the HttpHandler</code> trait, connection handling, and TLS interception</li> proxyapi_models</code> — shared request/response models and serialization</li> </ul> This separation makes the proxy engine reusable as a library, independent of any specific frontend. On the interface side, Proxelar now ships with three modes you can switch between at launch: proxelar # interactive TUI (default) proxelar -i terminal # plain terminal output proxelar -i gui # web GUI at localhost:8081</code></pre> The TUI is built with ratatui</a> and supports navigation, request/response inspection, filtering, and keyboard shortcuts. The web GUI runs on axum</a> with WebSocket streaming. All three interfaces are fed by a unified event pipeline — a bounded mpsc</code> channel of ProxyEvent</code> values — so they all see the same traffic in real time. Hyper 1.x and Modern TLS</h2> The core proxy engine has been migrated from hyper 0.14 to hyper 1.x, along with rustls 0.23 and tokio-rustls 0.26. This meant rewriting connection handling, body types (ProxyBody</code>), and the entire TLS interception layer. The new stack brings better performance, improved HTTP compliance, and alignment with the current Rust async ecosystem. Certificate generation now uses per-host caching, so repeated connections to the same host reuse previously minted certificates instead of generating new ones on every request. Forward and Reverse Proxy</h2> Proxelar 0.2.0 introduces proper forward proxy mode with CONNECT tunneling and HTTPS man-in-the-middle interception, as well as a new reverse proxy mode: # Forward proxy (default) — configure your system proxy to 127.0.0.1:8080 proxelar # Reverse proxy — forward all traffic to an upstream target proxelar -m reverse --target http://localhost:3000</code></pre> Forward mode handles both HTTP and HTTPS via CONNECT, transparently intercepting encrypted traffic by minting per-host certificates signed by the local CA. Reverse mode rewrites incoming requests to the specified upstream target — useful for debugging APIs and local services. Easy CA Certificate Installation</h2> Getting the CA certificate installed is often the most annoying part of setting up a MITM proxy. Proxelar now includes a built-in certificate download server that intercepts requests to the proxel.ar</code> hostname. Just configure your browser to use the proxy and visit: http://proxel.ar</code></pre> You'll get a page with direct PEM and DER downloads and installation instructions for your platform. No more hunting for certificate files in hidden directories (though ~/.proxelar/proxelar-ca.pem</code> is still there if you prefer). Testing and CI/CD</h2> This release adds integration tests covering the certificate authority, the cert download server, forward proxy, reverse proxy, and model serialization. Previously, the project had minimal test coverage — now the critical paths are exercised automatically. The CI/CD pipeline has been overhauled as well: Cargo caching for faster builds</li> MSRV 1.88 verification to ensure compatibility</li> cargo-deny policy checks for license and vulnerability auditing</li> Cross-platform release workflow producing binaries for multiple targets</li> Dependabot for automated dependency updates</li> </ul> Breaking Changes</h2> This is a major release, and the public API has changed significantly: The binary is now proxelar</code> (CLI) — the Tauri desktop app has been removed entirely </li> proxyapi</code> has been redesigned around the HttpHandler</code> trait, ProxyBody</code>, and ProxyEvent</code> </li> proxyapi_models</code> now uses http 1.x and http-serde 2.x, which changes the serialization format </li> License changed to MIT-only — the previous dual license has been simplified </li> </ul> If you were using proxyapi</code> as a library, you'll need to update your code to the new API. Getting Started</h2> Install Proxelar with Cargo: cargo install proxelar</code></pre> Then run it: proxelar</code></pre> Configure your system or browser proxy to 127.0.0.1:8080</code>, visit http://proxel.ar</code> to install the CA certificate, and you're ready to inspect traffic. For all CLI options, check the README</a> or run proxelar --help</code>. Acknowledgments</h2> Proxelar is heavily inspired by mitmproxy</a>, a project I had the opportunity to contribute to. Working on mitmproxy gave me a deep understanding of how MITM proxies work and shaped many of the design decisions behind Proxelar. The full changelog is available on GitHub</a>.

Web GUI</h2>
The web GUI gets the same capabilities with a point-and-click interface.</p>

Catching and Blocking Specific Requests</h3>
Sometimes you want to know what happens when a request doesn't go through. Drop a specific request mid-session — the client gets a 504, and you observe how it handles the failure without shutting anything down.</p>

Proxelar 0.3.0: Lua Scripting for HTTP Traffic

Cove 0.1.0: Six New Backends, Tabs, and Environments

Cove: A Native macOS Database Client

Proxelar 0.2.0: A Complete Rewrite

Emanuele Micheletti

Proxelar 0.5.0: Sessions, Rules, and More Ways to Capture Traffic

Cove 0.2.0: Agent Mode Without Settings

Proxelar 0.4.2: WebSocket Inspection and Smarter Filtering

Proxelar 0.4.0: Intercept & Modify Traffic

Emanuele Micheletti

Proxelar 0.5.0: Sessions, Rules, and More Ways to Capture Traffic

Cove 0.2.0: Agent Mode Without Settings

Proxelar 0.4.2: WebSocket Inspection and Smarter Filtering

Proxelar 0.4.0: Intercept & Modify Traffic

Web GUI</h2> The web GUI gets the same capabilities with a point-and-click interface.</p>

Catching and Blocking Specific Requests</h3> Sometimes you want to know what happens when a request doesn't go through. Drop a specific request mid-session — the client gets a 504, and you observe how it handles the failure without shutting anything down.</p>

Proxelar 0.3.0: Lua Scripting for HTTP Traffic

Why Lua</h2> Scripting is the feature that turns a proxy from a debugging tool into a development platform. For a Rust project, I wanted a scripting language that could be embedded with zero system dependencies</strong>.</p>

Real Examples</h2> Let me walk through a few practical scenarios. Each one is a complete, working script.</p> Blocking Domains</h3> The simplest use case: prevent requests from reaching certain hosts.</p>

Blocking Domains</h3> The simplest use case: prevent requests from reaching certain hosts.</p>

Injecting Headers</h3> Need to test how your app behaves with specific headers? Inject them on every request:</p>

Cove 0.1.0: Six New Backends, Tabs, and Environments

What's Next</h2> Planned for upcoming releases:</p>

Cove: A Native macOS Database Client

Proxelar 0.2.0: A Complete Rewrite

Web GUI</h2>
The web GUI gets the same capabilities with a point-and-click interface.</p>

Catching and Blocking Specific Requests</h3>
Sometimes you want to know what happens when a request doesn't go through. Drop a specific request mid-session — the client gets a 504, and you observe how it handles the failure without shutting anything down.</p>