Skip to content

Runtime isolation

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 test SUITE=capacity 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:

python3 services/resources/database/tools/check_native_engine.py \
  --guest ermahgerd-single-01 --report .cache/native-database-single.json

This 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 check. 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.

Integration selection What it exercises
make test SUITE=services R2, queues, databases, assets, schedules, secrets, and outbound networking
make test SUITE=platform Tenant isolation, telemetry, ingress protection, and shared-runtime boundaries
make test SUITE=external AI and vector search with a configured provider
make test SUITE=capacity Logical Worker density, Images admission, and neighboring traffic
make test SUITE=continuity Deployment continuity under traffic

For retained evidence and service measurements, see Platform observability.

Navigation

Type to search…

↑↓ navigate↵ selectEsc close