I used to wake up with a knot in my stomach before deploying to production.
Not because the code was bad, but because deploying infrastructure to AWS felt like a mix of manual configuration, prayer, and hoping I didn't accidentally break something. Creating a Lambda function here, setting up IAM roles there, configuring environment variables in a dozen different places—it was fragile and error-prone.
Then I discovered the Serverless Framework, and deployment day stopped being scary.
What Is the Serverless Framework?
The Serverless Framework is essentially a declarative way to define all your AWS infrastructure in a single file. Instead of clicking through the AWS Console or running random CLI commands, you describe everything you need in serverless.yml: your Lambda functions, their triggers, IAM permissions, environment variables, database tables, everything.
Think of it like a blueprint for your entire backend. You tell it what you want, and it handles the details of creating it.
functions:
api:
handler: dist/api/handler.main
environment:
STAGE: ${self:provider.stage}
TABLE_NAME: jottings-${self:provider.stage}
events:
- http:
path: api/{proxy+}
method: ANY
This single definition replaces weeks of manual AWS Console configuration. It's reproducible, version-controlled, and auditable.
Why We Chose Serverless Framework
When building Jottings, I had three options:
- AWS CloudFormation - AWS's native infrastructure as code tool. Powerful, but verbose and AWS-specific.
- Terraform - Cloud-agnostic and sophisticated. But also heavyweight for a startup focused on velocity.
- Serverless Framework - Specifically designed for serverless applications with great defaults.
We chose Serverless Framework for one reason: it's built for exactly what we do. It speaks the language of serverless applications—functions, triggers, permissions, Lambda layers. No unnecessary abstraction layers, no learning AWS's CloudFormation syntax.
Plus, the deployment experience is incredible. One command deploys everything:
serverless deploy --stage prod
No fumbling with AWS CLI flags. No creating resources in the wrong region. No accidentally skipping IAM roles.
How We Use It at Jottings
Our serverless.yml defines the entire backend:
Lambda Functions:
- API handler - Express server that handles all HTTP requests to our dashboard and API
- Build processor - Triggered by SQS messages to generate static HTML, sitemaps, and feeds
- Cognito triggers - Post-confirmation and pre-token-generation for authentication
Events and Triggers:
- API Gateway routes everything to our Express function
- SQS queue triggers the build processor when users create new sites
- Cognito hooks into Lambda for user provisioning
Infrastructure:
- DynamoDB tables with pay-per-request billing
- IAM roles with principle of least privilege
- Environment variables for dev, staging, and production
- CloudWatch alarms for monitoring
Example from our config:
provider:
name: aws
runtime: nodejs20.x
stage: ${opt:stage, 'dev'}
region: us-east-2
environment:
SITES_TABLE: jottings-sites-${self:provider.stage}
USERS_TABLE: jottings-users-${self:provider.stage}
BUILD_QUEUE: jottings-build-${self:provider.stage}
functions:
api:
handler: dist/api/handler.main
timeout: 30
memory: 512
events:
- http: ANY {proxy+}
- http: ANY /
buildProcessor:
handler: dist/build/handler.process
timeout: 900
memory: 1024
events:
- sqs:
arn: !GetAtt BuildQueue.Arn
batchSize: 1
This single config manages functions, triggers, permissions, and environment variables across three environments (dev, staging, production).
The Developer Experience Magic
Here's what makes Serverless Framework amazing for actual developers building products:
1. Instant Feedback Deploy in seconds, not minutes. Iterate fast. When you find a bug, you fix it and redeploy—not skip the next iteration of your product.
2. Environment Management One config file. Three environments. Change the stage flag and everything adjusts—function names, table names, queue names. No environment-specific configs to maintain.
# Deploy to dev
serverless deploy --stage dev
# Deploy to production
serverless deploy --stage prod
3. Local Development Run everything locally before touching AWS:
serverless offline start
Your Lambda functions run locally. Your events trigger correctly. You can test the full flow without shipping to AWS.
4. Zero Configuration Overhead The framework handles IAM role creation. You don't have to manually craft permission policies. It creates only the permissions your functions actually need.
5. Version Control for Infrastructure Your entire backend is in git. You can code review infrastructure changes. You can revert a deployment with git. You can see exactly what changed between production versions.
The Real Win: Confidence
The reason I sleep better now? Everything is reproducible.
If AWS mysteriously deletes my infrastructure (it won't), I can redeploy with one command. If I mess something up in dev, I can destroy it and recreate it from the config. If a developer joins the team, they can understand the entire architecture by reading one file.
That reproducibility is worth everything. It's not just about automation—it's about safety. It's about knowing that your infrastructure is defined, tested, and ready to go.
Getting Started
If you're building on AWS Lambda, Serverless Framework is worth investigating. The learning curve is gentle, the community is active, and it'll make your deployment day something you actually look forward to.
Start with the official docs, deploy your first function, and experience that "deploy with confidence" feeling yourself.
We built Jottings with Serverless Framework because we needed infrastructure that moved as fast as our product. It's proven invaluable for maintaining velocity while keeping our backend clean and manageable.
If you're curious about Jottings' architecture, our build system, or how serverless infrastructure powers a microblogging platform, feel free to reach out. I love talking about how we build things.
Want to try it? Start blogging with Jottings today and see how simplicity and speed can coexist in a publishing platform.