Architecture before abstraction
Understand the event path, ownership boundary, and failure model before reaching for another layer of tooling.
Build serverless in the open, with people who care about the details.
The zerverless community is for engineers designing, shipping, and operating serverless systems on AWS. Bring a real question, a trade-off, or a lesson from production.
Real systems
Start with architecture, code, operations, and the constraints around them.
Shared context
Explain the problem well enough for another engineer to reason with you.
Respectful review
Challenge the decision without turning the person into the problem.
A place for the work between the happy path and production.
Serverless gets interesting where services, permissions, teams, cost, and failure modes meet. This community exists to make those decisions easier to inspect and discuss.
Production evidence over hype
Prefer measurements, incidents, constraints, and reproducible examples to claims that only work on a slide.
Customer control by default
Keep source, infrastructure, data, and AWS access visible to the team responsible for the workload.
Talk about the decisions that shape the system.
The useful conversation is rarely about one service in isolation. Follow the decision across its technical and operating boundaries.
01
System design
Events, APIs, workflows, data boundaries, multi-account structure, and the trade-offs behind each choice.
02
Delivery
TypeScript, AWS CDK, deployment safety, testing, environments, and patterns a team can maintain.
03
Operations
Observability, incident learning, performance, cost, security, and change in systems already serving users.
04
AI Solutions on AWS
Retrieval, evaluation, agents, guardrails, and the serverless foundations that make an AI feature operable.
Make every contribution useful to the next engineer.
A strong question does not need a perfect answer. It needs enough context to turn individual experience into shared knowledge.
01
Name the decision
Say what you are trying to choose, change, understand, or repair.
02
Show the constraints
Include scale, ownership, security, cost, timeline, and the AWS boundaries that matter.
03
Bring evidence
Share a minimal example, measurement, diagram, or sanitized production signal when it helps.
04
Close the loop
Return with the outcome, what changed, and what the next engineer should know.
Keep the room technical, generous, and safe.
Good community standards protect both the quality of the conversation and the people doing the work.
What helps
- Be specific about facts, assumptions, and opinions.
- Explain acronyms and unusual context when they affect the answer.
- Give credit and make corrections visible.
- Offer critique that leaves the work easier to improve.
What stays out
- Customer data, credentials, secrets, and private account details.
- Harassment, discrimination, personal attacks, and gatekeeping.
- Hidden promotion, lead harvesting, spam, and manufactured urgency.
- Security testing or disclosure without an approved private path.
How this community works.
Help make serverless knowledge easier to trust.
Clear questions, honest constraints, and production evidence are enough to start. The community will grow around that standard.