Introduction

In Elastic Beanstalk .ebextensions, commands and container_commands run at different points in the deployment lifecycle. The short answer is that commands are for early instance-level setup, while container_commands are for application-level work after your source bundle has been unpacked into the staging area.

Using the wrong section causes predictable problems: package installs run too late, application build steps run before source files exist, or database migrations run more times than expected. Understanding the deployment phase is the real key here.

What commands Are For

commands run early during instance provisioning, before the application is deployed. They run as root, and they are best suited for machine setup tasks.

Typical examples include:

• installing OS packages
• writing system configuration files
• creating directories or system users
• changing permissions for instance-level resources

Example:

1commands:
2  01_install_jq:
3    command: "yum install -y jq"
4  02_make_log_dir:
5    command: "mkdir -p /opt/myapp/logs"

These commands are about preparing the environment the app will run in, not manipulating the staged application source code.

What container_commands Are For

container_commands run later, after Elastic Beanstalk has extracted your application into a staging directory but before it is deployed to the final live location. This is the right place for tasks that need the application files.

Typical examples include:

• building frontend assets
• collecting static files
• compiling templates
• running application-specific setup against staged code
• running one-time deployment tasks such as migrations

Example:

1container_commands:
2  01_install_node_deps:
3    command: "npm ci"
4  02_build_assets:
5    command: "npm run build"
6  03_migrate:
7    command: "python manage.py migrate"
8    leader_only: true

Because these run against the staged application bundle, they can safely reference files in your project.

The Most Important Practical Difference

If a command needs your application source tree, it almost certainly belongs in container_commands, not commands.

For example, this is a mistake:

commands:
  01_collect_static:
    command: "python manage.py collectstatic --noinput"

At the commands phase, the deployment may not yet have the staged app code in the location you expect. That is why application build steps tend to fail there.

The corrected version is:

container_commands:
  01_collect_static:
    command: "python manage.py collectstatic --noinput"

leader_only Matters for Shared Deployments

One especially important container_commands feature is leader_only. On environments with multiple instances, this lets one instance perform a task that should not run everywhere.

Database migrations are the classic example:

1container_commands:
2  01_migrate:
3    command: "python manage.py migrate"
4    leader_only: true

If you put a migration in plain container_commands without leader_only, every instance may attempt to run it during deployment.

Think in Terms of Machine Setup Versus App Setup

A useful mental model is:

• 'commands prepare the server'
• 'container_commands prepare the app release'

That phrasing is often easier to remember than the full Beanstalk lifecycle details. It also helps during code review because you can ask whether a script is operating on the machine or on the staged application.

Common Pitfalls

• Putting application build steps in commands before the source bundle is staged.
• Installing system packages in container_commands instead of doing that machine setup earlier.
• Forgetting leader_only for migrations or other one-time deployment actions.
• Assuming both sections run from the same directory and with the same purpose.
• Writing non-idempotent commands that break on redeploys or instance replacement.

Summary

• Use commands for early instance-level setup such as OS packages and system configuration.
• Use container_commands for tasks that need the staged application code.
• If a script references project files like manage.py or package.json, it usually belongs in container_commands.
• Use leader_only for one-time tasks in multi-instance environments.
• The simplest rule is machine setup first with commands, app setup later with container_commands.