[HN Gopher] Instrumenting Next.js with runtime secret injection
___________________________________________________________________
Instrumenting Next.js with runtime secret injection
Author : nimishk
Score : 17 points
Date : 2025-07-27 16:53 UTC (6 hours ago)
(HTM) web link (phase.dev)
(TXT) w3m dump (phase.dev)
| latchkey wrote:
| "https://api.phase.dev"
|
| 100% uptime, I'm sure.
| cowthulhu wrote:
| Are you making the argument that they should have a default API
| route? I don't think that's very common.
| latchkey wrote:
| I'm making the argument that I wouldn't rely on an API
| endpoint to serve up the secrets that enable my application
| to work. Imagine a network outage or endpoint failure when
| the app just happens to be redeployed.
| duncanfwalker wrote:
| I think it depends on the API - we do this with AWS Secret
| Managers. I haven't seen it fail but if did it would only
| effect new instances coming into service so I think we'd
| have to be pretty unlucky for it to have a noticeable
| impact.
| latchkey wrote:
| This wasn't an AWS Secrets Manager example, and yes,
| there's a guy named Murphy who wrote a law about this
| kind of thing.
| karmakaze wrote:
| That's a whole category of software that makes large
| systems work: etcd, Zookeeper, HashiCorp Vault, etc.
| latchkey wrote:
| Yes! All built with redundancy in mind.
|
| https://etcd.io/docs/v3.3/op-guide/
|
| https://zookeeper.apache.org/doc/r3.9.3/zookeeperStarted.
| htm...
|
| https://developer.hashicorp.com/vault/tutorials/day-one-
| raft
| jitl wrote:
| Where should secrets come from then? Burn them into the
| deployable artifact??? Place them on the host filesystem in
| perpetuity???
| ashwinsundar wrote:
| Looks like the Next.js gish-gallop machine is firing on all
| cylinders, augmented by generative AI. .env
| files are problematic because they often end up in version
| control or left lying on local disks unencrypted, increasing the
| risk of a secret leak. They're nearly impossible to manage
| securely at scale, are difficult to distribute across a team, and
| offer no access control or security.
|
| Sure, if your developers live in a bubble and don't know any
| better. Otherwise, .env files are fantastic because they are dead
| simple. Keeping them out of VCS is simple. echo ".env" >>
| .gitignore.
|
| Need to share a secret value? Use any number of secure
| communications systems your company has in place. Or generate
| your own from the system that is issuing secrets. It's not the
| 1950s, when sharing a secret was considered a national security
| endeavor. This doesn't need to be rocket science.
|
| You can communicate what's supposed to go in the .env file with a
| .env.template file, with a list of env variables set equal to an
| empty string.
|
| I'm glad they at least share the nightmare that is client-side
| environment variables. Prepare to waste days/weeks of your life
| sifting through unresolved issues in Next.js repo on GitHub, only
| to discover that you have to re-architect vast swaths of an
| application just so a secret (of any kind) is never required on
| the client. This is incredibly challenging and frustrating to
| deal with, especially when on a deadline and you're 95% done with
| a working solution.
|
| In typical Next.js fashion, the official documentation for
| instrumentation.ts is complete dog crap. It's deceptively short,
| making the naive developer think it's simple to configure. In
| reality, you should first read through the 50 open and 71 closed
| GitHub issues related just to instrumentation (https://github.com
| /vercel/next.js/issues?q=is%3Aissue%20stat...), and make sure you
| understand all the undocumented ways in which instrumentation.js
| will destroy any semblance of productivity or enjoyment of
| programming.
|
| I'd highly recommend staying away from the dumpster fire that is
| Next.js. It's too bad it's like the top skill asked for by
| employers these days, who seem to have no idea what they're
| signing up for.
| politelemon wrote:
| TIL https://en.m.wikipedia.org/wiki/Gish_gallop
| jitl wrote:
| > just so a secret (of any kind) is never required on the
| client
|
| This is how web clients usually work though not NextJS special
| at all. You have a HTTP only cookie for authentication and
| proxy requests through your backend to authorize client to
| perform actions that depend on secrets.
|
| I'm not a NextJS proponent and have experienced frustrations
| running into its limitations but I think in this case it's
| unfair to malign it.
|
| If anything NextJS makes this easier, you just move your
| function call that uses a secret to a "use server" file and add
| an authorization check but your client code doesn't need to
| change you keep importing it and calling it like a regular
| async function.
| anonzzzies wrote:
| > I'd highly recommend staying away from the dumpster fire that
| is Next.js. It's too bad it's like the top skill asked for by
| employers these days, who seem to have no idea what they're
| signing up for.
|
| 100% agree and we need more people saying it. It is crazy how
| it got so big. Look at the amount of (breaking) changes that
| benefit no one except vercel (others cannot really keep up, and
| that's the plan) and the almost unbelievable amount of sloppy
| CVEs all over the place (patched automatically if you run with
| vercel). We get called in after things go wrong to monkey patch
| it so the business keeps going: nextjs issues are delivering us
| a lot of work.
| azemetre wrote:
| I still don't believe it's that big, but they have had
| consistent revenue growth:
|
| https://getlatka.com/companies/vercel
|
| If there is another sustained recession, I do wonder how
| these companies will handle the turmoil. Cutting overpaid
| services seems like a no-brainer if you have to tighten your
| belt.
|
| I've also never seen next.js mentioned in a job ad where I
| worked for the last 10 years (greater Boston area), never
| really heard much from them during the meetup scene during
| that time either (2015-2020). I wonder if these customers are
| more associated with SV businesses, where VC's force their
| portfolio to buy services from each other.
|
| Also can't imagine v0 not being a money drain.
| techpression wrote:
| > I'd highly recommend staying away from the dumpster fire that
| is Next.js. It's too bad it's like the top skill asked for by
| employers these days, who seem to have no idea what they're
| signing up for.
|
| Oh yes, Next.js is on my permanent blacklist of "I won't take a
| job if they use it". It's truly one of the worst maintained
| software I've ever used, they break stuff constantly,
| completely without awareness.
| ashwinsundar wrote:
| I agree with everything except "completely without
| awareness"...the game is called "vendor lock-in" and they're
| intentionally breaking anything that allows people to use
| Next.js outside their fancy, expensive ecosystem
___________________________________________________________________
(page generated 2025-07-27 23:01 UTC)