Introduction

In Elastic Beanstalk, environment variables can be defined through .ebextensions, but where and how you read them depends on what is consuming them. Your application can usually read them as normal process environment variables. Deployment-time shell commands often need a platform-aware way to retrieve the same values reliably.

Define Environment Variables in .ebextensions

A common pattern is to set them with option_settings.

1option_settings:
2  aws:elasticbeanstalk:application:environment:
3    APP_MODE: production
4    API_BASE_URL: https://api.example.com

Place that in a file such as .ebextensions/01-environment.config at the root of the application bundle.

This tells Elastic Beanstalk to create application environment properties for the running environment.

Access Them in the Application

Once set, your app usually reads them through the normal runtime environment.

For Python:

1import os
2
3app_mode = os.environ.get('APP_MODE')
4api_base_url = os.environ.get('API_BASE_URL')
5print(app_mode, api_base_url)

For Node.js:

const appMode = process.env.APP_MODE;
const apiBaseUrl = process.env.API_BASE_URL;
console.log(appMode, apiBaseUrl);

That is the simplest and most common use case.

Access Them During Deployment-Time Commands

The trickier part is accessing those values inside .ebextensions commands or scripts. A reliable platform-aware tool is get-config.

/opt/elasticbeanstalk/bin/get-config environment

You can query a specific variable inside a shell command:

1container_commands:
2  01_show_env:
3    command: |
4      APP_MODE=$(/opt/elasticbeanstalk/bin/get-config environment -k APP_MODE)
5      echo "APP_MODE is $APP_MODE"

This is better than assuming every deployment shell has the exact same exported environment behavior across platform versions.

Understand the Two Contexts

It helps to separate the two places environment variables matter:

• runtime application process
• deployment/configuration scripts

The variable may exist in both contexts, but the access pattern is not always identical. Many Beanstalk problems come from assuming that because the app can read a variable, a shell command in .ebextensions can read it the same way without using Beanstalk's tooling.

Avoid Storing Secrets Directly in Source

Although .ebextensions can define environment properties, it is usually a poor place to hard-code secrets because the configuration is often stored in version control. For secrets, use a safer source such as Parameter Store or Secrets Manager and inject them through a controlled deployment path.

That keeps .ebextensions focused on environment wiring rather than becoming a secret-storage file.

Prefer Clear Ownership of Configuration

A deployment is easier to operate when each variable has one clear source of truth. If some values come from .ebextensions, others from console overrides, and others from scripts, debugging becomes harder because the effective runtime configuration is spread across too many places.

Debug the Active Environment, Not the File Alone

A .config file can look correct in source control and still not be the effective runtime configuration if deployment packaging, environment overrides, or later configuration layers changed the final result. When debugging, verify the running environment in addition to reading the .ebextensions file itself.

That is why environment-variable debugging on Beanstalk is really a deployment-state problem as much as a YAML problem.

Common Pitfalls

• Defining variables in .ebextensions but forgetting that the application still reads them through the normal process environment.
• Assuming deployment-time shell commands see the same environment shape without using get-config.
• Putting secrets directly into version-controlled .ebextensions files.
• Misplacing .ebextensions files so Elastic Beanstalk never processes them.
• Mixing runtime app configuration and deployment-script logic without understanding which context is being debugged.

Summary

• Use .ebextensions option_settings to define environment properties for Elastic Beanstalk.
• Application code usually reads those variables through the normal runtime environment.
• Deployment-time scripts should use /opt/elasticbeanstalk/bin/get-config environment for reliable access.
• Keep secrets out of committed .ebextensions files.
• Most confusion comes from mixing application runtime access with deployment-time shell access.