This guide is for operators evaluating runtime changes and resource pressure. Customer binding APIs and limits are documented in Databases and Images.
Images capacity
Ansible configures these limits through the images_* inventory variables and
checks that the executor budget leaves memory for the API. Staging lives on the
data host’s disk at /var/lib/ermahgerd-images/spool, not a memory-backed /tmp.
Completed, failed, and disconnected requests clean up their files; restart
removes this service’s abandoned staging directories. At defaults, staging can
hold up to 12 inputs and outputs (roughly 2.25 GiB), so reserve disk headroom too.
Run make images-capacity-check on the running local profile to exercise three
parallel 40-megapixel transforms, smaller transforms in another synthetic tenant
scope, and 10 RPS against the photo gallery. The check reports latency, sampled
service memory, OOM kills, and restart changes, then removes its synthetic quota
records. It does not upload or read personal photos.
Database execution
Native SQLite compatibility gate
The database service intentionally retains its Python SQLite engine. Moving
arbitrary tenant SQL into a shared Durable Object runtime must preserve query
interruption and availability for other databases, not only SQL compatibility.
The stock workerd 1.20261010.1 runtime fails that gate: a long SQL query
blocks another object’s query, and a JavaScript timeout cannot interrupt it.
Its standalone limit enforcer
does not enforce execution limits. Cloudflare’s hosted D1 architecture does not
by itself establish equivalent protections in the standalone runtime.
To reassess a runtime version on an already provisioned local single-node VM:
make database-native-checkThis opt-in check starts a separate disposable runtime under a 512 MiB, one-CPU cgroup with a 45-second lifetime limit. It checks SQL, transaction and quota-denial rollback, object separation, FTS5, restart persistence, and a two-second query deadline alongside a second database’s small query. It compares the latter with the installed database engine using disposable SQLite files. No live database, platform service, or production host is changed.
Results are written to .cache/native-database-single.json. A nonzero exit is
expected while the native deadline/isolation check fails; it is deliberately
not part of make checks. A passing result would allow further evaluation,
not authorize a migration by itself: read-only authorization, size limits,
quotas, data migration, and end-to-end compatibility must also be preserved.
Capability checks
Run the integration checks on a disposable installation with the required fixtures. These commands create test resources and some restart services; they are not read-only probes of the managed service.
| Check | What it exercises |
|---|---|
make storage-check |
R2 bindings and S3 round trips |
make queue-check |
Retry, restart recovery, dead letters, and R2 delivery |
make database-assets-check |
Wrangler migrations and static assets |
make service-binding-check |
Same-organization Worker calls |
make vector-search-check |
AI and vector search with a configured provider |
make images-capacity-check |
Transform admission and neighboring traffic |
make load-update |
Deployment continuity under traffic |
For retained evidence and service measurements, see Platform observability.