Great writeup on offline OSM routing! If you're also interested in simulating vehicle movement on those road networks — useful for testing tracking or logistics software — Moveet (https://github.com/ivannovazzi/moveet) does exactly that: A* pathfinding on GeoJSON road graphs with WebSocket streaming of real-time positions. It uses the same OSM data you'd be pre-processing here.
Readit Newsivannovazzi commented on An offline map using OruxMaps(satellite,routing,3D terrain,GPS and POI) · Posted by u/supergoogler
ivannovazzi commented on Show HN: EV range calculator – range circles and charger map (700 models) · Posted by u/sthorat
Neat project! For anyone building or testing EV fleet management software who needs realistic vehicle movement data, Moveet (https://github.com/ivannovazzi/moveet) might be useful — it's an open-source simulator that drives synthetic vehicles along real OSM road networks using A* pathfinding, streaming GPS positions over WebSocket. It supports Kafka and REST sinks so you can feed position data straight into whatever backend you're testing.
ivannovazzi commented on Show HN: TerraViz – Real-time flights, earthquakes, ISS on one map terraviz.live/... · Posted by u/cvaambikapur
Cool project! The OSM vehicle interpolation along way geometries is a nice touch. If you want to push further into realistic vehicle routing — where vehicles actually navigate junctions and follow shortest paths — Moveet (https://github.com/ivannovazzi/moveet) might be a useful reference. It's an open-source fleet simulator I built that runs A* pathfinding on GeoJSON/OSM road graphs and streams positions over WebSocket in real time, which could complement your existing layer setup.
Nice work! The real-time vehicle movement rendering challenge you mentioned reminded me of a tool I've been building — Moveet (https://github.com/ivannovazzi/moveet), an open-source fleet simulator that drives synthetic vehicles on real OSM road networks using A* pathfinding, streaming positions over WebSocket. It's aimed at developers who need realistic GPS movement data to test fleet or logistics software, and supports Kafka, Redis, and REST sinks. Your approach of batching 30k+ GeoJSON features into typed arrays is a great pattern for this kind of workload.
ivannovazzi commented on Show HN: Grrow – NDA to wire in one platform for PE funds and family offices · Posted by u/shreybakhai
The pre-investment workflow gap is real. Everything I've seen in fund admin focuses on post-close: reporting, K-1s, cap table. The NDA-to-wire funnel is manual chaos for most GPs.
We're solving a similar document-chasing problem in a different vertical — professional services firms (accountants, lawyers, consultants) using Gatherly (gatherly.io). Same core pain: clients need to sign agreements and submit supporting documents, and without automation the firm spends hours on follow-up emails.
Our approach: one Secure Link to a branded portal where the client signs (eIDAS-qualified) and uploads everything in a single session. Automated reminders handle the chasing.
Curious about your subdocs flow — that's the most complex part of fund onboarding. Are you generating the subscription documents dynamically based on the accredited investor questionnaire, or is it templated per fund? That integration point seems like where most of the value is for GPs who currently do it over email + DocuSign + spreadsheets.
Really like the three-tier classification (PUBLIC/SENSITIVE/SERVER). That's a thoughtful design — most env var solutions treat everything as equally secret or equally public.
The frontend injection problem you're solving is the mirror image of what we deal with on the backend side. We built KeyEnv (keyenv.dev) to handle the server-side piece: secrets stored encrypted, pulled via CLI, and injected as env vars at runtime. No .env files on disk.
The combination is interesting — REP for the browser-facing config, something like KeyEnv for the server-side secrets that feed REP_SERVER_* vars. The HMAC integrity check on the payload is a nice touch, especially for SPAs where someone could tamper with the injected HTML before it hits the client.
One question on the SENSITIVE tier: with the session-key-based decryption, what's the lifecycle of the session key? Is it per-page-load, per-user-session, or something else? That seems like the main variable in the security tradeoff.
ivannovazzi commented on Show HN: Atrium – An open-source, self-hosted client portal github.com/Vibra-Labs/Atr... · Posted by u/ecotto123
Thanks! Gatherly looks good, the eIDAS integration is a great niche.
We just launched, so we’re still in the "discovery" phase regarding our user base but you’re right that many pro services want zero overhead, which is why a paid hosted version is on our roadmap to capture that majority.
We are starting with the self-hosted/open-source angle for two reasons:
Privacy & Control: For agencies handled sensitive data who aren't ready for a full SaaS commitment.
The "Tech-Forward" Freelancer: People doing smaller contracts who want a professional portal without another recurring subscription.
We plan to work on getting merged into Unraid to lower the barrier for those smaller self-hosters so it feels less like "ops" and more like a one-click install
Thanks! The Unraid angle is smart — one-click install removes the biggest objection to self-hosted. That could be a really strong wedge for the privacy-first crowd.
We're seeing a similar split in our market. The accountants and law firms we talk to won't touch self-hosted — they want zero ops and just need it to work. But agencies and consultants who handle sensitive client data (immigration, financial advisory) often ask about data residency and control first.
Your two-track approach (self-hosted free, hosted paid) actually complements what we're doing well. If someone needs full infrastructure control, Atrium is the right fit. If they want managed SaaS with eIDAS compliance baked in, Gatherly covers that. Might even make sense to cross-refer users who land in the wrong bucket.
Good luck with the launch — the market is definitely big enough for both approaches.
ivannovazzi commented on Stop Putting Secrets in .env Files jonmagic.com/posts/stop-p... · Posted by u/veverkap
While the 1Password model is not perfect, you can organize your vaults however makes sense for your project. You can do prod/staging/dev, or by projects, etc. Or you can use the new environments feature and create a separate "environment" for each. Service accounts and users can be granted access to specific vaults only.
The huge benefit is that if you are already using it for other stuff, there is no additional "secret zero" to set up - plus you get biometric unlock for your secrets.
Easiest way to use it for dev purposes is varlock (although I'm biased since I created it).
Good points — the "no secret zero" advantage of 1Password is real, especially if the team already uses it. Biometric unlock is a nice UX win too.
Where we saw friction was in CI/CD and multi-service setups. 1Password's op CLI adds ~2-3s per secret fetch, which compounds in pipelines with dozens of env vars. KeyEnv batches the pull so it's one round-trip regardless of how many secrets you need.
The other gap we kept hitting: onboarding a new team member. With 1Password you need to set up vault access, service accounts, and teach them the op run workflow. With KeyEnv it's `keyenv pull` and you're done — access is scoped per project and environment, so you grant access once and they get exactly the secrets they need.
Varlock's approach of bridging 1Password into dotenv workflows is clever though. For teams already deep in the 1Password ecosystem, that's probably the lowest-friction path.
ivannovazzi commented on Show HN: KeyEnv – manage team secrets without scattered .env files keyenv.dev/... · Posted by u/ivannovazzi
you are wrong on every point
On Open Source: you deflect from the actual question to talk about cloud hosting, which they also have
On hyperscalers: very little friction, cloud lockin is not true
On pricing: your calculation is backwards, for a team of 10 with 10 secrets, yours costs 48x, break even does not happen until I have 48 secrets per developer, I don't know anyone near that
Context: this is one thing I get paid to do
Appreciate the pushback — you clearly know this space well.
On open source: no, KeyEnv is not open source. That's a real trade-off and I should have said so directly.
On pricing math: you're right in that scenario. For 10 devs with 10 total secrets, AWS SM is dramatically cheaper. Our pricing makes more sense when teams have dozens of secrets per environment across multiple projects (dev/staging/prod) — where the per-user flat rate becomes predictable. But I take the point that the break-even is higher than I'd like.
On hyperscaler friction: fair, it's gotten much better. The main gap we see is local dev DX — injecting secrets into `npm start` or `docker compose up` without writing files. But you could wrap that around SM too.
Honest feedback helps. Thanks.