Skip to content

tobilg/extenddo

ExtendDO

ExtendDO runs ExtendDB's implemented DynamoDB JSON request/response surface on Cloudflare Workers, Durable Objects, SQLite storage, and R2. The compatibility target is ExtendDB parity, not general AWS parity. DynamoDB- or IAM-shaped behavior is in scope only when ExtendDB implements it, depends on it, or exposes it directly.

ExtendDO is not affiliated with, endorsed by, or sponsored by Amazon Web Services or Amazon.com, Inc. AWS, Amazon DynamoDB, and related service names are trademarks of their respective owners. They are used in plain text only for factual references to compatible request shapes, client tooling, and behavior where ExtendDB exposes it.

The Worker entrypoint accepts DynamoDB JSON requests, dispatches operation validation and response shaping through local ExtendDB Rust crates compiled to wasm, and satisfies ExtendDB storage traits through Durable Object callbacks. The current topology uses one catalog Durable Object, one SQLite-backed table Durable Object per logical table, and a transaction coordinator Durable Object for cross-table transaction recovery.

Documentation

  • Development: local setup, wasm build flow, generated Worker types, test commands, and contributor checks.
  • Deployment: Cloudflare resources, Wrangler deployment, R2 setup, Durable Object migrations, secrets, and post-deploy bootstrap.
  • Configuration: Worker bindings, runtime environment variables, management settings, and credential gates.
  • Usage: end-to-end AWS CLI and AWS SDK client examples using ExtendDO endpoint overrides for credentials, table lifecycle, writes, reads, queries, updates, and deletes.
  • API Surface: DynamoDB JSON operations, Worker-native R2 import/export, health checks, and management endpoints.
  • Limitations: current Cloudflare topology constraints, background-job behavior, scale limits, and unsupported operations.
  • ExtendDB Parity: reused ExtendDB crates, Worker-specific adaptations, and differences from broader AWS service behavior.
  • Architecture: Rust/Worker/DO topology.
  • DynamoDB Primitive Mapping: how DynamoDB-compatible request concepts map to ExtendDB Rust code, wasm storage callbacks, Durable Objects, SQLite state, and R2.
  • ExtendDB Reference Notes: local ExtendDB setup, compatibility patches, and reference provenance.
  • Security Policy: vulnerability reporting and production hardening guidance.
  • Contributing: compatibility rules, checks, generated files, and documentation expectations.

Quick Start

Install dependencies and verify the local workspace:

pnpm install
pnpm run setup:extenddb
pnpm run check
pnpm run test
pnpm run deploy:dry-run

For local development with Wrangler:

cp wrangler.example.json wrangler.jsonc
pnpm run build:wasm
pnpm run generate:types
pnpm exec wrangler dev --config wrangler.jsonc

Deploy And Bootstrap

The tracked wrangler.example.json is a validation and bootstrap template. Before deployment, copy it to ignored local config, choose environment-specific Worker and R2 bucket names, create the configured bucket, configure management bootstrap credentials, and deploy the Worker:

cp wrangler.example.json wrangler.jsonc
# Edit wrangler.jsonc: name, r2_buckets[].bucket_name, observability sampling.
pnpm exec wrangler r2 bucket create <your-extenddo-r2-bucket>
pnpm exec wrangler secret put EXTENDDO_ADMIN_USER
pnpm exec wrangler secret put EXTENDDO_ADMIN_PASSWORD
pnpm exec wrangler deploy --config wrangler.jsonc

EXTENDDO_ADMIN_USER and EXTENDDO_ADMIN_PASSWORD are required for a fresh deployment because no stored management admin exists yet. Once you have created and verified a stored admin through /management/admins, you can rotate or remove the static bootstrap credentials according to your environment policy.

Verify the deployment:

curl https://<worker>/healthz

Create an account, user, inline policy, and access key through the curl-friendly management API:

curl -u admin:secret \
  -X POST https://<worker>/management/accounts \
  -H 'content-type: application/json' \
  -d '{"account_id":"123456789012","account_name":"dev"}'

curl -u admin:secret \
  -X POST https://<worker>/management/accounts/123456789012/users \
  -H 'content-type: application/json' \
  -d '{"user_name":"quickstart","password":"secret"}'

curl -u admin:secret \
  -X PUT https://<worker>/management/accounts/123456789012/users/quickstart/policies/FullAccess \
  -H 'content-type: application/json' \
  -d '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"dynamodb:*","Resource":"*"}]}'

curl -u 123456789012/quickstart:secret \
  -X POST https://<worker>/management/accounts/123456789012/users/quickstart/access-keys

Unsigned DynamoDB JSON requests are rejected by default. Set EXTENDDO_ALLOW_UNAUTHENTICATED=true only for local development or controlled tests that intentionally use the default local account without SigV4.

Current Parity Slice

The current data-plane and control-plane slice routes table lifecycle, item CRUD, query/scan, batch operations, single-table and coordinated cross-table transactions, TTL settings, tags, streams, secondary index maintenance, backups, RestoreTableFromBackup, and Worker-native R2 import/export through the ExtendDB-backed engine/storage boundary.

RestoreTableToPointInTime intentionally returns ExtendDB's current unsupported-operation behavior. AWS-only management extensions such as managed policies, MFA devices, OIDC/SAML providers, AWS Organizations context, request-tag condition keys, trusted network/FAS headers, and federated assume-role flows are outside the public parity target and should return 404.

About

ExtendDO runs ExtendDB's implemented DynamoDB JSON request/response surface on Cloudflare Workers, Durable Objects, SQLite storage, and R2

Topics

Resources

License

Contributing

Security policy

Stars

Watchers

Forks

Contributors