Skip to content
Hakiri

ADR-0009 — Cloudflare and AWS are the only first-class cloud targets in v0

Context

Section titled “Context”

Hakiri’s “one binary, many topologies” principle commits to running on multiple deployment surfaces. Each first-class target costs real engineering: a hakiri deploy <cloud> codegen path, a catalog backend, an orchestrator integration, a CDK or wrangler equivalent, a parity soak test in CI.

Candidates considered: Cloudflare (Workers + Workflows + Containers + DO + R2), AWS (Lambda + Step Functions + Fargate + RDS/Dynamo + S3), GCP (Cloud Run + Workflows + Firestore + GCS), Fly.io Machines, Render, Railway, generic Kubernetes.

Decision

Section titled “Decision”

Cloudflare and AWS are the only first-class cloud targets in v0. All other cloud platforms are supported via Topology 2 (self-hosted daemon) or Topology 2.5 (self-hosted cluster) — the Hakiri binary runs anywhere Linux runs, but bespoke hakiri deploy <cloud> wiring is not provided in v0.

GCP, Fly, and Kubernetes-via-Helm are M3-or-later candidates if user demand warrants.

Consequences

Section titled “Consequences”

Positive

  • Two cloud targets is the maximum we can hold to feature parity in a small team. The M2 success criterion (“the same hakiri.toml produces byte-identical Parquet on both clouds after a 24h soak”) is achievable; tripling the matrix would not be.
  • Cloudflare and AWS together cover the bulk of the agent-builder persona. Cloudflare for edge-first / R2-native deploys; AWS for VPC / regulated / enterprise.
  • Both clouds are reconciliation-shaped (cron triggers, durable orchestration, single-writer state primitives, object storage). The conceptual model lifts cleanly onto either. GCP fits this shape too, but the increment of polish is real.

Negative

  • Teams already on GCP must run Topology 2 or 2.5 on Compute Engine / Cloud Run themselves. We provide systemd units and Docker compose, not Cloud Run Service YAML.
  • “First-class” is a commitment to feature parity; if a Cloudflare primitive ships before its AWS equivalent (or vice versa), we hold the feature back or build a portable abstraction. That tax is real.
  • Kubernetes users see no shipped Helm chart in v0. They can kubectl apply a Deployment + Service themselves, but no bespoke chart. M3 ships one.

Neutral

  • The decision is revisitable. Adding GCP in M3 is a finite project, not a re-architecture.

Alternatives considered

Section titled “Alternatives considered”

Cloudflare only. Tightest deploy story, smallest test matrix. Rejected because the AWS persona (VPC-bound, regulated, “already on AWS, won’t add a second cloud”) is too large to ignore.

AWS only. The default cloud, broadest install base. Rejected because Cloudflare’s primitives (Workers + Workflows + DO + R2 + Containers) line up uniquely well with Hakiri’s reconciliation model — DO SQLite is the cleanest expression of the single-writer-per-pipeline invariant on any cloud (ADR-0006), and R2’s zero-egress reads make Pillar 5 (collocation) economically viable.

Cloudflare + AWS + GCP. GCP’s primitives (Cloud Run Jobs + Workflows + Firestore + GCS) map onto the model, but the third target triples the parity-test cost without serving a meaningfully different persona than AWS in v0. Deferred.

Generic Kubernetes as the first-class target. Would cover every cloud at once. Rejected because (a) it contradicts Pillar 1 — Kubernetes is exactly the orchestrator we’re letting teams avoid, (b) the K8s deploy is just a thin wrapper around the same binary + config that Topology 2.5 already specifies, and (c) we want to not require K8s, not promote it as the canonical path.

References

Section titled “References”