# Show HN: VeilStream - Per-Branch Preview Environments## Optionally with sanitized production dataI've been building VeilStream to solve a problem I kept running into: Rigorous evaluation of changes, such that they won't break production is hard. Staging is shared and often broken. Pulling to local setups are a pain. So PRs get a quick code skim and a "LGTM." VeilStream spins up isolated...
we were considering allowing the user to inject stored procedures themselves, and then use those, but currently, we're opting to implemented them ourselves, so we have better control over the user experience. In the future, for very custom stored procedures, I think we may allow the custom path.
A future improvement to that: currently the conditions are all ANDed together, I'd like to support more types of boolean logic in the future. :)
- uuids: no, but I should. adding to my list :)
- ip addresses: yes ip4 and ip6, but I want to go further and let you configure the replacement ips to be within specified cidr blocks
- arrays: again, not yet. Do you mind if I ask the use case? Arrays are commonly done as single rows and foreign keys/look ups, which we can do.
We've internally got the path for adding new filter types (dashboard configuration, api layer storage, and proxy rule implementation) pretty optimized. it takes us a day or two to add simple requested filters. longer for more complex ones.
We do not do connection pooling yet. currently it's a fresh connection per query (which adds a bit of latency). We're intending to add basic connection pooling shortly after launch. That said, if you put it in-front of pgbouncer, that would work well.
PostGIS and other extensions are on the radar, but currently are not supported. The proxy works with the extensions, but can't mask the data yet. If we get requests for specific extensions to be fully supported, we'll implement (same with extra masking data types). I look forward to the GIS data implementation, as I've met one of the postGIS contributors and have discussed several of those masking complexities.
# TL;DR We built VeilStream, a drop-in, read-only PostgreSQL proxy that strips, masks, or anonymizes sensitive values as queries stream through. In less than two minutes, you can put a proxy in front of a PostgreSQL database, whether hosted on your laptop, Neon, Supabase, or a cloud provider, and the user is able to start configuring filter rules.The use cases we're trying to solve are:-...