Greptile Logo

How Greptile Built a Single Source of Truth for Secrets as It Scaled

As Greptile's engineering team grew, manual management broke. Now on Infisical, onboarding a new engineer is a single access grant, rotating a production secret is a swap-and-deploy, and Greptile can tightly scope AI agent secrets access.

Greptile·North America·11-50 employees·$30M raised
“Getting people to set up their development environment used to be painful. Now it’s solved.”Soohoon Choi, Founder and CTO, Greptile
The challenge: manual secret management that broke down as the team grew
Greptile builds AI code review agents. Its customers trust it with proprietary source code, so credentials, isolation, and access are core to the product.
Secrets management became a concern when the company started scaling its engineering team after its Series A. Up to that point, managing credentials was a manual exercise. The team passed secrets around with one-time password shares, handed off .env files, and leaned on a mix of 1Password and other tools. None of it was programmatic.
As onboarding picked up, that no longer scaled:
  • Every engineer needed their own local setup plus a shared staging environment, and keeping them aligned was a chore.
  • When a secret was renamed or changed, it had to be updated manually in everyone’s setup. Miss one, and things broke.
  • The backend on AWS and the frontend on Vercel drifted out of sync whenever someone updated one and forgot the other.
“People’s secrets would be out of sync,” Soohoon said. “Someone would make a change, the name of the variable would change, and then someone else’s local setup hasn’t updated, so it breaks things. We needed one centralized store for all this.”
Beyond operational friction, Greptile wanted to audit what was happening with its secrets and the ability to rotate them quickly. With supply chain attacks proliferating, the team ran a thought experiment: if a Greptile secret were exposed, how fast could it swap the secret out? One secret would’ve been manageable, but the whole set of credentials would’ve been difficult. The number of people responsible also grew and even spread across teams.
The solution: open source and self-hostable, chosen for the long run
Soohoon led the evaluation and the implementation. He looked at Bitwarden, 1Password, and AWS Secrets Manager before choosing Infisical.
AWS Secrets Manager was out because it only served AWS. Greptile required hosting flexibility. It needed to host on its own stack and on a different cloud like GCP. A single-cloud secrets manager closes that door. 1Password was out because it is closed source and functions more as a password manager. Bitwarden is open source but is also closer to password sharing than to engineer-first secrets management.
This made open source the deciding factor in choosing Infisical. Greptile needs to run on-premises, so keeping as much of the stack open source as possible gives the team room to move.
“You have full visibility into the stack,” Choi said. “And since Greptile needs to be on-prem, in the event we need to deploy the full stack ourselves, we can just have a copy of that inside our stack. That gives us incredible freedom.”
Greptile runs a monorepo, deploys its cloud services on AWS using ECS, and ships its frontend on Vercel. The team plugged Infisical directly into that stack rather than layering it on top of another secrets store. Today Infisical backs machine identities for production and feeds into Greptile’s CI checks in GitHub Actions, with SSO handling engineer access.
Standing it up took only one to two weeks, with most time spent on cleanup. Most of the work was consolidating scattered config and secrets and making Infisical the single source of truth. “It took a day to upload all the values into Infisical,” Choi said. “Then it was making sure everything was actually dependent on Infisical and there were no other sources of truth.”
The results: onboarding is solved and rotation is trivial
The biggest unlock was onboarding. New engineers now get access to Infisical as part of standard onboarding. From there, a developer only sets their personal overrides for local testing. They no longer accumulate a long list of secret values by hand.
“Getting people to set up their development environment used to be painful,” Choi said. “Now it’s solved.”
Rotation got just as simple. When the team needed to point a database connection string at a read replica, the change was a single update. “We just went to Infisical, swapped it out, and deployed. Done,” Choi said.
The drift between AWS and Vercel went away too, because both now pull from one store instead of being updated separately.
For an AI company, the most differentiated result is access control for agents. Choi treats secrets the way he treats sensitive code: not everyone, and not every agent, should see everything. Using role-based access control, he scopes a role down to only the read-only variables an agent needs, points the agent at that Infisical environment, and knows exactly what it can touch.
“It’s been very useful when I’m working with my agents,” Choi said. “I create a new role with access to only certain variables, and that guarantees the agent only ever has access to that set of values.”
Securing AI agents with Infisical
That same principle is what has Greptile interested in Infisical’s Agent Vault for the code-review product itself. Greptile’s review agents run inside a network sandbox that limits each agent to one repository at a time. To test a customer’s service, an agent sometimes needs real secret values, and Greptile does not want real credentials inside the sandbox.
The team had considered building a solution itself. Agent Vault, which passes dummy values to the agent and swaps in the real value through a proxy as the request leaves the sandbox, is exactly the pattern Greptile was looking for. The team plans to integrate it.
Choi’s advice to other engineering leaders facing a secrets mess follows from all of this: treat secrets like code.
“These secret values are an important resource. In a sense they’re a piece of code, and you don’t want everyone to have access to a piece of code,” he said. “You build access models for sensitive information. The secrets themselves should follow that same model. A central store, plus the ability to programmatically delegate secrets and create roles, is a must-have for any organization.”
Key outcomes
  • Onboarding is a single access grant. New engineers get Infisical access through SSO as part of a standard onboarding routine, then only set personal overrides for local work. Setting up a development environment went from a recurring chore to a solved problem.
  • Secret rotation is swap-and-deploy. Repointing a database string to a read replica was one update in Infisical followed by a deploy, with no dependence on a single deployment machine holding the master secret list.
  • No more environment drift. AWS and Vercel deployments now pull from one centralized store instead of being updated by hand and falling out of sync.
  • Scoped access for AI agents. Role-based access control lets Greptile give a coding agent read-only access to exactly the secrets it needs, and nothing else.
  • A foundation built to self-host. Choosing an open-source, self-hostable tool keeps Greptile’s on-prem and multi-cloud options open as the company grows.
Starting with Infisical is simple, fast, and free.