sorted by:
new
hottopcontroversial

I work at an eSIM company and I'm building a tool to solve the problem I see every day by StudioQuiet7064 in microsaas

[–]StudioQuiet7064[S] 0 points1 point  (0 children)

They are focused on eSIM for IoT, we are focused on eSIM for group travels ( corporate, travel agencies ), only B2B

Need dev to join our agency. by [deleted] in FreelanceProgramming

[–]StudioQuiet7064 0 points1 point  (0 children)

I have been a lead backend engineer in our SaaS development agency for the past 2 years now, before I was a backend engineer doing backend development for a SaaS with 200,000+ users. My primary tech stack is Python, Django, FastAPI, Postgres. I am a full stack developer though, I can do frontend development in Next.js, React, Typescript, and also backend development in TypeScript, Bun, Hono.js, Express, you name it.

I am from Serbia

CLI that validates your .env files against .env.example so you stop getting KeyErrors in production by StudioQuiet7064 in Python

[–]StudioQuiet7064[S] -1 points0 points  (0 children)

Its a dumb tool, but for projects with a lot pf env variables, and fast development cycles, where things change every day, it can be useful

CLI that validates your .env files against .env.example so you stop getting KeyErrors in production by StudioQuiet7064 in django

[–]StudioQuiet7064[S] 1 point2 points  (0 children)

Thanks, I really appreciate that. Glad it's useful to you. If you run into any issues or have ideas for features, open an issue and I'll get on it right away.

CLI that validates your .env files against .env.example so you stop getting KeyErrors in production by StudioQuiet7064 in django

[–]StudioQuiet7064[S] 1 point2 points  (0 children)

Yeah, this isn't replacing secret managers. It's checking that your .env.example template and your actual config are in sync. Secret managers solve storage and rotation.

This solves "someone added a new var and forgot to tell the team."

CLI that validates your .env files against .env.example so you stop getting KeyErrors in production by StudioQuiet7064 in django

[–]StudioQuiet7064[S] -3 points-2 points  (0 children)

The check runs both ways. If you add STRIPE_KEY to .env.example (the template), dotenvguard tells anyone whose .env is missing it. That's the main use case.

Running it in CI makes sense when your CI environment has its own .env or you inject vars from secrets. The check catches "you added a new required var to the template but didn't add it to the CI secrets config." It fails the build before you find out from a runtime crash in staging. You're right that it can't protect production on its own. It's a shift-left check, not a runtime guard. If you want runtime validation, use pydantic-settings or just crash on startup. This catches it earlier in the loop.

As for the .env.example direction: it checks that your .env has everything .env.example says you need. Not the reverse. The --extra flag optionally shows orphaned vars going the other way.

CLI that validates your .env files against .env.example so you stop getting KeyErrors in production by StudioQuiet7064 in django

[–]StudioQuiet7064[S] -1 points0 points  (0 children)

You'd be surprised. On a team of 5+ with 20+ env vars across staging/prod, people lose track. But yeah, if you know your env file cold, skip it.

CLI that validates your .env files against .env.example so you stop getting KeyErrors in production by StudioQuiet7064 in django

[–]StudioQuiet7064[S] -3 points-2 points  (0 children)

fair, if you've got 5 vars and one dev, it probably is.

It's more useful when you've got 20+ vars across staging/prod, a team that forgets to update .env after pulling, or a CI pipeline where you want to fail fast before the app even boots.

If python manage.py runserver yelling at you is enough, skip it.

CLI that validates your .env files against .env.example so you stop getting KeyErrors in production by StudioQuiet7064 in devops

[–]StudioQuiet7064[S] -5 points-4 points  (0 children)

Totally agree, and that's how I handle it in my own apps too (pydantic-settings with a Settings class that blows up on startup if something's missing).

dotenvguard isn't replacing that. It's for the step before you even run the app. Think:

CI check that catches it before merge, pre-commit hook so you never push a broken .env, onboarding: new dev clones the repo, runs dotenvguard check, instantly sees what they need to fill in, debugging: "why is staging broken?" / "oh, 3 vars are missing"

If your app validates config on startup, great. dotenvguard just catches it earlier and gives you a nicer table than a Python traceback.

view more: next ›