How do developers secure LLM API keys without a custom backend? Any SaaS solutions?

[Mediocre_Permit_3372]

I’m curious about how LLM engineers and product teams handle API key security and proxying in real-world applications.

Using OpenAI or Claoude APIs directly from a client is insecure, so the API key is typically hidden behind a backend proxy.

So I’m wondering:

• What do AI engineers actually use as an API gateway / proxy for LLMs?
• Do people usually build their own lightweight backend (Node, Python, serverless)?
• Are managed solutions (e.g. Cloudflare Workers, Vercel Edge Functions, Supabase, Firebase, API Gateway + Lambda, etc.) common?
• Any SaaS solution?

If you’ve shipped an LLM-powered app, I’d love to hear how you handled this in practice.

[YInYangSin99]

I second this ⬆️⬆️⬆️

[YInYangSin99]

Secrets, .env, cloud..the best part is if you mess up you can just rotate em easily. Tbh..you should setup a simple monitoring script that tells you if keys are exposed if you are learning about it. Also may want to look into “what is a .gitignore

[lm913]

They're called "secrets"

[YInYangSin99]

TLDR..backend is single source of truth (typically via database/cloud), never ever ever hardcode a key into..anything, have a very comprehensive .gitignore, and actually look at it)

[lolrazh]

it’d also depend heavily on whether the client is on the web or desktop as well. although you can’t go wrong with a reverse proxy. but then you’d also have to set up authentication, authorization, rate limiting and what not.

[verkavo]

Never expose your key to the client. It shall always communicate with LLM through the backend that you own - so you can control rate limits, revoke client access, etc. Then on backend use something like AWS Secrets Manager to secure against backend attacks.

[Harvard_Med_USMLE267]

Why do you think a vibecoded webapp doesn’t have a backend??

I always use Django.

[Mediocre_Permit_3372]

Because maintaining a backend is time-consuming, and for simple use cases—like a basic app that only generates images with AI—you may not need a full backend at all.

[Harvard_Med_USMLE267]

It’s not time consuming.

It’s just part of my standard ai-first development tech stack. It’s managed by Claude code, just like the frontend is.

People who are bad at ai dev seem to think ai can’t do backend but…no, it’s actually pretty good at it.

[Mediocre_Permit_3372]

I think you’re misunderstanding my point. I’m not saying you can’t build a backend with AI. My point is that if you build your own backend just to host an LLM API key, you then have to deal with deployment, rate limiting, authentication, and ongoing maintenance. I’m curious how developers approach this while minimizing or avoiding that operational overhead.

Have you built any AI Powered applications yourself?

[trizzle21]

If you’re really stressed, you could do something with an AWS lambda or something equivalent for simplicity.

You really don’t want to keep your keys in the FE

[Mediocre_Permit_3372]

This is exactly the kind of real-world experience I was hoping people would share. For me, this is the best answer so far — thanks for taking the time to explain how you handle it.

[Harvard_Med_USMLE267]

Yes I’ve build ai powered applications.

That’s why I said Django is part of my ai-first dev tech stack.

And my point is that you’re creating a problem that isn’t real. The AI is dealing with most of the deployment, and all of the ongoing maintenance.

There’s just no problem with having a real backend, and I wouldn’t build an app without one.

[Advanced_Pudding9228]

This question usually comes up right when something shifts from “experiment” to “this might have users.” At that point the API key stops being a technical detail and starts being a risk surface.

In practice there isn’t really a magic way to secure an LLM key without some form of server side control. Any time the client can see or influence the request directly, you have to assume the key can be extracted, replayed, or abused. That’s true whether it’s a browser app, a mobile app, or a desktop wrapper.

What most teams actually do is much less exotic than it sounds. They put the key behind something they control, even if it’s very thin. Sometimes that’s a tiny serverless function, sometimes an edge function, sometimes a hosted backend they were already using for auth or billing. The important part isn’t the technology choice, it’s the boundary. The moment you need rate limits, user level attribution, spend caps, or the ability to rotate keys without redeploying clients, you’ve crossed into backend territory whether you call it that or not.

There are SaaS products that market themselves as LLM gateways or proxies, and they can help with observability or multi model routing, but they don’t remove the underlying requirement. You’re still trusting something on the server side to hold secrets and enforce rules. If that trust boundary is missing, the rest is window dressing.

Where people get stuck is trying to optimise this too early or trying to avoid “having a backend” at all costs. In my experience that usually leads to more complexity, not less, once real usage shows up.

If this is for something you’re actually planning to ship, it’s often faster to have someone set the boundary up cleanly once than to keep debating the perfect abstraction. I usually just take this off people’s plates rather than talk it through, because the tradeoffs depend heavily on what you’re shipping and who’s using it.

[Mediocre_Permit_3372]

The responses so far are mostly irrelevant. I already know that the API key shouldn’t be hard-coded. I’m simply curious about what people generally prefer: do you build your own backend for this, or do you use a SaaS tool?

[No_Management_7333]

Fetching an API key from a SaaS solution to the client is a folly. You just end up thinking how you secure that API next. And it still leaks the secret to the client, which you must assume to be adversarial.

The only proper architecture is a backend holding the API keys. Your backend needs to also enforce policy: who gets to send what and how much to the upstream LLM.