Skip to content
Back to main site

AWS CodeDeploy

Create and inspect application, deployment-group and deployment records.

Plan: Pro47 of 47 operations implemented3Known differences

Deployments report synthetic success without proving that a revision ran on a host.

Example checked on Vera 1.2.2, 8 November 2026. Each coverage note names its own evidence and date.

Activate your license key and start the emulator with the Vera launcher, as in Activate Pro, then run this in a terminal of its own, from an empty scratch directory. It gives the official AWS CLI dummy credentials and a config file of its own, so no AWS account is needed and your own AWS profile isn't touched.

Terminal window
export VERA_ENDPOINT="http://localhost:5003"
export AWS_ACCESS_KEY_ID=test AWS_SECRET_ACCESS_KEY=test
export AWS_REGION=us-east-1 AWS_DEFAULT_REGION=us-east-1
export AWS_SHARED_CREDENTIALS_FILE=/dev/null
export AWS_EC2_METADATA_DISABLED=true
export AWS_PAGER="" AWS_CLI_AUTO_PROMPT=off
unset AWS_PROFILE AWS_DEFAULT_PROFILE
unset AWS_SESSION_TOKEN AWS_SECURITY_TOKEN
unset AWS_WEB_IDENTITY_TOKEN_FILE AWS_ROLE_ARN AWS_ROLE_SESSION_NAME
unset AWS_CONTAINER_CREDENTIALS_FULL_URI
unset AWS_CONTAINER_CREDENTIALS_RELATIVE_URI
cat > vera-aws-config <<'EOF'
[default]
region = us-east-1
output = json
cli_binary_format = base64
s3 =
addressing_style = path
EOF
export AWS_CONFIG_FILE="$PWD/vera-aws-config"

When you've finished every example in this terminal, close it and delete vera-aws-config, not before.

Use the AWS CLI’s deploy commands: the CLI calls CodeDeploy deploy, not codedeploy. The emulator serves the 2014-10-06 API over the AWS JSON protocol, and the examples use us-east-1.

A deployment group needs a service role from the emulator’s IAM. In Vera 1.2.2, deployment-group metadata worked with a freshly created role. The example below uses an application only, which needs no role.

Create an application for the Server compute platform and read it back:

Terminal window
aws --endpoint-url "$VERA_ENDPOINT" deploy create-application \
--application-name docs-example-application --compute-platform Server
aws --endpoint-url "$VERA_ENDPOINT" deploy get-application \
--application-name docs-example-application

These are selected fields from the last command’s output. Generated values, such as the application’s ID and creation time, aren’t shown: they differ on every run.

Output (selected fields)
{
"application": {
"applicationName": "docs-example-application",
"linkedToGitHub": false,
"computePlatform": "Server"
}
}

To clean up, delete the application:

Terminal window
aws --endpoint-url "$VERA_ENDPOINT" deploy delete-application \
--application-name docs-example-application
  • Applications, created for a compute platform, read back and deleted.
  • Deployment groups. In Vera 1.2.2, deployment-group metadata worked with a freshly created IAM role. In a separate check of Vera 1.2.0 preview, with a role record that already existed in the emulator, CreateDeploymentGroup accepted ec2TagFilters as the list AWS defines, GetDeploymentGroup returned the same list, and DeleteDeploymentGroup deleted the group.
  • Deployment records. With a ZIP in the emulator’s S3 holding a valid appspec.yml, and a group whose EC2 tag filter matched no registered host, CreateDeployment returned a Succeeded deployment at once. Its create, start and completion times were identical, its overview counted one successful target, and ListDeploymentTargets returned one target whose ID was the deployment’s own ID. See Limitations.
  • Listed in the earlier implementation inventory; not rechecked since: deployment configurations, application revisions, deployment instances, on-premises instances, GitHub account tokens and tags.

The main limits are below. A few more apply to every service, and the API coverage notes cover smaller differences.

  • Deployment success is synthetic. A deployment is Succeeded at once, with a target made up from its own ID, even when no host matches. No revision ran on a host, and no host agent, lifecycle hooks, traffic shift or rollback was established.
  • Deployment settings weren’t tested. Service role checks, deployment limits and state changes over time weren’t tried.

Every operation in AWS's published 2014-10-06 API (SDK model, botocore 1.43.105), and whether the emulator implements it. Availability combines the earlier implementation inventory with the dated observations below; checking a page's example does not verify every operation. Each note names its evidence first; an observation given without a build or date comes from earlier testing, on 3 November 2026. What the statuses mean

OperationStatusNotes
AddTagsToOnPremisesInstancesImplemented
BatchGetApplicationRevisionsImplemented
BatchGetApplicationsImplemented
BatchGetDeploymentGroupsImplemented
BatchGetDeploymentInstancesImplemented
BatchGetDeploymentTargetsImplemented
BatchGetDeploymentsImplemented
BatchGetOnPremisesInstancesImplemented
ContinueDeploymentImplemented
CreateApplicationImplementedLocal observation: Vera 1.2.0 preview, 5 November 2026 — created the example's Server application.
CreateDeploymentKnown differenceLocal observation: Vera 1.2.0 preview, 5 November 2026 — with a ZIP in local S3 holding a valid appspec.yml, and a group whose EC2 tag filter matched no registered host, returned a Succeeded deployment at once, with identical creation, start and completion times and one successful target in its overview. No revision ran on a host. Source inspection: This path does not execute revisions, host lifecycle hooks or traffic shifts.
CreateDeploymentConfigImplemented
CreateDeploymentGroupImplementedLocal observation: Vera 1.2.2, 8 November 2026 — deployment-group metadata worked with a freshly created IAM role. Local observation: Vera 1.2.0 preview, 5 November 2026 — accepted ec2TagFilters as the list AWS defines, with Key, Value and Type KEY_AND_VALUE, using an IAM role record that already existed, since creating a role failed in that release.
DeleteApplicationImplementedLocal observation: Vera 1.2.0 preview, 5 November 2026 — deleted the example's application.
DeleteDeploymentConfigImplemented
DeleteDeploymentGroupImplementedLocal observation: Vera 1.2.0 preview, 5 November 2026 — deleted a group created with a role record that already existed.
DeleteGitHubAccountTokenImplemented
DeleteResourcesByExternalIdImplemented
DeregisterOnPremisesInstanceImplemented
GetApplicationImplementedLocal observation: Vera 1.2.0 preview, 5 November 2026 — read the example's application back.
GetApplicationRevisionImplemented
GetDeploymentKnown differenceLocal observation: Vera 1.2.0 preview, 5 November 2026 — returned that deployment as Succeeded, with identical creation, start and completion times, though no host matched its group. Source inspection: Returns stored synthetic deployment state; a Succeeded result does not establish that revision contents, lifecycle hooks or traffic shifts ran.
GetDeploymentConfigImplemented
GetDeploymentGroupImplementedLocal observation: Vera 1.2.0 preview, 5 November 2026 — returned the group's ec2TagFilters list as sent, for a group created with a role record that already existed.
GetDeploymentInstanceImplemented
GetDeploymentTargetImplemented
GetOnPremisesInstanceImplemented
ListApplicationRevisionsImplemented
ListApplicationsImplemented
ListDeploymentConfigsImplemented
ListDeploymentGroupsImplemented
ListDeploymentInstancesImplemented
ListDeploymentTargetsKnown differenceLocal observation: Vera 1.2.0 preview, 5 November 2026 — returned one synthetic target whose ID was the deployment's own ID, though no host matched the group. No EC2 instance or agent was discovered.
ListDeploymentsImplemented
ListGitHubAccountTokenNamesImplemented
ListOnPremisesInstancesImplemented
ListTagsForResourceImplemented
PutLifecycleEventHookExecutionStatusImplemented
RegisterApplicationRevisionImplemented
RegisterOnPremisesInstanceImplemented
RemoveTagsFromOnPremisesInstancesImplemented
SkipWaitTimeForInstanceTerminationImplemented
StopDeploymentImplemented
TagResourceImplemented
UntagResourceImplemented
UpdateApplicationImplemented
UpdateDeploymentGroupImplemented