ivannovazzi
Joined 9 months ago
Joined 9 months ago
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.
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.
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.
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.
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.
We're building something in the same space with KeyEnv (https://keyenv.dev) but took a different direction: server-side encrypted storage with a CLI that injects secrets as env vars at runtime (`keyenv run -- npm start`). No files written to disk, no .env files to manage.
The trade-off is pretty clear: AxKeyStore gives you full ownership of storage (GitHub repo) at the cost of managing encryption keys yourself. KeyEnv handles the key management server-side but requires trusting our infrastructure (or self-hosting).
For teams, the big differentiator is access control — KeyEnv scopes secrets per project and environment, and tracks who accessed what. Curious if you've thought about multi-user scenarios for AxKeyStore?
We're building Gatherly (gatherly.io) for a similar audience but with a SaaS approach focused on professional services (accounting firms, law firms, consultants). The key difference is we've baked in eIDAS-qualified e-signatures and automated document collection workflows — so clients can sign agreements and upload requested documents through a single branded portal, no account required.
The self-hosted angle is interesting for developers, but most of the professional services firms we talk to want zero ops overhead. Would be curious if you've seen demand from non-technical users.
Where we've differentiated: Gatherly bundles e-signatures (eIDAS-qualified) with document collection in a single client workflow. So instead of sending one link for documents and another for contract signing, the client gets one Secure Link to a branded portal where they sign and upload everything in one session.
Curious how you're handling the reminder/follow-up side — that's been the single biggest value driver for our early users. Automated reminders that chase the client so the firm doesn't have to.
We built KeyEnv (keyenv.dev) to handle this: secrets are encrypted at rest, pulled via CLI, and injected at runtime. The agent gets the env vars it needs without ever seeing the raw secret values stored anywhere on disk.
The approach works well with AI coding tools because: (1) no secrets in any file the agent can read/commit, (2) rotation happens server-side without touching the dev environment, (3) audit trail shows exactly which secrets were accessed and when.