# Elastic Beanstalk

Deploy to AWS Elastic Beanstalk, in either Beanstalk Standard mode (EC2) or Beanstalk...

- Repository: https://github.com/awslabs/agent-plugins (933 stars)
- Category: DevOps
- License: Apache-2.0
- Last updated: 2026-10-15
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add awslabs/agent-plugins --skill elastic-beanstalk -g -a claude-code -y`
Codex: `npx skills add awslabs/agent-plugins --skill elastic-beanstalk -g -a codex -y`
Cursor: `npx skills add awslabs/agent-plugins --skill elastic-beanstalk -g -a cursor -y`
Gemini CLI: `npx skills add awslabs/agent-plugins --skill elastic-beanstalk -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add awslabs/agent-plugins`

## Description

Deploy to AWS Elastic Beanstalk, in either Beanstalk Standard mode (EC2) or Beanstalk Cluster mode (managed EKS). Triggers on: elastic beanstalk, EB, beanstalk standard, beanstalk cluster, managed EC2 platform, web app with managed patching, worker on EC2, Heroku alternative, don't want to manage servers or container orchestration, migrate from Heroku, managed operational lifecycle, containerised app without operating Kubernetes, several services sharing a managed cluster, managed EKS without kubectl. Covers web and worker applications on EC2, and containerised single- and multi-service applications on managed EKS.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Elastic Beanstalk

Deploy applications to production on AWS with full lifecycle management. Elastic
Beanstalk is an application management service: the user provides application
code or a container image, AWS manages everything underneath (deployment,
scaling, patching, monitoring, health response).

There are two modes, and the choice determines every setting that follows.
**Standard** runs the application on Amazon EC2; **Cluster** runs a container on
a managed Amazon EKS Auto Mode cluster. See [Choose the Mode](#choose-the-mode).

## When to Use

Elastic Beanstalk is the right choice when:

- User explicitly asks for Elastic Beanstalk, EB, or a managed application platform
- User says "don't want to manage servers", "managed patching", or "Heroku-like"
- User is migrating from Heroku, Render, or Railway
- User wants AWS to manage ongoing operational lifecycle (patching, scaling,
  health monitoring, rollback, deployments) after initial setup
- App is a web framework, API, or background worker on a standard runtime and
  the user signals low infrastructure involvement

Elastic Beanstalk is NOT the right choice when:

- User explicitly wants serverless/Lambda, this imposes a different programming
  model (event-driven functions, stateless, cold starts, 15-min max execution)
  rather than just eliminating server management
- User wants fine-grained container orchestration control (use ECS)
- User already has Kubernetes expertise and wants direct K8s access (use EKS)
- App is a static site or SPA (use Amplify Hosting for the frontend; deploy the
  backend API separately if present)
- User already has ECS task definitions or Fargate configuration

## Key Distinction

The rest: https://github.com/awslabs/agent-plugins/blob/HEAD/plugins/deploy-on-aws/skills/elastic-beanstalk/SKILL.md