How are you folks handling secrets in a simple way?
- sops , ansible vault and similar seems too weak given the agent is gonna read them at some point if you have the pass available.
- proxy injection seems too complicated and doesn’t cover all use cases.
Try not to: use AWS short-term credentials for anything there, federate with GitHub/GitLab job credentials where possible, etc. It’s easier and you never worry about rotation again.
If you can’t avoid it, use an automatically-rotated store and inject them as late as possible so an attacker needs to be able to get them out of a running process.
In all cases, look into restrictions: not just least privilege access but things like network restrictions so an attacker can’t just use the key on their own systems.
I recently finally fully moved all my projects away from .env (for local dev) to infisical, thinking it'd be the way to stop agents from (accidentally?) peeking at my secrets. while I'm still glad I made the move, it's clear that local agents are still moving around my local environment with sufficient privileges and autonomy to use infisical cli however it wants. my work isn't high stakes enough to matter much and I have rotation scripts on hand, but it's hard to see how to fully close the door against this type of risk at this point.
There's a solution for this in Infisical! It's called secrets brokering and is built into the Infisical CLI: The Infisical agent proxy. Using this, your agent can use secrets without ever being able to fetch them back since they are injected into upstream requests. You can use this for local coding agents like Claude Code or Codex, and also have a standalone proxy with a separate machine identity for longer running agents (slack agents, hermes, openclaw etc.) Check it out here:
It's not clear to me whether this is being done with genuinely good intentions, or if it's just a way to put barriers in front of open-source models. We'll see.
This is not my case. Today Claude code coded three features in my client saas just perfectly. Medium complex ones but perfectly from the plan, tests, linter and pr.
A good CLAUDE.md is enough. Skills for auxiliary tools like sentry, grafana…
WHEN do you move to Redis/Memcached? None of my projects have exceeded 1000 rps at peak, and in none of them have I felt the need to move from unlogged PostgreSQL tables to Redis.
Just trying to get a sense of where people draw the line.
Mostly is no rule, adding a cache can just save you from having to buy a bigger database instance in many cases.
The most common first thing to cache is getting the current user, because this ends up being a very hot path for most stateless systems. Because you need to get the current user for almost every request, it's quite easy for getting the current user to be 50% of database load: first you get the user, then you do the thing. tada, user lookup is now half your app by volume
At scale, the timing and order of magnitude increases in latency can add up. Caching the most requested data the higher you go can keep up performance (at added cost). On a busy website, that could be things like session tokens or other data that is part of every request. On a landing page, it could be images or other static data (I mean, you'd use a CDN for this, but you get the idea). Database calls can be expensive (computationally and IO wise), so if you can recalculate and cache certain operations, you can keep up.
Also, do you really need memcached/redis? If you have session affinity, you can also have nodes each keep their own caches in memory, with the caveat that if there's a failover, you'll have to re-fetch the data. Redis/memcached would be more of a shared cache, for things that you may not want to interrupt the user if they hit a different front-end endpoint.
It also doesn't have to be a cache. We've used redis for distributed task coordination as a shared state with the caveat that if something happened to redis, we'd just restart the task.
TL;DR If you need a SHARED cache when the performance of your app slows down enough that the cost of caching makes up for it.
You could ask the opposite question too, could you move your bespoke Redis/mcd workload to a boring old database? We have some workloads from 100k-1M ops/s that I would love to streamline but the load is too high. So... 100k in this case? :-)
reply