public digest · 5 picks
Proxies, pipelines, and one very legally gray Android toolkit
Infrastructure week, mostly. Envoy and Apache APISIX both want to be your gateway layer but come at it from opposite philosophies — one is a C++ config-protocol standard, the other is Lua-on-nginx with a plugin count that borders on absurd. Woodpecker and Flagsmith round things out with the less glamorous but more immediately useful stuff: self-hosted CI and self-hosted feature flags, both mature enough to run in production without crossing your fingers.
Then there's hooker, which is exactly what it says on the tin — a Frida CLI for tearing into Android apps — and doesn't pretend to be anything else. It's the odd one out this week, and worth reading about even if you never touch it.
// pick 1 of 5
hooker is a Frida-based CLI toolkit for Android reverse engineering that wraps common tasks - SSL unpinning, script generation, memory/activity roaming, SOCKS5 proxying, and an injectable HTTP server - into a single interactive shell. It's aimed at people doing app traffic analysis, protocol reverse engineering, or crawler/API extraction work on rooted Android devices, not general mobile security researchers looking for a polished framework.
The gs command alone justifies a look: it generates real, usable Frida hook scripts with stack traces and overload-matching call-through wrappers, which is normally the most tedious part of writing Frida hooks by hand. The bigger idea, though, is the embedded webserver — annotation-based routing that turns an app's internal Java methods into HTTP endpoints. That's a genuinely clever shortcut around manual JNI/reflection work for anyone doing API extraction.
It bundles frida-server, r0capture, iptables-based SOCKS5 proxying, and SSL unpinning tools into one shell, which saves the usual tool-juggling reverse engineers do manually.
What to know going in: documentation is almost entirely Chinese, and the examples center on apps like Taobao and Douyin, so non-Chinese speakers will be translating as they go. The repo ships compiled binaries directly rather than fetching them — no checksums, no signing story — for a tool that needs root. It's pinned to a specific Frida version, updates via frequent git pulls, and the legal risk of bypassing app protections is real and explicitly not the project's problem to own. Go in eyes open.
View on GitHub → Our full take →
// pick 2 of 5
Woodpecker is a self-hosted CI/CD engine, forked from Drone before Drone's license change, aimed at teams wanting a lightweight self-hosted pipeline runner integrated with Gitea, Forgejo, GitHub, GitLab and Bitbucket. It's a good fit for people who want a straightforward YAML-based pipeline system without the operational weight of Jenkins or the vendor lock of hosted CI.
If you want self-hosted CI without the operational weight of Jenkins or vendor lock to a hosted service, Woodpecker is a solid answer. It supports Docker, Kubernetes, local, and custom execution backends, which means you're not stuck with one runtime model. The footprint is genuinely light — around 100MB for the server, 30MB for an agent — and forge support (Gitea, Forgejo, GitHub, GitLab, Bitbucket) is actually maintained rather than half-stubbed.
What to know going in: docs are scattered across a lot of small numbered markdown files, so expect to piece together the full picture rather than read one guide start to finish. The YAML pipeline syntax is Woodpecker's own, so migrating existing GitHub Actions or GitLab CI configs takes real rewrite work, not a find-and-replace. It's a Drone fork, and some of Drone's original rough edges around matrix builds and multi-forge quirks are still in there. The Kubernetes backend also reads as less battle-tested than the Docker one — worth testing thoroughly before betting production on it.
View on GitHub → Our full take →
// pick 3 of 5
Apache APISIX is a mature, high-performance API gateway built on NGINX/OpenResty and etcd, with a huge plugin ecosystem covering auth, traffic control, observability, and now LLM/AI proxying. It's aimed at platform/infra teams running microservices or Kubernetes ingress who need a dynamic gateway that doesn't require reloads to change config.
APISIX's biggest selling point is real dynamic configuration — routes and plugins hot-reload through etcd with zero restarts, which matters a lot once you're running this in front of live traffic. The plugin ecosystem is enormous and actually useful: multiple auth schemes, several logging backends, multi-language plugin runners for Java/Go/Python, and Wasm support. The newer AI proxy code is a real feature, not a label slap — it's doing genuine protocol conversion across Anthropic, Bedrock, and OpenAI-compatible APIs.
Apache governance means a slower, steadier release cadence, which is a feature if you've been burned by single-maintainer projects disappearing.
What to know going in: it's Lua on OpenResty, so debugging or extending plugins means understanding LuaJIT and nginx internals — a steeper curve than a Go-based gateway. etcd is a hard dependency even for small deployments, which is one more stateful service to run and babysit. The plugin directory is sprawling (100+ files), and it's not obvious which plugins are production-hardened versus recently added — especially the AI ones. Threat-modeling gets harder too, since APISIX supports so many protocols (MQTT, Dubbo, gRPC transcoding) that you likely won't need.
View on GitHub → Our full take →
// pick 4 of 5
Envoy is the CNCF proxy that underpins most modern service mesh and API gateway stacks (Istio, Ambassador, Gloo, etc.), handling L3-L7 traffic with a config-driven, extensible filter model. It's for infra engineers building service meshes, edge proxies, or anyone needing a proxy with deep observability and dynamic config via xDS.
Envoy's xDS API and dynamic config model has become the de facto standard well beyond Envoy itself — if you've touched a service mesh, you've indirectly touched this design. The extension surface is huge: Kafka, Postgres, MySQL filters, Golang and Lua extension points, even hardware crypto offload via QAT, so you rarely need to fork the proxy to add protocol support. The observability and hot-restart architecture is proven at Lyft, Google, and Airbnb scale, and the fuzzing infrastructure plus third-party security audits show real hardening investment, not just a README claim.
What to know going in: the Bazel-based C++ build is heavy and slow to get running locally — the dev loop isn't friendly for casual contributors, regardless of what the README says. The config surface (protos, filter chains, xDS resources) is enormous, and writing or debugging configs has a real learning curve. Small thing, but the repo's GitHub topics include junk tags like cars, cats, and corgis — cosmetic, but a decent signal to check when the repo metadata was last actually cleaned up.
View on GitHub → Our full take →
// pick 5 of 5
Flagsmith is a self-hostable feature flag and remote config service with a Django API, React admin dashboard, and SDKs for 15+ languages. Targets teams that want feature flags/A/B testing without vendor lock-in or want to run it on their own infra.
Flagsmith handles the production concerns that a lot of feature-flag tools hand-wave: Postgres, ClickHouse and InfluxDB backends for analytics at different scale tiers, an edge API for identity-based flag evaluation, MFA/oauth, and a migration history that goes back years. The CI setup — separate pipelines for api, frontend, docs, and mcp, ECS deploys, trivy scanning — is a strong signal this runs somewhere real, not just in a demo. Docker-compose gets you a working instance in one command, which is a good way to kick the tires fast.
What to know going in: this is open-core, not fully open source — the governance and RBAC features you'd want at enterprise scale are gated behind a paid license, so read the licensing fine print before building infra around it. The Django API codebase is large and sprawling across dozens of apps, so onboarding a contributor or doing a real audit takes time. And that one-command demo undersells what production self-hosting actually requires — Postgres, Redis, and likely ClickHouse or Influx on top.
View on GitHub → Our full take →
That's five. If you want these in your inbox before we post them here, the email signup is at the bottom of the page — no spam, just the picks.
Get this in your inbox →