Core Resource Model

Quilt’s API is broad, but the underlying model is stable.

If you understand the resources on this page, the rest of the docs become much easier to reason about.

The Stable Resources

• containers are the primary runtime unit
• exec runs a command inside a container synchronously, returning output inline
• operations represent async lifecycle work
• snapshots capture container state for cloning and lineage
• forks create a writable branch from a live container
• volumes hold persistent filesystem data
• network resources expose addressing and diagnostics
• terminal sessions are managed interactive PTY sessions

Why This Matters

These are not random endpoint families. They describe the lifecycle of real work:

1. create or locate a runtime
2. check whether it is ready
3. run commands or open a session
4. save, clone, scale, or delete it

The Default Troubleshooting Flow

1. confirm API health
2. resolve the target container or function
3. inspect readiness and current state
4. act
5. read the result — exec returns inline, operations require polling, invocations have their own record

Readiness Before Action

The resource model assumes you will check readiness intentionally:

• containers: use /ready
• functions: inspect state plus pool status
• orchestration: inspect health and operation records

That is why the docs repeatedly separate existence, accepted mutation, and actual readiness.

How the Resources Connect

Resource	Depends on	Produces
Container create	image or managed runtime	201 Created + full container status
Exec request	running, exec-ready container	200 OK + inline result
Snapshot	existing container	operation + snapshot
Clone	existing snapshot	operation + container
Fork	existing live container	operation + container
Volume attach	existing volume + create payload	persistent filesystem
Terminal session	existing container	session + websocket attach