Add AWS deployment assets

[rgarcia]

Summary

• Add a maintained AWS deploy path centered on a hosted CloudFormation Launch Stack quickstart.
• Consolidate AWS deploy assets to CloudFormation only by removing the Terraform wrapper, Packer AMI starter, and duplicate standalone validation script.
• Make the Hypeman host a stack-managed AWS::EC2::Instance so deleting the CloudFormation stack deletes the instance and stack-managed volumes.
• Keep a small custom launch-template resource only for the nested-virtualization CPU option because CloudFormation does not expose that EC2 setting on typed resources yet.
• Provision a separate encrypted EBS data volume, format it as XFS, mount it at /var/lib/hypeman, and validate that mount during bootstrap.
• Strip validated registry Authorization headers before forwarding registry requests so authenticated remote pushes reach the embedded registry cleanly.

Registry auth note

Hypeman has two JWT paths that both remain supported:

• User/API JWTs from hypeman-create-token, used by the CLI for normal remote API access, including hypeman push.
• Registry-scoped JWTs with repo_access or repos plus scope: push, used by the registry auth flow for builder/build access.

The middleware change does not remove registry-scoped push JWT support. For /v2/... requests, JwtAuth first validates registry-scoped tokens with repo/scope checks, then falls back to validating regular user tokens for direct registry access. After either token type is accepted, the request is forwarded without the original Authorization header because Hypeman middleware is the auth boundary; the embedded registry does not understand Hypeman JWTs and can reject requests if the already-validated bearer token is passed through.

Testing

• cfn-lint deploy/aws/cloudformation/template.yaml
• go test ./deploy/aws/cloudformation
• go test ./lib/middleware
• git diff --check
• AWS e2e in us-east-1 from the PR template: launched a temporary CloudFormation stack, confirmed nested-virtualization launch-template creation, waited for bootstrap, verified /var/lib/hypeman mounted as XFS, generated a JWT, called the public health endpoint with bearer auth, installed/configured the CLI, built and pushed a Claude Code Docker image, waited for image import to reach ready, ran it, executed claude --version successfully, stopped/removed the workload, and deleted the stack.

---

Note

Medium Risk
Medium risk because it introduces new AWS CloudFormation infrastructure/bootstrap logic and changes registry request forwarding by stripping Authorization headers, which could affect image push/pull flows if misapplied.

Overview
Adds a maintained AWS deployment path via a new CloudFormation “Launch Stack” template and documentation, including EC2 bootstrap that enables nested virtualization, provisions an encrypted XFS data volume at /var/lib/hypeman, and exposes the API only to a configurable CIDR (optional SSH).

Introduces a Deploy Assets GitHub Actions workflow to cfn-lint/unit test the template on PRs and publish the versioned template to S3 on main.

Adjusts registry-path JWT auth handling to forward validated requests without the incoming Authorization header (helper requestWithoutAuthorization), and updates middleware tests to assert the header is removed.

^{Reviewed by Cursor Bugbot for commit d10fabb. Bugbot is set up for automated code reviews on this repo. Configure here.}

[firetiger-agent]

Firetiger deploy monitoring skipped

This PR didn't match the auto-monitor filter configured on your GitHub connection:

Any PR that changes the kernel API. Monitor changes to API endpoints (packages/api/cmd/api/) and Temporal workflows (packages/api/lib/temporal) in the kernel repo

Reason: PR focuses on deployment infrastructure (CloudFormation, Terraform, Packer assets) rather than changes to API endpoints or Temporal workflows; the middleware header stripping is a utility change, not a kernel API change.

To monitor this PR anyway, reply with @firetiger monitor this.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Autofix Details

Bugbot Autofix prepared a fix for the issue found in the latest run.

• ✅ Fixed: Validation script hardcodes port ignoring configurable ApiPort
  • Updated the bootstrap validation curl URL to use ${ApiPort} so health checks target the configured API port instead of hardcoded 8080.

Or push these changes by commenting:

@cursor push 8e8a84148f

Preview (8e8a84148f)

diff --git a/deploy/aws/single-node/cloudformation/template.yaml b/deploy/aws/single-node/cloudformation/template.yaml
--- a/deploy/aws/single-node/cloudformation/template.yaml
+++ b/deploy/aws/single-node/cloudformation/template.yaml
@@ -410,7 +410,7 @@
         grep -Eq '(^flags|^Features).* (vmx|svm)( |$)' /proc/cpuinfo
         systemctl is-active --quiet hypeman
         token="$(hypeman-create-token validation 1h)"
-        curl -fsS -H "Authorization: Bearer $token" http://127.0.0.1:8080/health >/dev/null
+        curl -fsS -H "Authorization: Bearer $token" http://127.0.0.1:${ApiPort}/health >/dev/null
         echo "hypeman aws single-node validation passed"
         SCRIPT
         chmod 755 /opt/hypeman/deploy/validate.sh

_{You can send follow-ups to the cloud agent here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

Bugbot Autofix prepared a fix for the issue found in the latest run.

• ✅ Fixed: Redundant header clone after r.Clone already copies headers
  • Removed the redundant req.Header = r.Header.Clone() assignment since r.Clone(ctx) already deep-copies headers before deleting Authorization.

Or push these changes by commenting:

@cursor push 50d7e7b0f5

Preview (50d7e7b0f5)

diff --git a/lib/middleware/oapi_auth.go b/lib/middleware/oapi_auth.go
--- a/lib/middleware/oapi_auth.go
+++ b/lib/middleware/oapi_auth.go
@@ -475,7 +475,6 @@
 
 func requestWithoutAuthorization(r *http.Request, ctx context.Context) *http.Request {
 	req := r.Clone(ctx)
-	req.Header = r.Header.Clone()
 	req.Header.Del("Authorization")
 	return req
 }

_{You can send follow-ups to the cloud agent here.}

^{Reviewed by Cursor Bugbot for commit 166500a. Configure here.}

[sjmiller609]

I want to sync on packer -> ami versus startup lambda function

[sjmiller609]

install the native compression libraries used by snapshot compression

[sjmiller609]

wait isn't this the stuff that would run inside of packer build? and basically when AMI is build then launched it comes up with hypeman and everything already installed, systemd unit files set up so that when the machine boots it initializes one time stuff like random JWT secret then starts things up? So all that gets set up in the packer build, then the cloudformation template is just launching the AMI that's ready to go

[sjmiller609]

does this terraform just exist so that someone can deploy via terraform? all it's doing is calling the cloudformation