Why Handling environment variables in Astro? - Purpose & Use Cases

The Big Idea

Discover how to keep your secrets safe and your app flexible with one simple practice!

The Scenario

Imagine you have to change your website's API keys or database passwords directly inside your code every time you move from development to production.

Each time you share your code, you risk exposing sensitive information or making mistakes that break your app.

The Problem

Hardcoding secrets is risky and tedious.

It leads to security leaks, accidental commits of private data, and makes switching environments slow and error-prone.

The Solution

Handling environment variables lets you keep secrets outside your code.

Astro reads these variables safely from files or your system, so you can switch settings without touching your code.

Before vs After

✗ Before

const apiKey = 'my-secret-key'; // hardcoded in code

✓ After

const apiKey = import.meta.env.PUBLIC_API_KEY; // loaded from environment

What It Enables

You can securely manage different settings for development, testing, and production without changing your code.

Real Life Example

When deploying your Astro site, you use environment variables to provide API keys for payment gateways or analytics without exposing them publicly.

Key Takeaways

Hardcoding secrets is unsafe and inflexible.

Environment variables keep sensitive data separate from code.

Astro makes it easy to access these variables securely in your app.

Practice

1. In Astro, how do you access environment variables inside your code?

easy

A. Using import.meta.env

B. Using process.env

C. Using window.env

D. Using Astro.env

Solution

1. Step 1: Understand Astro environment variable access

   Astro uses the import.meta.env object to expose environment variables.

2. Step 2: Compare with other options

   process.env is common in Node.js but not in Astro client code. window.env and Astro.env are not valid in Astro.

3. Final Answer:

   Using import.meta.env -> Option A

4. Quick Check:

   Astro environment variables = import.meta.env [OK]

Hint: Remember: Astro uses import.meta.env for env variables [OK]

Common Mistakes:

• Using process.env which is Node.js specific
• Trying to access env variables via window object
• Assuming Astro has a global Astro.env object

2. Which prefix must you add to an environment variable name to make it accessible in Astro client-side code?

easy

A. PUBLIC_

B. SERVER_

C. CLIENT_

D. ASTRO_

Solution

1. Step 1: Identify the client-side environment variable prefix

   Astro requires environment variables to be prefixed with PUBLIC_ to expose them to client-side code.

2. Step 2: Eliminate incorrect prefixes

   SERVER_ is not used for client exposure, CLIENT_ and ASTRO_ are not recognized prefixes in Astro.

3. Final Answer:

   PUBLIC_ -> Option A

4. Quick Check:

   Client env prefix = PUBLIC_ [OK]

Hint: Use PUBLIC_ prefix for client env variables [OK]

Common Mistakes:

• Using SERVER_ prefix which is for server only
• Assuming CLIENT_ or ASTRO_ prefixes work
• Not prefixing variables and expecting client access

3. Given this Astro code snippet:

const apiKey = import.meta.env.PUBLIC_API_KEY;
console.log(apiKey);

If the environment variable PUBLIC_API_KEY is set to 12345, what will be logged in the browser console?

medium

A. "PUBLIC_API_KEY"

B. "12345"

C. Error: Variable not found

D. undefined

Solution

1. Step 1: Understand variable access in Astro client code

   Since the variable is prefixed with PUBLIC_, it is exposed to client code and accessible via import.meta.env.PUBLIC_API_KEY.

2. Step 2: Determine logged value

   The value of PUBLIC_API_KEY is set to 12345, so console.log(apiKey) outputs the string "12345".

3. Final Answer:

   "12345" -> Option B

4. Quick Check:

   PUBLIC_API_KEY value = "12345" [OK]

Hint: PUBLIC_ vars appear as strings in import.meta.env [OK]

Common Mistakes:

• Thinking the PUBLIC_ prefix doesn't make it client accessible, expecting undefined
• Confusing variable name with value
• Assuming error if variable exists

4. What is wrong with this Astro code snippet?

const secret = import.meta.env.SECRET_KEY;
console.log(secret);

Assuming SECRET_KEY is set in the environment but not prefixed with PUBLIC_.

medium

A. It will log the secret correctly in the browser console.

B. It will log the string "SECRET_KEY" instead of the value.

C. It will log null because secrets are blocked by Astro.

D. It will log "undefined" because SECRET_KEY is undefined in client code.

Solution

1. Step 1: Check environment variable accessibility rules

   Variables without the PUBLIC_ prefix are only available on the server side and not exposed to client code.

2. Step 2: Analyze client-side access attempt

   Trying to access import.meta.env.SECRET_KEY in client code results in undefined, so console.log(secret) logs "undefined".

3. Final Answer:

   It will log "undefined" because SECRET_KEY is undefined in client code. -> Option D

4. Quick Check:

   Non-PUBLIC_ vars are undefined client-side [OK]

Hint: Secrets need no PUBLIC_ prefix and stay server-only [OK]

Common Mistakes:

• Expecting secret to be available in client code
• Assuming Astro logs variable names instead of values
• Thinking Astro replaces missing vars with null

5. You want to use an API key in your Astro project. The key should be kept secret and never exposed to the browser. How should you handle this environment variable?

hard

A. Prefix the variable with PUBLIC_ and use it directly in client code.

B. Store the variable without prefix and access it in client code via import.meta.env.

C. Store the variable without PUBLIC_ prefix and access it only in server-side code.

D. Prefix the variable with SERVER_ and use it in client code.

Solution

1. Step 1: Understand security best practices for secrets

   Secrets like API keys should never be exposed to client code to avoid leaks.

2. Step 2: Use environment variable naming and access rules

   Variables without the PUBLIC_ prefix are only available on the server side in Astro, so store the API key without the prefix and access it only in server-side code.

3. Final Answer:

   Store the variable without PUBLIC_ prefix and access it only in server-side code. -> Option C

4. Quick Check:

   Secrets stay server-only without PUBLIC_ prefix [OK]

Hint: Keep secrets unprefixed and server-only for safety [OK]

Common Mistakes:

• Adding PUBLIC_ prefix and exposing secrets to client
• Trying to access secrets in client code
• Assuming SERVER_ prefix controls access