## Optionally with sanitized production data

I'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 preview environments from your `docker-compose.yml`, (optionally) complete with a sanitized snapshot of your production database.

## What happens when you open PR #247

1. GitHub webhook hits our API

2. We pull your branch and parse your compose file

3. Kubernetes manifests render from your compose services (and applied to our cluster)

4. A fresh namespace gets created with your containers

5. Optionally, postgres containers are seeded with your data

6. Health checks pass, you get a stable URL: `https://.env.veilstreamapp.com`

7. that link is commented back on any open PRs from that branch

Total time from push to working environment: about 2 minutes.

### The reviewer experience

Your teammate clicks the link. They're using your app with real data structure, real relationships, real edge cases—but emails are fake, SSNs are masked, and PII never leaves your production boundary.

No shared staging. No "wait, who's testing on staging right now?" No stepping on each other's test data. No risk to prod.

### When PR #247 gets merged or closed

The namespace, containers, and database are automatically destroyed. Nothing lingers.

## What it's not

- Not serverless/edge - this is for apps that run containers

- Not a Vercel competitor - we're focused on the full stack from a docker-compose perspective

- Not a database replication tool - the proxy works like a man-in-the-middle, not on the WAL

## MCP Server for AI Agents

We built an MCP server so Claude Code, Cursor, and other AI coding agents can deploy preview environments directly. Your agent can spin up an environment, run tests against it, and tear it down—all without leaving your editor.

## Tech Stack

- Backend: Go (API + reconciler)

- Frontend: React + TypeScript

- Infrastructure: Kubernetes, with dynamic namespace provisioning

- Database proxy: Custom Go proxy that interfaces with a database, and exposes the standard psql wire protocol, mimicing a server

## Links

- Landing page: https://www.veilstream.com

- Application: https://app.veilstream.com

- Example project: https://github.com/veilstream/example-music-company

- Demo video: https://www.linkedin.com/posts/jonessteven_i-have-only-made-...

- Docs: https://docs.veilstream.com

Happy to answer questions.

Also: htaccess-style password protection is available for your preview environments.

Comments URL: https://news.ycombinator.com/item?id=46874014

Points: 6

# Comments: 0

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.

The use cases we're trying to solve are:

- Production-like data in development environments

- Improve incident handling by masking all data that is not relevant

- Share a subset of your data

- Protecting data being shipped into a data lake

- Safe data to expose in internal tooling, metrics, or BI dashboards

- Empower non-technical staff to vibe-code against sanitized data

# How it fits in your stack

- Role based policies: define masking rules in our web dashboard

- The proxy picks up the configuration and starts applying rules automatically.

## You host it

- it's a docker container, two environment variables: an api key, and the database URI connection

## We host it

- Drop-in proxy: no code changes. Point your connection string at a new endpoint, that's it.

# How it works (and how fast it is)

Restructuring the query AST based on the config. AST rewrites depend on the text/structure of the query, not on how many rows the database eventually returns, so they are effectively O(1) with respect to result size.

# Status & feedback wanted

VeilStream is GA, but billing isn’t switched on yet so it's currently free at all tiers. We’d love your thoughts on:

- throughput / latency in real workloads

- Filter rules & DevX

- weird edge-case queries (pg_dump, logical replication, etc.)

I’ll be around all day to answer questions and dig into issues.

# tagline

Ship features with data you can trust and privacy you don't have to worry about.

Comments URL: https://news.ycombinator.com/item?id=44310026

Points: 22

# Comments: 12