infra

infra/ — pixieengine.com static site (AWS CDK, Civet)

Sources are Civet (bin/, lib/, functions/, build.civet, validate-template.civet). build.civet (esbuild + @danielx/civet) compiles them to dist/ — the CDK app to dist/pixie.cjs and each functions/*.civet to a standalone dist/functions/*.js (CloudFront JS_2_0-safe). cdk.json runs the build automatically on every cdk command, so there's no separate build step; dist/ is gitignored.

Greenfield CDK stack for the static archive. Entirely separate from the legacy distribution E3BKYYG8EH9O0K (which serves pixieengine.com today and is never touched by this stack). Cutover = move the DNS alias to the new distribution.

What it creates (PixieStaticStack, us-east-1)

• S3 bucket pixieengine-static — private (CloudFront OAC only), RETAIN (content survives cdk destroy).
• CloudFront Function pixieengine-rewrite (compiled from functions/rewrite.civet → dist/functions/rewrite.js; unit-tested via npm test).
• OAC + bucket policy (auto-managed by CDK since the bucket is stack-owned).
• CloudFront distribution: function on viewer-request, index.html root, 403/404 → /410/index.html served as 404 (CloudFront's custom-error responses don't allow a 410 code; both still de-index in Google).
• (withDomain only) ACM cert (DNS-validated via the existing zone) + pixieengine.com alias + Route 53 A/AAAA records.
• pixie-deploy IAM role (assumed by the pixie-ops user) with read/write on the bucket, cloudfront:CreateInvalidation on the dist, and scoped backup-recovery access. No long-lived deploy key — content deploys assume the role for short-lived STS creds.

Prereqs

• Node 18+. cdk synth/diff need no creds.
• cdk deploy runs locally as the pixie-ops profile (scoped to sts:AssumeRole on the CDK bootstrap roles): npx cdk deploy --profile pixie-ops. See "Credentials" below.
• One-time per account/region: npx cdk bootstrap aws://<account>/us-east-1 — needs admin (run in CloudShell), since pixie-ops can only assume the bootstrap roles, not create them. Already bootstrapped for this account, so normally skip it.
• npm install in this dir.

Credentials (~/.aws/credentials)

[pixie-ops]                       # the only static key — low-privilege (assume CDK + deploy roles)
aws_access_key_id = AKIA...
aws_secret_access_key = ...

[pixie-deploy]                    # keyless — assumes the role via pixie-ops; auto-refreshed STS creds
role_arn = arn:aws:iam::186123361267:role/pixie-deploy
source_profile = pixie-ops
region = us-east-1

cdk deploy uses --profile pixie-ops; content syncs/invalidations use --profile pixie-deploy. Nothing needs re-pasting across key rotations or stack updates — the role ARN is stable.

Bootstrap from CloudShell (one-time, admin only)

Deploys run locally as pixie-ops (below); only the one-time cdk bootstrap needs admin, since pixie-ops can assume the bootstrap roles but not create them. This account is already bootstrapped, so you normally skip this section. If you ever need to re-bootstrap: CloudShell starts empty, so get this infra/ dir there. Either:

• git (if the repo is reachable): commit + push infra/ (it's self-contained — includes functions/*.civet; npm install pulls the build deps), then in CloudShell git clone <repo> && cd pixieengine.com/infra, or
• upload: CloudShell → Actions → Upload file → a zip of infra/.

Then (CloudShell uses your console admin identity, no profile flag needed):

cd infra && npm install
npx cdk bootstrap aws://186123361267/us-east-1   # once per account/region

Deploy — Phase 1 (test, no custom domain)

cd infra
npm install
npx cdk deploy --profile pixie-ops    # creates bucket + dist + function (alias NOT attached yet)

Note the DistributionDomain output (dXXXX.cloudfront.net).

Then populate the new bucket (content is NOT managed by CDK — it's a deploy step), syncing the generated tree with the deploy profile:

aws s3 sync ../static-site/public s3://pixieengine-static --profile pixie-deploy
aws cloudfront create-invalidation --distribution-id <DistributionId> --paths "/*" --profile pixie-deploy

Test everything on https://dXXXX.cloudfront.net/ — gallery, slug URLs, ?tagged= 301, missing→404, replay, tune.

Deploy — Phase 2 (cutover)

A CloudFront alias can only exist on one distribution. So:

1. Remove the pixieengine.com alias (CNAME) from the legacy dist E3BKYYG8EH9O0K (console).
2. Add it to the new dist + create cert + DNS:

   npx cdk deploy -c withDomain=true --profile pixie-ops   # ACM cert, alias, Route 53 A/AAAA -> new dist

   (The ACM DNS validation auto-creates a CNAME in the zone; first deploy waits for it.)
3. Verify https://pixieengine.com/.

Rollback

Re-point the pixieengine.com Route 53 alias back to the legacy dist (or re-add the alias there). Nothing in the legacy distribution was modified, so rollback is just DNS.

Ongoing content deploys

aws s3 sync ../static-site/public s3://pixieengine-static --delete --profile pixie-deploy then a CloudFront invalidation.