An API key is a credential that lets software use a service. Depending on its permissions, it may access information, change something, or generate charges.
That is why I want to treat it with the same care as a password.
My starting rule is to keep real keys out of code, public posts, screenshots, and AI conversations. When I need help with a setting, I can use a placeholder instead of the real value.
Some projects load local settings from a file named .env. That file can contain secrets, so I need to keep it out of Git and limit access to it. The filename itself does not encrypt or protect the contents.
A companion file named .env.example can show the required setting names with blank or clearly fake values. That helps someone set up the project without sharing the actual credentials.
For learning, I want separate development resources and test credentials where the service supports them. I will also limit permissions and set spending controls where available. A test key may still have access or cost implications, so it deserves protection too.
Live application secrets belong in the hosting service’s secret settings, with access limited to the people and systems that need them. I do not want to copy them into a practice project.
Keeping live keys out of that folder does not remove every route to the live app. A signed-in hosting dashboard or a GitHub account allowed to publish can still be powerful.
I also want secret scanning as another check. A scanner can catch common credential patterns in files or saved history. It can miss things, and it needs to run on the material I am actually sharing.
If a real key is exposed, deleting the visible text is only part of the response. The key needs to be revoked or replaced at the service that issued it.