Add AWS Lambda deployment target

[busla]

What

Adds lambda.ts, a serverless entry point for running the admin panel as a single AWS Lambda. The handler detects the incoming event shape and supports both:

• a Lambda Function URL / API Gateway HTTP API (payload format 2.0)
• an Application Load Balancer target (target_type = lambda)

The same Lambda serves both the server routes and the static client assets, so no CDN or S3 bucket is required — the deployed zip is self-contained.

Why

The panel currently ships only the long-running server.ts / Docker deployment. This adds a zero-infrastructure serverless option for teams that prefer to run it as a Lambda.

Usage

bun run build:lambda     # outputs dist/lambda/{index.mjs, client/}

Zip the contents of dist/lambda/ and deploy with handler index.handler on a Node.js runtime. Set the runtime environment variables used by the Docker deployment (SESSION_SECRET, VITE_API_BASE_URL, ADMIN_SSO_*, SESSION_COOKIE_SECURE, VITE_BASE_PATH, etc.). A GET /health route returns 200 ok for health checks.

Changes

• lambda.ts — the handler:
  • detects ALB (requestContext.elb) vs. payload-2.0 events and replies in the matching format (statusDescription + multiValueHeaders for ALB; headers + cookies[] for HTTP API)
  • builds a Web Request from the event and delegates dynamic routes to the existing fetch handler
  • serves dist/client assets directly (immutable caching, gzip for compressible types, path-traversal guarded)
  • honors VITE_BASE_PATH: serves assets only under the prefix and redirects the bare base path to its trailing-slash form, matching server.ts
  • applies the same security headers as server.ts (CSP report-only/enforced, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, HSTS in production) to text/html responses
• package.json — build:lambda script bundles handler + client into dist/lambda/.
• tsconfig.json — excludes lambda.ts (consistent with server.ts; it imports the built server bundle).
• README.md — documents both deployment paths and their caveats.

Notes

• Static serving from a Lambda is for simplicity, not a production ideal — in production you would normally front it with a CDN (or S3 + CloudFront) serving dist/client directly. The inline serving keeps the deploy to a single self-contained zip.
• ALB targets: enable multi-value headers on the target group so multiple Set-Cookie headers survive; ALB caps responses at 1 MB (gzip keeps assets under it).
• The Prometheus /metrics endpoint is not exposed by the Lambda — pull-model metrics don't fit Lambda's ephemeral instances; use CloudWatch / a push exporter instead.
• No new runtime dependencies.

[CLAassistant]

All committers have signed the CLA.

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 3 potential issues.

^{Reviewed by Cursor Bugbot for commit 03c7652. Configure here.}