dropthejase puts Mike on AWS Lambda

The fork repackages Mike's backend to run as a serverless function inside Amazon's cloud rather than as a long-running server.

infrastructure

dropthejase has rebuilt Mike to live inside AWS Lambda - Amazon's serverless compute service, which runs code in short bursts only when a request comes in. The pieces fit together cleanly: an API gateway sits in front, AWS Secrets Manager hands over credentials when the function first wakes up, and S3 (Amazon's object storage) takes over files from the original setup. Authentication now leans on AWS-issued identity claims rather than Mike's default login layer.

It's a foundational shift, not a user-facing feature, and it's specific enough that another fork couldn't lift it wholesale - the auth and storage choices are wired to AWS-only paths. But the shape of the migration is instructive: the team kept the local development path intact while bolting on a parallel cloud path, so contributors can still run Mike on a laptop.

So what For anyone weighing how to host a legal-AI tool inside their firm or product, this is a working blueprint for running Mike serverlessly on AWS instead of on a dedicated server.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?

Commits in this thread

12 commits from dropthejase/louis, oldest first. Source extracted verbatim from the harvested git log.

SHA	Subject	Author	Date
`c6ff8a18`	chore(backend): add Lambda + Powertools + Bedrock deps	Jason Lee	2026-05-06	↗ GitHub
`472e65ec`	chore(backend): ensure CommonJS output and add build:lambda script	Jason Lee	2026-05-06	↗ GitHub
`e2da4284`	refactor(backend): extract app.ts - shared Express app for local dev and Lambda	Jason Lee	2026-05-06	↗ GitHub
`c3c58397`	feat(backend): add lambda.ts - serverless-http + Powertools handler	Jason Lee	2026-05-06	↗ GitHub
`6afb46e7`	feat(backend): add secrets.ts - Secrets Manager cold-start loader for Supabase creds	Jason Lee	2026-05-06	↗ GitHub
`f2278ac8`	feat(backend): auth middleware - prod reads API Gateway context; dev falls back to Supabase getUser	Jason Lee	2026-05-06	↗ GitHub
`ab6f4e58`	feat(backend): storage.ts - S3 IAM role in Lambda, R2 fallback for local dev	Jason Lee	2026-05-06	↗ GitHub
`4c11ec5e`	feat(backend): Dockerfile.lambda - arm64 Lambda container for Express app	Jason Lee	2026-05-06	↗ GitHub
`ea417f3b`	feat(backend): Dockerfile.lambda - arm64 Lambda container for Express app	Jason Lee	2026-05-06	↗ GitHub
`4536d02b`	docs(backend): add .env.lambda.example documenting Lambda env vars	Jason Lee	2026-05-06	↗ GitHub
`eef3665b`	Merge feature/backend-migration: Express → Lambda (serverless-http, Bedrock, S3, auth)	Jason Lee	2026-05-06	↗ GitHub
`c96d725d`	refactor(backend): auth middleware Lambda-only, drop Supabase fallback; storage S3-only, drop R2 fallback	Jason Lee	2026-05-07	↗ GitHub
commit body Auth middleware now returns 401 immediately if the API Gateway authorizer context is absent, removing the Supabase getUser() local dev path and the @supabase/supabase-js import. Storage is simplified to a single S3Client using the IAM role; removes isLambda() branching, R2 env vars, and the storageEnabled export.

Capture this thread into my fork

Download a single Markdown prompt that tells Claude how to port every commit above into your working tree — adapting paths and structure to match your repo. Run it via claude -p < capture-thread-328.md from inside the repo you want the changes in.

⬇ Download capture-thread-328.md