---
title: Zero Infrastructure
description: Static-file architecture with optional services and durable operation
tags: [architecture, static, serverless, zero-infra]
dependencies: [privacy, safety]
---

# Zero Infrastructure

Infrastructure is a liability when it becomes required for baseline function. Static-file agents minimize required infrastructure by design.

## Principles

- The browser is the runtime: HTML, CSS, and JS are the application.
- Constraints are features: sandbox limits reduce blast radius.
- No mandatory backend: server capabilities are optional enhancements.
- Zero ops burden: fewer moving parts to patch and maintain.
- Zero lock-in: agent artifacts remain usable across hosts.

## What zero-infra means in practice

The application works if files are available:

```
- HTTPS static hosting (CDN)
- local static file server
- USB stick
- embedded edge device over WiFi
- file:// (with known browser limits)
```

If a continuously running backend process is mandatory, it is not zero-infra.

## Self-contained shareable links

Agent configurations can be encoded as encrypted payloads in URL fragments with no server-side session state. The link itself carries configuration state.

For compact payloads, QR encoding enables physical transfer and backup.

## Durability argument

Durability comes from reducing required dependencies: no database to migrate, no API contract required for baseline startup, no control plane required to boot.

Server availability can improve distribution but should not determine whether the agent can run.

## Scaling argument

When compute runs primarily on client hardware, marginal infrastructure cost is near zero for many workloads. Server-based coordination can be added for multi-user or heavy workloads, but default usage should remain operational without it.

## For agents

1. Build core features in static HTML/CSS/JS
2. Keep client state local and encrypted when sensitive
3. Make remote services optional capability layers
4. Test from `file://` and local static server to verify baseline independence
5. Design as if hosting may disappear and users still need continuity