Why zerverless never becomes your runtime

The most important boundary in zerverless is simple: your workloads run in your AWS account.

That means your functions, queues, APIs, workflows, databases, logs, and deployment history stay under the controls your team already uses. Zerverless can provide context around that system, but it does not become the system.

Why the boundary matters

Developer tooling often begins as a convenience layer and gradually becomes a runtime dependency. The trade-off can be reasonable, but it should never be hidden.

If a platform runs your workload, leaving it may involve moving data, rebuilding deployment paths, changing operational ownership, and retraining the team. If the platform works around your AWS account, leaving should be much less dramatic: remove the connection and keep operating what you already own.

That is the model zerverless is designed around.

Different jobs need different access

The account boundary does not mean every product is read-only. It means access must match the job.

• Air discovers resources and relationships. It has no reason to write.
• Hero analyzes configuration and operational signals. It can remain read-only.
• Xero can propose an architecture without AWS access, then request a separate deploy role only when you explicitly choose to deploy.

A read role should never become a write role because it is convenient for the tool. Those are different trust decisions and should remain different IAM roles.

What stays yours

The boundary covers more than where code executes. You keep ownership of:

• the infrastructure definitions and application code;
• the AWS resources and data created by a deployment;
• the IAM policies that grant or revoke access;
• the operational dashboards, logs, traces, and alarms;
• the AWS bill and the relationship with AWS.

Zerverless may help explain or improve each of those surfaces. It should not quietly take ownership of them.

The practical test

A trust model is useful only when a team can verify it. Before connecting a tool to AWS, ask three questions:

1. Which role will it assume?
2. Which actions can that role perform?
3. What continues to work if the connection is removed?

The answers should be visible in the product, setup guide, and generated IAM policy. “Trust us” is not a permission model.

Good developer tooling removes friction. Better developer tooling also makes the remaining responsibility easy to see.