Upload a PDF, draw rectangles over what you want removed, download. Free, no account, 5 languages including Arabic RTL.

https://mypdfboy.com

Built with React + FastAPI + PyMuPDF. Would love feedback on the UX.

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

Points: 3

# Comments: 0

  I scanned all 58 official AWS Terraform modules. Here's what I found.

  terraform-aws-modules is the gold standard. 30k+ GitHub stars on the VPC module alone. Used by thousands of teams in production.

  I pointed MonPhare at the entire org:

    monphare scan --github terraform-aws-modules

    45 seconds later: 58 repos scanned, 2,315 files parsed, 3 errors, 692 warnings.


  Even the best-maintained modules in the ecosystem have constraint hygiene gaps -- missing pins, no upper bounds, unbounded providers that welcome breaking changes on any terraform init.

  Now imagine your own infrastructure. Dozens of repos, hundreds of modules, multiple teams pushing changes. Who's checking that a provider upgrade won't break prod on Monday morning?

  That's what MonPhare does.

  One command to audit version constraints across your entire Terraform/OpenTofu state:

  - Scan a local directory, a remote repo, or an entire GitHub/GitLab/Azure DevOps/Bitbucket org
  - Detect missing constraints, unbounded versions, wildcard pins, deprecated modules, and cross-repo conflicts
  - Generate dependency graphs in DOT, Mermaid, or JSON -- see exactly what depends on what
  - Output as formatted CLI tables, machine-readable JSON, or self-contained HTML reports
  - Drop --strict into your CI pipeline -- warnings become blocking errors, nothing slips through
  - Define policies in monphare.yaml -- deprecation lists, required upper bounds, exclusion patterns -- and enforce them across every
  repo

  Written in Rust. Parallel scanning. Shallow clones with local caching. An entire GitHub org in under a minute.

  Open source: https://github.com/tanguc/monphare

"npm install" your secrets like any other dependency.

Vaults = source of truth Git = distribution layer OneSeal: make the bridge between them

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

Points: 2

# Comments: 1

- Terraform or Pulumi outputs → Vault/KMS → CI replaces values in YAML → K8s secrets operator injects env vars → app starts → DATABASE_PASSWORD typo, chaos ensues.

- Copy-pasted creds from Slack or Teams.

- Secrets/configs left in plaintext files or repos.

- Password managers with outdated entries that no one really trusts.

As a developer, what frustrates me most is the lack of predictability. Between Terraform, Vaults, pipelines, and operators, it’s often unclear who “owns” the truth — and every layer can quietly introduce drift.

So I’m curious:

- How are you handling that handoff today? - Are you still pushing everything through Vault + env vars, or have you built something cleaner? - What has actually worked for you in production — and what’s bitten you later?

Would love to hear some real war stories or simple patterns that actually hold up over time.

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

Points: 2

# Comments: 0

I built Oneseal: a small CLI that turns platform outputs (Terraform state, etc.) into a typed, versioned SDK you can install and import. The goal is to make consumption predictable and diffable, not to replace your vault.

What it does - Reads outputs (secrets, URLs, flags, IDs, connection strings)

- Generates a package (TypeScript today) with types + multi-env selection

- Deterministic artifacts, safe to commit or publish to your internal registry.

If this solves your env-drift pain, tell me where it breaks in your stack !

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

Points: 4

# Comments: 0