Zerverless builds products, templates, open-source tools, learning resources, and consulting for AWS serverless teams. Products support repeatable jobs; consulting supports decisions that depend on your system and constraints.
Frequently asked questions.
Find quick answers about getting started, products, AWS permissions, pricing, consulting, learning, templates, GenAI, and getting help.
Browse questions by topic.
General
No. AWS remains the runtime and your account remains the workload boundary. Zerverless helps your team design, inspect, and improve the system without moving application code to a Zerverless runtime.
Access depends on the job. Discovery and analysis use a dedicated read-only role, assumed on demand with AWS STS. Any deployment role is separate, explicit, and limited to the resources it needs to change.
Your team keeps the AWS account, source code, infrastructure, data, architecture decisions, and operating artifacts. Outputs are designed to stay useful in the workflow your team already owns.
Start with the decision. Use the Concepts Hub to build shared language, choose a product for a repeatable job, or choose consulting when the outcome depends on your system context and experienced review.
Parts of it. ZDK and OZ are MIT-licensed standalone tools that you can inspect and use without a Zerverless account. Xero, Air, and Hero are commercial products that connect through a role you control.
Zerverless does not take over operations or become your runtime. A product handles one focused job in your account; consulting delivers a written outcome and hands it back. Your team keeps the architecture, code, and decisions.
Getting started
Start with the decision in front of your team. Use a product for a repeatable job such as designing, mapping, or improving a serverless system; use the Concepts Hub to build shared language; and choose consulting when the outcome depends on your system context and experienced judgment.
No. You can explore the products, templates, open-source tools, learning resources, and consulting options without connecting an account. An AWS role is only reviewed when a selected product or engagement needs access to a specific workload.
Yes. Xero is designed for new services, architecture spikes, and migrations before deployment. Templates and the Concepts Hub are also useful when a team needs a credible starting point before an account has resources to inspect.
Bring it. Zerverless can use the constraints, code, diagrams, and production context your team already has to make the next decision clearer. The goal is to preserve useful work, expose missing assumptions, and leave you with an outcome you can review and own.
A person reviews the short description of your workload and the decision you need to make. You will get a direct answer, the relevant resource, or a proposed next step; no product signup, AWS connection, or IAM access is required just to start the conversation.
Products and pricing
Air and Hero work through a read-only IAM role. Xero needs no AWS access while you design; write access exists only in an explicit deploy workflow you start yourself.
No. Your AWS account stays the runtime and the source of truth. Products read through the role you grant, and nothing changes unless you explicitly deploy.
Yes. Read and deploy use separate IAM roles with a per-customer external ID, so you can give one product read-only access and another deploy access — or neither.
Yes. Remove or narrow the trusted role in your AWS account and the product loses access immediately — no ticket or approval from Zerverless required.
Xero and Hero are in private beta and Air is in preview. Request access from the tab above, or contact us and describe the workload you want to start with.
Pricing applies once a product reaches general availability. You'll see the plan and cost in advance — nothing changes automatically at the end of a beta or preview.
Yes. There is no long-term lock-in tied to product access — remove the connected role when a product no longer fits, and reconnect later if it does.
They share the same account connection and context, but each keeps its own job and permission boundary. You can adopt one without the others.
AWS access and security
Customer account connections are designed around role assumption with AWS STS, a role ARN, and a per-customer external ID rather than long-lived customer access keys.
No. Read and write use separate IAM roles. A workflow that deploys or changes resources requires a separately approved write role.
Remove the trusted role, change its trust policy, or narrow its permissions in the customer AWS account. The customer retains control of that authorization boundary.
No. Certifications and independent assurance will be named only when they have been completed and the scope can be stated accurately.
Only what a specific job requires, over the access you grant. Discovery and analysis work from what the assumed role can see in your account, and nothing is retained beyond what the product needs to do its job.
Data captured during discovery and analysis is encrypted in transit and at rest, scoped per customer, and limited to what a product needs to do its job. The privacy policy has the full data-handling detail.
Consulting
After a short discovery call, you receive a fixed-price proposal tied to the written scope. If the problem is not defined well enough to price, the first engagement is a small discovery sprint.
Reviews and architecture sprints are usually measured in days or a few weeks. Modernization work is split into independent waves so you can stop, reassess, or continue without a long commitment.
Enough read-only access to understand the relevant workload, plus access to the documentation and code your team already uses. Write access is requested separately only if deployment is in scope.
Yes, when implementation is part of the agreed scope. The work still happens in your repository with your team involved so the handoff is not a separate phase.
The engagement can integrate with the rest of your stack, but AWS serverless architecture and operations remain the focus.
Yes. A mutual NDA is standard before any account access or detailed workload discussion, and is easy to put in place before the first working session.
A written architecture decision, a prioritized improvement plan, or a reviewable code skeleton — always something your team can execute without Zerverless in the room, not a slide deck.
Learning and architecture
The Concepts Hub is Zerverless's public learning library for AWS serverless architecture. Its guides explain services and patterns through the security, reliability, operations, and delivery trade-offs that shape real systems.
Only if shared language is the immediate need. The guides are useful for clarifying a concept or trade-off; a product is useful when you have a repeatable job to do now. You can move between both paths without creating an account.
Yes. The Concepts Hub is public and does not require a Zerverless account. It is intended to help teams make better AWS serverless decisions whether or not they use a product or consulting engagement.
Yes. If applying a concept depends on your architecture, constraints, or production evidence, contact Zerverless with the short version of the decision. That conversation can identify whether a focused product or scoped consulting work is the better next step.
Templates and open source
Yes. The templates are free to use, and the source lives in a public repository. AWS charges for the resources you deploy are separate and depend on your own configuration and usage.
No. They deploy through standard AWS CDK and CloudFormation. The generated workload runs in your AWS account and does not require a hosted zerverless runtime.
That is where we come in. Architecture changes, integrations, migrations, and taking a template-based system to production are available as scoped engagements — talk to sales and describe the system you need.
Yes. Open an issue or pull request in the public repository. Focused changes that keep the templates narrow and the permission model explicit are welcome.
Each template documents the AWS resources it provisions and the IAM permissions each one needs before you deploy, so there are no surprises in the CloudFormation change set.
Yes. Templates are a starting point, not a dependency. Once deployed, the CDK code is yours to change, extend, or strip down with no ongoing tie back to Zerverless.
AI Solutions
AWS is the operating boundary and Amazon Bedrock is usually the starting point because it provides managed model access and integrates with the surrounding AWS platform. If an existing model provider is a hard requirement, the architecture can evaluate it without weakening the data, security, or operating boundaries.
Not by default. Start with the task and a small evaluation set. Prompting may be enough; retrieval helps when answers depend on changing or private knowledge; fine-tuning is useful for narrower behavior and style problems. The evidence should choose the technique.
Use an agent when the workflow must choose among tools, gather information over several steps, or adapt its plan. A deterministic workflow is usually better when the steps are already known. Agent autonomy should grow only as authorization, evaluation, and recovery paths prove it is safe.
No architecture can promise that every generated statement will be correct. You can reduce and contain the risk through grounding, citations, contextual checks, guardrails, structured validation, human review, and a tested refusal or fallback path.
Discovery begins with architecture context and read-only access to the relevant systems. Any deployment role is separate, explicit, and limited to the resources in scope. Long-lived customer credentials are never required.
Yes. The first step is to preserve what the prototype already proved, then identify what is missing for production: data permissions, evaluation, failure behavior, observability, cost controls, deployment, and ownership.
Your team does. Prompts, evaluation sets, and any fine-tuned artifacts stay in your AWS account and your source control, not in a Zerverless-hosted store.
Yes. Token usage, model selection, caching, and batching are architecture decisions with real cost impact, and they are part of the same evidence-based design process as the rest of the system.
Community and help
This page is the canonical home of the zerverless community. There is no separate forum or chat to join today. Any future gathering space will be announced and documented here before it opens.
Software engineers, full-stack developers, platform teams, DevOps practitioners, and technical leaders working on serverless systems in AWS. Experience is welcome; curiosity and clear context matter more than seniority.
No. Community participation is separate from product access, subscriptions, and consulting work.
Share it when it directly answers the technical question and disclose your relationship to it. Promotion without useful context does not belong here.
Only after removing customer identities, account identifiers, secrets, private data, and any detail you are not authorized to disclose. Recreate the smallest safe example whenever possible.
Yes: be technical, be honest about constraints, and do not share what you are not authorized to share. Zerverless will remove content that violates that standard.
Yes, when the question is technical and the answer helps more than one reader. Zerverless does not use this page as a sales channel.
Anything across Zerverless: evaluating a product against a workload, scoping a consulting engagement, planning a GenAI system, buying or adapting a template, or a question about one of our open-source projects. If you are not sure where it fits, send it anyway and we will route it to the right place.
The short version is enough: what runs today, the outcome you need, and the constraint or risk in the way. You do not need a polished brief, a budget, or an architecture diagram — and please leave credentials and secrets out of the form.
A real person replies within one business day. We will either answer directly, point you to the right resource, or suggest a short call when a conversation would move things forward faster.
No. Getting in touch never requires an account connection, product signup, or IAM access. If a later product or engagement needs access to your AWS account, we explain exactly what it needs and why before you grant anything.
Send the short version through the form first. If a call is the right next step, we will propose times rather than asking you to guess at availability.
Contact us and say so directly. We cannot promise incident-response SLAs today, but we will tell you quickly whether we can help and how fast.
Still have a question?
Send us the short version of what you are trying to do, and we will point you to the right product, resource, or next step.