Fast-Track to Serverless Mastery: What I Took Away from StackGen at devinfradays
A hands-on serverless workshop at Radisson Blu by StackGen - deploying AWS Lambda and API Gateway in under an hour. My notes as someone who runs 711 FastAPI endpoints and Celery workers in production.
I spent a morning at the StackGen devinfradays workshop at Radisson Blu, Bengaluru - "Fast-Track to Serverless Mastery: Deploy Serverless Applications in Minutes." Here are my notes, filtered through the lens of someone who runs 711 FastAPI endpoints and a fleet of Celery workers in production every day.
#What the workshop covered
The session was hands-on from the start. We went from zero to a working AWS Lambda function behind API Gateway in under 45 minutes. The demo stack:
- AWS Lambda (Python 3.12) as the compute unit
- API Gateway as the HTTP front door
- GitHub Actions for CI/CD - push to main, action zips and deploys
- IAM roles scoped tightly per function
The GitHub Actions pipeline was the part that impressed me most. The deploy step was genuinely clean - zip the handler, call aws lambda update-function-code, and Lambda versioning gives you instant rollback with a single alias pointer swap. No Docker, no Compose, no server to SSH into.
#Workshop Highlights & Live Sessions
Here are a few moments from the live demonstration and hands-on coding session at Radisson Blu:
#Where it fits (and where it does not) in the work I do
I build and operate Opaeron - a multi-tenant AI operations platform at roughly 226,000 lines of code, 711 API endpoints across 89 routers, and about 20 AI agents running on Celery workers. Sitting through this workshop made me think hard about where the serverless boundary actually should sit in a system like that.
The cold-start problem for LLM work
The real constraint for serverless in AI applications is cold-start latency. On Python 3.12 with a small deployment package, a cold start lands at 400 ms to 1.2 seconds without Provisioned Concurrency. That is acceptable for a webhook handler. It is not acceptable for a user-facing LLM endpoint where the model load alone already costs time.
The agents in Opaeron run for 10 to 90 seconds depending on complexity - well within Lambda's 15-minute ceiling on paper, but the cold-start penalty on the first invocation per burst is a UX problem at the front of a streaming response.
What I would actually use serverless for
- Inbound webhook handlers (Slack events, GitHub hooks, CRM triggers)
- Scheduled jobs that run once a day and finish in under 5 minutes
- Lightweight pre-processing: sanitise input, validate schema, queue to SQS
- Low-traffic public APIs where paying for idle server time is wasteful
What I would keep on persistent workers
- LLM inference endpoints (long connection, streaming, model in memory)
- Celery agent tasks (30 to 90 seconds, stateful context across tool calls)
- pgvector queries (connection pooling, warm connections matter for latency)
- Any task that holds large model weights in memory between calls
#The deployment pipeline takeaway
The GitHub Actions to Lambda deploy path is significantly simpler than my current Docker-on-VPS workflow for functions that fit the serverless model. If I were starting a new small service today - a Slack bot, an inbound webhook processor, a nightly report generator - I would reach for Lambda before I reached for a VPS.
The workshop made that case clearly and with working code. For the engineers in the room who were still manually SSHing into servers to deploy Python scripts, this was a meaningful unlock.
#Community note
The devinfradays format - focused workshops at a venue, hands-on from minute one - is one I want to see more of in the Bengaluru tech community. The signal-to-noise ratio was high. I left with working code and two specific ideas about where to apply the pattern in my own stack.
If you are curious about how I handle the other side of this - background jobs, LLM task queues, and why Celery still wins for long-running agent work - I wrote about it in detail: Celery and Redis for LLM Background Jobs.
Frequently asked questions
When does serverless make sense for AI applications?
Serverless works well for stateless, short-lived AI tasks: webhook handlers, lightweight classification endpoints, scheduled data pulls and async trigger functions. It struggles with long-running LLM inference (cold starts add 2 to 5 seconds), stateful agent loops that maintain context across steps, and streaming responses where the connection must stay open for seconds or minutes.
How does GitHub Actions to Lambda deployment compare to Docker on a VPS?
The GitHub Actions to Lambda path is genuinely simpler for single-function services: push, the action zips and deploys, Lambda versioning gives you instant rollback. Docker on a VPS wins when you need persistent workers, large model weights on disk, or long-lived connections - which is most of what I run in Opaeron. The right answer depends on your longest-running task: if it exceeds the Lambda 15-minute timeout, serverless is the wrong abstraction.
What is the practical cold-start cost for AWS Lambda in 2024?
Cold starts on Python 3.12 Lambda with a small deployment package typically land at 400 ms to 1.2 seconds depending on memory allocation and VPC configuration. With Provisioned Concurrency that drops to under 100 ms but you pay for idle time. For user-facing AI endpoints where latency matters, cold starts are the primary reason I keep a persistent FastAPI server running rather than going fully serverless.
Attending an event or workshop in Bengaluru? Always happy to connect.
Get in touch