Environment variables on Deploy in Deno - Deep Dive

Overview - Environment variables on Deploy

What is it?

Environment variables are special values stored outside your code that your program can read when it runs. They hold important information like passwords, API keys, or settings that change depending on where your program runs. When you deploy a Deno app, you use environment variables to keep secrets safe and configure your app without changing its code. This helps your app behave differently in development, testing, or production without rewriting it.

Why it matters

Without environment variables, you would have to hardcode sensitive data like passwords or keys directly in your code. This is risky because anyone with access to the code can see them, and changing settings would require code changes and redeployment. Environment variables let you keep secrets safe and easily change app behavior depending on where it runs, making your deployments secure and flexible.

Where it fits

Before learning environment variables on deploy, you should understand basic Deno programming and how to run Deno apps locally. After this, you can learn about deployment platforms that support Deno, and advanced configuration management techniques like secrets management and config files.

Mental Model

Core Idea

Environment variables are like secret notes you give your app when it starts, telling it important info without writing it in the app itself.

Think of it like...

Imagine you are baking cookies using a recipe, but the oven temperature changes depending on the kitchen you are in. Instead of writing the temperature in the recipe, you get a sticky note from the kitchen owner with the right temperature. This sticky note is like an environment variable — it tells you how to bake without changing the recipe.

┌─────────────────────────────┐
│       Deployment Server      │
│ ┌─────────────────────────┐ │
│ │ Environment Variables    │ │
│ │  - API_KEY=abc123        │ │
│ │  - DB_PASS=secret        │ │
│ └─────────────┬───────────┘ │
│               │             │
│        ┌──────▼──────┐      │
│        │  Deno App   │      │
│        │  Reads vars │      │
│        └─────────────┘      │
└─────────────────────────────┘

Build-Up - 6 Steps

1

Foundation

What are Environment Variables

Concept: Introduce environment variables as external key-value pairs that programs can read at runtime.

Environment variables are like settings stored outside your program. They hold data such as usernames, passwords, or configuration options. Your Deno app can read these values when it starts, so you don't have to write them directly in your code.

Result

You understand that environment variables are separate from code and can be used to configure your app safely.

Knowing that environment variables live outside your code helps you keep secrets safe and makes your app flexible across different environments.

2

Foundation

Accessing Environment Variables in Deno

Concept: Learn how to read environment variables inside a Deno program using Deno.env API.

In Deno, you can read environment variables using Deno.env.get('VARIABLE_NAME'). For example, Deno.env.get('API_KEY') returns the value of API_KEY if set. You must run Deno with the --allow-env flag to access environment variables for security reasons.

Result

You can write code that reads environment variables and uses their values.

Understanding how to access environment variables in Deno is essential to use them effectively and securely.

3

Intermediate

Setting Environment Variables Locally

Concept: Learn how to set environment variables on your local machine for testing your Deno app.

On your computer, you can set environment variables before running your app. For example, on Linux or Mac, you can run: API_KEY=abc123 deno run --allow-env app.ts. On Windows PowerShell, use: $env:API_KEY='abc123'; deno run --allow-env app.ts. This way, your app reads the API_KEY variable when it runs.

Result

You can test your app locally with different environment variables without changing code.

Knowing how to set environment variables locally prepares you for deploying your app with different settings.

4

Intermediate

Using Environment Variables on Deployment

🤔Before reading on: do you think environment variables are set inside your code or on the server where your app runs? Commit to your answer.

Concept: Understand that environment variables are configured on the deployment platform, not inside your app code.

When you deploy your Deno app to a server or cloud platform, you set environment variables in the platform's settings or configuration. Your app reads these variables at runtime. This keeps secrets out of your code and lets you change settings without redeploying code.

Result

You know that deployment platforms provide ways to set environment variables securely and separately from your code.

Recognizing that environment variables live on the deployment environment helps you separate code from configuration and keep secrets safe.

5

Advanced

Security Best Practices for Environment Variables

🤔Before reading on: do you think committing environment variables to public code repositories is safe? Commit to your answer.

Concept: Learn why environment variables must never be committed to public code and how to manage secrets securely.

Never write secrets like passwords or API keys directly in your code or commit them to public repositories. Use environment variables to keep them outside code. Use deployment platform secret managers or encrypted storage to set environment variables securely. Rotate keys regularly and restrict access to environment variables.

Result

You understand how to protect sensitive data and avoid common security mistakes.

Knowing security best practices prevents leaks of sensitive data and protects your app and users.

6

Expert

Advanced Environment Variable Management on Deploy

🤔Before reading on: do you think environment variables can be changed while the app is running without restarting? Commit to your answer.

Concept: Explore how environment variables behave at runtime and advanced patterns like dynamic config and secret injection.

Environment variables are read once when the app starts; changing them on the server does not affect running apps until restart. For dynamic config, use external config services or reload mechanisms. Some platforms offer secret injection or vault integration to manage secrets securely and update them without redeploying. Understanding these patterns helps build robust, secure apps.

Result

You grasp the limits of environment variables and how to handle advanced configuration needs in production.

Understanding environment variable lifecycle and advanced secret management helps build scalable and secure deployed apps.

Under the Hood

When a Deno app starts, the runtime reads environment variables from the operating system's environment block. These variables are stored as key-value pairs accessible via Deno.env.get(). The app cannot change these variables at runtime; they are fixed for the process lifetime. The --allow-env flag controls permission to access these variables for security. Deployment platforms inject these variables into the environment before starting the app process.

Why designed this way?

Environment variables were designed as a simple, OS-level way to pass configuration to programs without changing code. This separation improves security and flexibility. Deno enforces explicit permission (--allow-env) to prevent accidental leaks or misuse of environment data, reflecting modern security best practices. Alternatives like config files or hardcoded values were less secure or less flexible.

┌───────────────┐
│ Operating Sys │
│ Environment   │
│ Variables     │
└──────┬────────┘
       │ Injected at process start
┌──────▼────────┐
│  Deno Runtime │
│  (with --allow-env) │
└──────┬────────┘
       │ Provides access
┌──────▼────────┐
│  Deno App     │
│  Reads vars   │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: do you think environment variables can be changed inside a running Deno app and the app will see the change immediately? Commit to yes or no.

Common Belief: Environment variables can be updated anytime during app execution and the app will see the new values immediately.

Reality: Environment variables are read once when the app starts and cannot be changed during runtime for that process.

Why it matters: Expecting dynamic changes can cause bugs if the app relies on environment variables to update without restart.

Quick: do you think storing secrets like API keys directly in code is safe if the repo is private? Commit to yes or no.

Common Belief: It's safe to put secrets in code if the repository is private and access is limited.

Reality: Storing secrets in code risks accidental leaks through backups, forks, or insider access; environment variables keep secrets separate and safer.

Why it matters: Hardcoded secrets can leak and cause security breaches, even from private repos.

Quick: do you think environment variables are part of your Deno app's source code? Commit to yes or no.

Common Belief: Environment variables are stored inside the app's source code files.

Reality: Environment variables live outside the source code, in the OS or deployment environment.

Why it matters: Confusing this leads to mixing code and config, reducing security and flexibility.

Quick: do you think you can access environment variables in Deno without any special permissions? Commit to yes or no.

Common Belief: Deno apps can freely access environment variables without extra flags or permissions.

Reality: Deno requires the --allow-env flag to access environment variables for security reasons.

Why it matters: Not knowing this causes permission errors and confusion when running Deno apps.

Expert Zone

1

Environment variables are process-level and cannot be shared or updated across multiple running instances without orchestration.

2

Using environment variables for complex configuration can become unwieldy; combining them with config files or services is common in production.

3

Deno's explicit permission model (--allow-env) is a security feature that differs from many runtimes, requiring deliberate access to environment data.

When NOT to use

Avoid using environment variables for large or complex configuration data; instead, use configuration files, databases, or dedicated config services. For secrets that require rotation or audit, use secret management tools like HashiCorp Vault or cloud provider secret managers integrated with your deployment platform.

Production Patterns

In production, environment variables are set via deployment platform dashboards, CLI tools, or infrastructure as code scripts. Secrets are injected securely and rotated regularly. Apps read these variables at startup, and orchestration tools restart apps to apply changes. Combining environment variables with config files or remote config services allows dynamic behavior without redeployment.

Connections

12-Factor App Methodology

Environment variables are a core part of the 12-Factor App's config principle.

Understanding environment variables helps grasp how modern apps separate config from code for portability and security.

Operating System Processes

Environment variables are managed by the OS and passed to processes at start.

Knowing OS process environment behavior clarifies why environment variables are fixed during runtime.

Secrets Management in Cybersecurity

Environment variables are one method to handle secrets securely in software systems.

Learning environment variables connects to broader security practices of protecting sensitive data in applications.

Common Pitfalls

#1 Hardcoding secrets directly in source code.

Wrong approach:

const API_KEY = "mysecretapikey123";
console.log(API_KEY);

Correct approach:

const API_KEY = Deno.env.get("API_KEY");
console.log(API_KEY);

Root cause:

Misunderstanding that secrets should be kept outside code to avoid leaks and ease configuration.

#2 Running Deno app without --allow-env flag and expecting environment variables to be accessible.

Wrong approach:

deno run app.ts # No --allow-env flag
// Inside app.ts: Deno.env.get('API_KEY') returns undefined or error

Correct approach:

deno run --allow-env app.ts
// Inside app.ts: Deno.env.get('API_KEY') returns the correct value

Root cause:

Not knowing Deno's security model requires explicit permission to access environment variables.

#3 Expecting environment variable changes on the server to reflect immediately in a running app.

Wrong approach:

Change environment variable on server
// App continues using old value without restart

Correct approach:

Change environment variable on server
Restart app process to load new values

Root cause:

Not understanding environment variables are loaded once at process start and do not update dynamically.

Key Takeaways

Environment variables store important configuration and secrets outside your code, keeping apps secure and flexible.

In Deno, you access environment variables using Deno.env.get() and must run with --allow-env permission.

Deployment platforms let you set environment variables separately from code, enabling different settings per environment.

Environment variables are fixed at app start and cannot be changed dynamically without restarting the app.

Following security best practices with environment variables prevents accidental leaks and protects your application.

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