Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account


rochacbruno opened this Issue Apr 9, 2019 · 3 comments


None yet
3 participants
Copy link

rochacbruno commented Apr 9, 2019


As you are on Dynaconf Issues page I assume you are using Dynaconf, or are interested in using it?

This issue is a placeholder to get feedback from users, can you share your experience?

Or if you are not a user, can you share what are you looking for in a config management library?


For those using Dynaconf

  • Are you using Dynaconf (yes/no)
  • Can you share some details? (company, project, stack)
  • When did you start using Dynaconf?
  • What features you use?
  • What features you miss?

For those not using

  • If you have tried Dynaconf but decided not to use, can you share why?
  • If you are still reading and have not tried yet can you share what you are looking for?

Feel free to share any comment, suggestion you have


@rochacbruno rochacbruno pinned this issue Apr 9, 2019

@rochacbruno rochacbruno added the meta label Apr 9, 2019


This comment has been minimized.

Copy link

janw commented Apr 17, 2019

Hey. New dynaconf user here! Thanks for the great library, here are some answers to your "market research request" 🙃

Can you share some details? (company, project, stack)

We just started using Dynaconf at @innovocloud for one internal project, possibly more in the future. The app is a custom-built, containerized, and runs in Kubernetes. The latter greatly benefits from configurability via environment variables.

When did you start using Dynaconf?

Two days ago 🤓

What features you use?

Env vars, .env files, settings.toml file, and an extensive validation logic. Possibly vault support in the future.

What features you miss?

Disabling Env var prefixes altogether. Within a controlled environment like Docker containers there's no real need for prefixing all settings, and setting GLOBAL_ENV_FOR_DYNACONF="" leaves a preceding underscore. If you're interested and that's a feature that you would like in Dynaconf, I will provide a PR allowing to disable the global env.


This comment has been minimized.

Copy link
Owner Author

rochacbruno commented Apr 17, 2019

@janw thanks for answering!

I like the idea of disabling the prefix.


This comment has been minimized.

Copy link

chobeat commented Apr 21, 2019

Are you using Dynaconf (yes/no):

yup, at work in most of our python codebase

Can you share some details? (company, project, stack)

Project: we do data-compression using machine learning. Dynaconf is used in many services for the training part.
Stack: Faust and Kafka, basically.

When did you start using Dynaconf?

Around 1 year ago

What features you use?

Before I was using it pretty basically, loading a toml and some environment variables, using a series of "spec" classes that validated the presence of some keys at startup. Recently I've added a live reload of the logging levels when running in debug mode so that I can change the levels in a toml file and control the logging. Clearly this is done through dynaconf.

What features you miss?

My usage right now is quite basic so I don't feel like I'm missing any feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.