Skip to main content

Understanding Configuration and Secrets Safely

Passwords Should Never Go In Your Code​

Imagine giving your front door key to a locksmith who puts it in a labeled envelope on your doorstep: "Smith Family House Key—Keep This Safe!" That's what happens when you hardcode passwords or API keys in your code. If someone gets your code, they get your secrets.

This lesson teaches you how to keep secrets safe. Configuration (like API keys, database passwords, and tokens) should live in environment variables or configuration files, never in code.

By the end of this lesson, you'll:

  1. Understand temporary configuration (export commands that last while terminal is open)
  2. Understand persistent configuration (settings that survive closing the terminal)
  3. Never hardcode secrets into your code (security mindset)

Use export to Set Temporary Configuration​

The export command sets a variable in your terminal session temporarily. It's useful for testing values without storing them in files.

Example 1: Set a Temporary Variable​

Step 1: You Try It

In your terminal, set a temporary variable:

$ export TEST_VALUE="hello-world"
$ echo $TEST_VALUE
hello-world

You've set TEST_VALUE temporarily. It exists only in this terminal session. When you close the terminal, it's gone.

What to notice: You used export to set a variable. The $ symbol retrieves its value. It's temporary—only for this session.

Step 2: Your AI Does the Same​

Ask your AI:

Prompt:

Set a temporary environment variable using export.
Show me how to verify it's set using echo $VARIABLE_NAME.
Then explain: What happens to this variable when the terminal closes?

Expected AI Output:

$ export MY_VARIABLE="test-123"
$ echo $MY_VARIABLE
test-123

Your AI uses export the same way you did.

Step 3: Compare and Understand​

Your command: export TEST_VALUE="hello-world" AI's command: export MY_VARIABLE="test-123"

Both set temporary variables. Both verified with echo $. Both will disappear when the terminal closes.

Key insight: Temporary variables are useful for testing but disappear when you exit the terminal.

Diagram showing export command syntax (export VAR=value), variable scope (current shell session only), and echo command retrieving variable value with $ prefix

Flow diagram showing shell startup reading .bashrc/.zshrc, loading environment variables (PATH, HOME, USER), and programs accessing these variables at runtime

💬 AI Colearning Prompt​

"When would you use export for temporary configuration vs. a .env file for persistent configuration?"

Use .env Files to Store Persistent Configuration​

.env files (environment files) are text files that store configuration values. They persist across terminal restarts, unlike export which is temporary.

Step 1: You Try It

Create a simple configuration file:

$ echo "MY_API_KEY=test-key-12345" > .env
$ cat .env
MY_API_KEY=test-key-12345

You've created a .env file with a configuration value. This file persists—it survives terminal restarts.

What to notice: You created a file called .env with configuration. The file stays even after you close the terminal. Your code can read from it.

Step 2: Your AI Does the Same​

Ask your AI:

Prompt:

Create a .env file with configuration values.
Show the commands to create and verify the file.
Explain: Why is a .env file better than export for persistent configuration?

Expected AI Output:

$ cat > .env << 'EOF'
DATABASE_URL=postgres://localhost/db
API_KEY=sk-test-key-12345
EOF

$ cat .env
DATABASE_URL=postgres://localhost/db
API_KEY=sk-test-key-12345

Your AI uses file creation the same way you did.

Step 3: Compare and Understand​

Your approach: Create .env file with echo or editor AI's approach: Create .env file with cat command

Both create persistent configuration files. Both can be read by code. Both survive terminal restarts.

Key insight: .env files persist, unlike export which is temporary.

Why Hardcoding Secrets Is Dangerous​

Bad code (NEVER DO THIS):

# DANGEROUS! Never hardcode secrets!
API_KEY = "sk-abc123def456ghi789"
DATABASE_PASSWORD = "MySecretPassword123"

If this code reaches GitHub, anyone with access to your repository gets your secrets. They can use them to access your accounts and systems.

Good code (DO THIS):

import os
api_key = os.getenv('API_KEY')  # Read from environment, not hardcoded

Secrets come from environment variables or .env files—never from code itself.

🎓 Expert Insight​

In AI-native development, you don't memorize .env file syntax or dotenv library usage. You understand the CONCEPT (secrets belong in environment, not code), and AI handles .gitignore, .env.example, and secure loading. Your job: verify secrets never appear in version control.

Try With AI: Side-by-Side Configuration Comparison​

Now that you've set temporary and persistent configuration, compare what your AI does.

Comparison Prompt​

Open your AI tool and ask:

Prompt:

Let's practice safe configuration.
1. Set a temporary variable using export
2. Verify it with echo $VARIABLE
3. Explain why this is temporary (what happens when I close the terminal?)
4. Show how a .env file would be different

What to Compare:

ApproachYou Do ThisYour AI Does This
Temporary (export)export TEST="value"(AI's export command)
Verify itecho $TEST(AI verifies)
Persistent (.env)Create .env file(AI creates .env file)

Observation: Notice how AI suggested both temporary and persistent approaches—it taught you configuration options. Then you chose based on your project needs—teaching AI your context. This bidirectional learning is the pattern.

🤝 Practice Exercise​

Ask your AI: "Create a .env file for my API key, add it to .gitignore, and verify the key is accessible but NOT committed to version control. Then explain why this matters for security."

Expected Outcome: You understand secrets management workflow and can verify .gitignore is protecting sensitive configuration.

Try With AI: Security Best Practices​

Ask your AI:

Prompt:

I'm about to use an API key in my project.
What's the safest way to handle it?
Show me:
1. Wrong way (what NOT to do)
2. Right way (using .env or export)
3. How to verify it's set correctly
4. How to make sure .env never gets committed to GitHub

Expected Response: Your AI will explain:

  1. Never hardcode secrets in code
  2. Always read from environment or .env
  3. Use echo $VARIABLE or test scripts to verify
  4. Add .env to .gitignore to prevent accidental commits

Key Principle: Secrets belong in environment variables or configuration files, never in code.

Key Insight: Configuration isn't about memorizing export syntax—it's about understanding persistence and verification through conversation with AI.