elastic-beanstalk

Name: elastic-beanstalk
Author: awslabs

843stars132forks

How to install elastic-beanstalk?

awslabs/agent-plugins/elastic-beanstalk

$npx -y skills add awslabs/agent-plugins --skill elastic-beanstalk

Installs into the current project.

Summary

Deploy to AWS Elastic Beanstalk. Triggers on: elastic beanstalk, EB, 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. Covers Elastic

Files · 1

View on GitHub

SKILL.md

1	# Elastic Beanstalk
2
3	Deploy web and worker applications to production on AWS with full lifecycle
4	management. Elastic Beanstalk is an application management service: the user
5	provides application code, AWS manages everything underneath (deployment, scaling,
6	patching, monitoring, health response).
7
8	## When to Use
9
10	Elastic Beanstalk is the right choice when:
11
12	- User explicitly asks for Elastic Beanstalk, EB, or a managed application platform
13	- User says "don't want to manage servers", "managed patching", or "Heroku-like"
14	- User is migrating from Heroku, Render, or Railway
15	- User wants AWS to manage ongoing operational lifecycle (patching, scaling,
16	health monitoring, rollback, deployments) after initial setup
17	- App is a web framework, API, or background worker on a standard runtime and
18	the user signals low infrastructure involvement
19
20	Elastic Beanstalk is NOT the right choice when:
21
22	- User explicitly wants serverless/Lambda — this imposes a different programming
23	model (event-driven functions, stateless, cold starts, 15-min max execution)
24	rather than just eliminating server management
25	- User wants fine-grained container orchestration control (use ECS)
26	- User already has Kubernetes expertise and wants direct K8s access (use EKS)
27	- App is a static site or SPA (use Amplify Hosting for the frontend; deploy the
28	backend API separately if present)
29	- User already has ECS task definitions or Fargate configuration
30
31	## Key Distinction
32
33	ECS and EKS are infrastructure management services: the user defines and
34	operates the deployment infrastructure (task definitions, services, clusters,
35	scaling policies) and owns ongoing operational decisions. Elastic Beanstalk is
36	an application management service: the user provides source code or a Docker
37	image, and AWS provisions and operates the production environment on an ongoing
38	basis. The result is the same reliability, but with lower ongoing maintenance
39	cost because operational responsibility stays with the provider.
40
41	Both models support IaC (CDK, CloudFormation, Terraform). The distinction is not
42	about tooling — it is about who manages the lifecycle after deployment.
43
44	Lambda/serverless is a different axis entirely. "Don't want to manage servers"
45	does not mean "wants serverless" — Elastic Beanstalk also eliminates server
46	management while preserving the standard application programming model
47	(long-running processes, persistent connections, threads, local state).
48	Serverless imposes a specific programming model: stateless functions, cold
49	starts, event-driven invocation, and a 15-minute execution ceiling. Route to
50	Lambda only when the user explicitly asks for serverless or the workload is
51	natively event-driven (e.g., S3 triggers, API Gateway request/response with
52	no session state).
53
54	## Workflow
55
56	This skill is invoked after the deploy skill selects Elastic Beanstalk as the
57	deployment target. The deploy skill handles codebase analysis and cost estimation.
58	This skill handles EB-specific configuration:
59
60	1. Map to platform - Select the EB platform branch (see [platforms](references/platforms.md))
61	2. Configure - Environment type (web server or worker), instance size, scaling
62	3. Generate - AWS CLI commands, CDK, or Terraform (see IaC section below)
63	4. Deploy - Execute with user confirmation
64
65	## Defaults
66
67	\| Setting \| Dev \| Production \|
68	\| ------------------------- \| --------------------------------- \| --------------------------------- \|
69	\| Environment type (web) \| Load-balanced (min=1, max=1) \| Load-balanced, Multi-AZ \|
70	\| Environment type (worker) \| Auto Scaling group (min=1, max=1) \| Auto Scaling group (min=2, max=4) \|
71	\| Instance \| t3.small \| t3.medium or larger \|
72	\| Deployments \| All-at-once \| Rolling with additional batch \|
73	\| Health reporting \| Enhanced \| Enhanced \|
74	\| Managed updates \| Enabled (weekly) \| Enabled (maintenance window) \|
75	\| HTTPS (web only) \| ACM certificate + ALB \| ACM certificate + ALB \|
76
77	Default to dev unless user says "production" or "prod".
78
79	Always use load-balanced environments for web server types. This ensures
80	instances stay in private subnets behind an ALB, HTTPS terminates via ACM
81	automatically, and scaling up later is a config change rather than an environment
82	type migration. Dev deployments with min=max=1 cause brief downtime on deploy
83	(single instance, all-at-once). I

People who liked this also viewed

6 picks

Type

elastic-beanstalk

843stars132forks

View on GitHub

How to install elastic-beanstalk?

awslabs/agent-plugins/elastic-beanstalk

$npx -y skills add awslabs/agent-plugins --skill elastic-beanstalk

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Elastic Beanstalk
2
3	Deploy web and worker applications to production on AWS with full lifecycle
4	management. Elastic Beanstalk is an application management service: the user
5	provides application code, AWS manages everything underneath (deployment, scaling,
6	patching, monitoring, health response).
7
8	## When to Use
9
10	Elastic Beanstalk is the right choice when:
11
12	- User explicitly asks for Elastic Beanstalk, EB, or a managed application platform
13	- User says "don't want to manage servers", "managed patching", or "Heroku-like"
14	- User is migrating from Heroku, Render, or Railway
15	- User wants AWS to manage ongoing operational lifecycle (patching, scaling,
16	health monitoring, rollback, deployments) after initial setup
17	- App is a web framework, API, or background worker on a standard runtime and
18	the user signals low infrastructure involvement
19
20	Elastic Beanstalk is NOT the right choice when:
21
22	- User explicitly wants serverless/Lambda — this imposes a different programming
23	model (event-driven functions, stateless, cold starts, 15-min max execution)
24	rather than just eliminating server management
25	- User wants fine-grained container orchestration control (use ECS)
26	- User already has Kubernetes expertise and wants direct K8s access (use EKS)
27	- App is a static site or SPA (use Amplify Hosting for the frontend; deploy the
28	backend API separately if present)
29	- User already has ECS task definitions or Fargate configuration
30
31	## Key Distinction
32
33	ECS and EKS are infrastructure management services: the user defines and
34	operates the deployment infrastructure (task definitions, services, clusters,
35	scaling policies) and owns ongoing operational decisions. Elastic Beanstalk is
36	an application management service: the user provides source code or a Docker
37	image, and AWS provisions and operates the production environment on an ongoing
38	basis. The result is the same reliability, but with lower ongoing maintenance
39	cost because operational responsibility stays with the provider.
40
41	Both models support IaC (CDK, CloudFormation, Terraform). The distinction is not
42	about tooling — it is about who manages the lifecycle after deployment.
43
44	Lambda/serverless is a different axis entirely. "Don't want to manage servers"
45	does not mean "wants serverless" — Elastic Beanstalk also eliminates server
46	management while preserving the standard application programming model
47	(long-running processes, persistent connections, threads, local state).
48	Serverless imposes a specific programming model: stateless functions, cold
49	starts, event-driven invocation, and a 15-minute execution ceiling. Route to
50	Lambda only when the user explicitly asks for serverless or the workload is
51	natively event-driven (e.g., S3 triggers, API Gateway request/response with
52	no session state).
53
54	## Workflow
55
56	This skill is invoked after the deploy skill selects Elastic Beanstalk as the
57	deployment target. The deploy skill handles codebase analysis and cost estimation.
58	This skill handles EB-specific configuration:
59
60	1. Map to platform - Select the EB platform branch (see [platforms](references/platforms.md))
61	2. Configure - Environment type (web server or worker), instance size, scaling
62	3. Generate - AWS CLI commands, CDK, or Terraform (see IaC section below)
63	4. Deploy - Execute with user confirmation
64
65	## Defaults
66
67	\| Setting \| Dev \| Production \|
68	\| ------------------------- \| --------------------------------- \| --------------------------------- \|
69	\| Environment type (web) \| Load-balanced (min=1, max=1) \| Load-balanced, Multi-AZ \|
70	\| Environment type (worker) \| Auto Scaling group (min=1, max=1) \| Auto Scaling group (min=2, max=4) \|
71	\| Instance \| t3.small \| t3.medium or larger \|
72	\| Deployments \| All-at-once \| Rolling with additional batch \|
73	\| Health reporting \| Enhanced \| Enhanced \|
74	\| Managed updates \| Enabled (weekly) \| Enabled (maintenance window) \|
75	\| HTTPS (web only) \| ACM certificate + ALB \| ACM certificate + ALB \|
76
77	Default to dev unless user says "production" or "prod".
78
79	Always use load-balanced environments for web server types. This ensures
80	instances stay in private subnets behind an ALB, HTTPS terminates via ACM
81	automatically, and scaling up later is a config change rather than an environment
82	type migration. Dev deployments with min=max=1 cause brief downtime on deploy
83	(single instance, all-at-once). I

People who liked this also viewed

6 picks

Type