Why Environment variables on Deploy in Deno? - Purpose & Use Cases

The Big Idea

Discover how environment variables keep your secrets safe and your deployments smooth!

The Scenario

Imagine you have to change your app's secret keys or API URLs every time you move it from your computer to a server.

You open your code and replace values manually before each deployment.

The Problem

This manual method is risky and slow.

You might accidentally share secrets in your code or forget to update a value, causing your app to break.

The Solution

Environment variables let you keep secrets and settings outside your code.

When you deploy, your app reads these values automatically, so you never hardcode sensitive info.

Before vs After

✗ Before

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

✓ After

const apiKey = Deno.env.get("API_KEY"); // read from environment

What It Enables

This makes your app safer, easier to update, and ready for any environment without code changes.

Real Life Example

When deploying a Deno app to a cloud service, you set environment variables in the dashboard instead of changing your code.

Your app automatically uses the right keys and URLs for production.

Key Takeaways

Manual secret management is error-prone and unsafe.

Environment variables separate config from code.

This approach improves security and deployment flexibility.

Practice

1. What is the main purpose of environment variables when deploying a Deno application?

easy

A. To keep secrets and settings outside the code for security and flexibility

B. To write all configuration directly inside the source code

C. To make the application run faster by hardcoding values

D. To store user data permanently on the server

Solution

1. Step 1: Understand environment variables role

   Environment variables store secrets and settings outside the code to avoid exposing sensitive data.

2. Step 2: Recognize deployment best practices

   Keeping secrets outside code allows changing settings without modifying the app, improving security and flexibility.

3. Final Answer:

   To keep secrets and settings outside the code for security and flexibility -> Option A

4. Quick Check:

   Environment variables = external secrets/settings [OK]

Hint: Environment variables hold secrets outside code [OK]

Common Mistakes:

• Thinking environment variables are for storing user data
• Hardcoding secrets inside source code
• Believing environment variables speed up code execution

2. Which of the following is the correct way to read an environment variable named API_KEY in a Deno script?

easy

A. const key = getenv("API_KEY");

B. const key = process.env.API_KEY;

C. const key = Deno.env.get("API_KEY");

D. const key = env.API_KEY;

Solution

1. Step 1: Recall Deno environment variable syntax

   Deno uses Deno.env.get("NAME") to access environment variables.

2. Step 2: Compare options

   const key = Deno.env.get("API_KEY"); matches Deno syntax; others are from Node.js or incorrect.

3. Final Answer:

   const key = Deno.env.get("API_KEY"); -> Option C

4. Quick Check:

   Deno.env.get("API_KEY") = correct syntax [OK]

Hint: Use Deno.env.get("VAR_NAME") to read env variables [OK]

Common Mistakes:

• Using Node.js syntax like process.env in Deno
• Calling undefined functions like getenv
• Accessing env variables without Deno.env.get

3. Given the following Deno code snippet deployed with environment variable PORT=8080, what will be the output?

const port = Deno.env.get("PORT") || "3000";
console.log(`Server running on port ${port}`);

medium

A. Server running on port 3000

B. Server running on port 8080

C. Server running on port undefined

D. Error: PORT is not defined

Solution

1. Step 1: Check environment variable value

   The environment variable PORT is set to "8080" in deployment.

2. Step 2: Evaluate fallback logic

   The code uses Deno.env.get("PORT") || "3000", so it uses "8080" because PORT exists.

3. Final Answer:

   Server running on port 8080 -> Option B

4. Quick Check:

   PORT=8080 overrides default 3000 [OK]

Hint: Env var set? Use it; else fallback value [OK]

Common Mistakes:

• Assuming fallback value always prints
• Expecting error if env var exists
• Confusing undefined with fallback

4. You deployed a Deno app but reading environment variables returns undefined. Which fix will solve this problem?

medium

A. Restart the app without setting variables

B. Change Deno.env.get to process.env

C. Hardcode variables inside the source code

D. Set environment variables in the deployment platform settings

Solution

1. Step 1: Identify cause of undefined env variables

   Undefined means variables are not set in the deployment environment.

2. Step 2: Apply correct fix

   Setting environment variables in deployment platform ensures Deno.env.get can read them.

3. Final Answer:

   Set environment variables in the deployment platform settings -> Option D

4. Quick Check:

   Env vars must be set in deploy settings [OK]

Hint: Always set env vars in deployment platform [OK]

Common Mistakes:

• Using Node.js syntax in Deno
• Hardcoding secrets instead of setting env vars
• Restarting app without setting variables

5. You want to deploy a Deno app that uses an environment variable MODE to switch between 'development' and 'production'. Which approach correctly uses environment variables to change app behavior safely?

hard

A. Set MODE in deployment settings and use Deno.env.get("MODE") in code to conditionally run features

B. Hardcode const MODE = "production" in source code and redeploy to change

C. Use a config file checked into source with MODE value

D. Ask users to input MODE at runtime every time

Solution

1. Step 1: Understand environment variable usage for modes

   Environment variables allow switching modes without changing code.

2. Step 2: Choose safe and flexible method

   Setting MODE in deployment and reading it with Deno.env.get enables safe conditional logic.

3. Final Answer:

   Set MODE in deployment settings and use Deno.env.get("MODE") in code to conditionally run features -> Option A

4. Quick Check:

   Env vars control modes safely without code changes [OK]

Hint: Use env vars to toggle modes, not hardcoding [OK]

Common Mistakes:

• Hardcoding mode and redeploying for changes
• Storing secrets or modes in config files checked into source
• Asking users to input mode every run