Handling environment variables in Astro - Step-by-Step Execution

Concept Flow - Handling environment variables

Start Astro Project

↓

Create .env file

↓

Define variables: KEY=VALUE

↓

Access variables in Astro code

↓

Use import.meta.env.VARIABLE

↓

Build & Run Project

↓

Variables injected at build time

↓

App uses env values safely

This flow shows how Astro reads environment variables from a .env file, injects them at build time, and makes them available in your code via import.meta.env.

Execution Sample

Astro

console.log(import.meta.env.MY_SECRET)

This code accesses the environment variable MY_SECRET and logs its value to the console.

Execution Table

Step	Action	Evaluation	Result
1	Read .env file	MY_SECRET=supersecret	Variable loaded into build environment
2	Build Astro project	Inject import.meta.env.MY_SECRET	Variable available in code
3	Run code: import.meta.env.MY_SECRET	Access variable	"supersecret"
4	Console.log output	Print value	supersecret
5	End	No more steps	Execution complete

💡 All environment variables accessed and logged, execution ends.

Variable Tracker

Variable	Start	After Build	After Access	Final
import.meta.env.MY_SECRET	undefined	supersecret	supersecret	supersecret

Key Moments - 2 Insights

Why can't I access environment variables directly like process.env in Astro?

Astro uses import.meta.env to access env variables injected at build time, not process.env. See execution_table step 3 where import.meta.env.MY_SECRET is accessed.

What happens if I change the .env file after building?

Changes won't reflect until you rebuild the project because variables are injected during build. See execution_table step 2 where build injects variables.

Visual Quiz - 3 Questions

Look at the execution table, what is the value of import.meta.env.MY_SECRET after build?

A undefined

B "supersecret"

C null

D "MY_SECRET"

💡 Hint

Check execution_table row 2 under Result column.

At which step does the environment variable become available in the code?

A Step 1

B Step 3

C Step 2

D Step 4

💡 Hint

Look at execution_table step 2 where build injects variables.

If you modify the .env file after running the project without rebuilding, what happens?

A The old value remains until rebuild

B The new value is used immediately

C The project crashes

D The variable becomes undefined

💡 Hint

Refer to key_moments about build time injection and execution_table step 2.

Concept Snapshot

Handling environment variables in Astro:
- Define variables in a .env file as KEY=VALUE
- Access them in code via import.meta.env.KEY
- Variables are injected at build time
- Changes require rebuilding to take effect
- Use for safe config without exposing secrets

Full Transcript

In Astro, environment variables are stored in a .env file with KEY=VALUE pairs. During the build process, Astro reads this file and injects these variables into the code as import.meta.env.KEY. This means you access environment variables using import.meta.env in your Astro components or scripts. The variables are not available as process.env like in Node.js. When you run your project, the variables hold the values from the .env file at build time. If you change the .env file, you must rebuild the project to update the variables. This method keeps secrets safe and allows configuration without hardcoding values.

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