--- class: reference purpose: "Release notes for ArgonDBCloud 1.0.4 — the overlay's `user_data_append` reaches the VM and its exit is recorded; plan/v1 and state/v1 record every overlay answer; two installs in one VPC share or refuse the S3 gateway endpoint by name; the `box-ready` refusal carries the instance's status checks and console tail; a tunnel-fronted overlay carries no Route 53 zone or ACM certificate (the `ingress:` line, its refusal, the tunnel kind's DNS-only direct-reach record); the compatibility matrix 1.5.7.16 through 1.5.7.20 (1.5.7.20 installed by default); cut 2026-10-29." template: product --- # ArgonDBCloud 1.0.4 **ArgonDBCloud in one paragraph.** One binary, `argondbcloud`, prices three ways of running ArgonDB on AWS or Azure from a few numbers about your load (it infers the rest and says so), recommends the cheapest that fits, and installs the one you choose into YOUR account through direct SDK calls — a plan you can read first, an apply that resumes after a kill without creating a second copy of anything, and a teardown that removes exactly what it made. It runs the first two day-2 operations on a shape (b) install it made: an ArgonDB `upgrade` and a named `backup` with a `restore` into a new install. From this release an application's overlay is installed as its author wrote it: its `user_data_append` runs on the VM, its answers are recorded where the application's render reads them, and its tunnel is the only ingress line it needs. The design is `docs/2026-10-01-argondbcloud-design.md`. **Where to get it.** `https://releases.argondb.ai/argondbcloud/v1.0.4/` — `argondbcloud-1.0.4-linux-x86_64.tar.gz`, its `SHA256SUMS`, these notes as `RELEASE-NOTES.md`; `https://releases.argondb.ai/argondbcloud/LATEST` names the current version, its artifact and sha256, and `supported_argondb`, the ArgonDB version it installs by default. Unpack, and `bin/argondbcloud` runs (Linux x86_64; the glibc floor is in section 6). The channel is its own product line, outside the ArgonDB database channels' drift set. **What 1.0.4 is.** EXACTLY the five rows that landed on `main` after the 1.0.3 cut and before this one, by Steve's ruling of 2026-10-29 ~5:1xam ET, selected as worded ("1.0.3 is exactly O1 + O2 + P6 + P7 as ruled; the four P5b findings and P10 are 1.0.4, chartered now and queued behind the 1.0.3 cut" — its id lands at the registry regeneration carrying that block): the four component findings of the 2026-10-28 rehearsal with the ERP's own overlay — the engine APPENDS the overlay's `user_data_append` to the VM and records the append's exit; `plan/v1` and `state/v1` RECORD EVERY OVERLAY ANSWER; two installs in one VPC SHARE OR REFUSE the S3 gateway endpoint by name before any call; the `box-ready` refusal carries the instance's status checks and console tail and refuses early on a stopped or impaired instance — plus P10, the component half of the zone ruling: a tunnel-fronted overlay carries no Route 53 zone or ACM certificate, `plan` prints one `ingress:` line and refuses a certificate or record on a tunnel hostname, and the tunnel kind gains an optional DNS-only A record for direct reach. Nothing else moved: the matrix, the day-2 verbs, the post-install order and the quota read are 1.0.3's. Each of the five is a visible change in section 3; what each does NOT do is a line in section 5. The ERP's Post-V1 job (11/09) installs this version: its overlay's install lines run on the VM, its two numbers are read back from `state/v1`, and its plan carries the tunnel as its only ingress line. ## 1. What 1.0.4 installs | shape | AWS | Azure | |---|---|---| | (a) one VM on local disk | **installable** — the VM boots ArgonDB 1.5.7.20 from the pinned artifact (or 1.5.7.19 / 1.5.7.18 / 1.5.7.17 / 1.5.7.16 with `plan --argondb-version`); proven at 1.0.1 (2026-10-27) from the published artifact on both clouds; the (a) first boot is the same template as (b)'s and was not re-run live at this cut; an overlay's `user_data_append` reaches the (a) VM too, and its read-back goes through the instance's console output, so no command channel is needed | **installable** — the same first boot, the installer's one resource group adopted (proven at 1.0.0, 1.0.1 and 1.0.2 from the published artifact; not repeated at this cut — see the lane report for the condition); the VM size a new subscription offers may differ from the planner's pick — `plan --override instance_sku=`; the append's read-back and the `vm-ready` diagnostics on Azure are written against ARM's documented shape and NOT run live (section 5) | | (b) one VM + object storage + managed disk — **the production shape** | **installable** — the lake in the bucket through the instance role (ArgonDB 1.5.7.20, the default), bucket versioning with the 7-day non-current window, the daily snapshot policy on the data volume, the S3 gateway endpoint created or ADOPTED from a neighbouring install, the overlay's `user_data_append` run after the engine's block and its exit read back, the overlay's post-install steps right after that and before any ingress line, every overlay answer in `state/v1`, and `upgrade`, `backup` and `restore` against it; the install from the PUBLISHED artifact on 2026-10-29 (the marker append read back, the two answers in `state/v1`, the `s3-endpoint` and `ingress:` plan lines, `select 1`, teardown, census ZERO) is in the lane report, which runs after this file is frozen | **NOT YET INSTALLABLE** (priced; the live client compiles and has never run against a subscription; the lake in the bucket, the three verbs, the quota read and the route-table read are AWS-only in 1.0.x) | | (c) per-tenant compute with idle-stop and wake — the growth path | **NOT YET INSTALLABLE** as the advisor reads it (priced; the cloud arms C1–C7 landed and a (c) estate was applied live once on AWS, k13-05, 2026-10-25 — the advisor's `installable` flag for (c) is a later row; an overlay with `user_data_append` under shape (c) gets a named `not-buildable` row, there being no single VM) | **NOT YET INSTALLABLE** (priced; Azure (c) is 1.1 [D-2026-10-03-7a4b8f]) | The table is what `argondbcloud advise --json` prints at this cut (the `installable` / `not_installable_because` fields), read from the artifact built at the cut against its recorded price book, never typed: ``` $ argondbcloud advise --json --offline --price-cache /prices needs-.json # needs/v1: tenants 1, data_gb 2, backups on, ha off {"shape": "a", "cloud": "aws", "installable": true, "not_installable_because": null, "unlocked_by": "K4", "monthly_usd": 154.98} {"shape": "b", "cloud": "aws", "installable": true, "not_installable_because": null, "unlocked_by": "K8", "monthly_usd": 156.28} {"shape": "c", "cloud": "aws", "installable": false, "not_installable_because": "NOT YET INSTALLABLE", "unlocked_by": "K13", "monthly_usd": 700.59} {"shape": "a", "cloud": "azure", "installable": true, "not_installable_because": null, "unlocked_by": "K4", "monthly_usd": 165.65} {"shape": "b", "cloud": "azure", "installable": false, "not_installable_because": "NOT YET INSTALLABLE", "unlocked_by": "K8", "monthly_usd": 166.72} {"shape": "c", "cloud": "azure", "installable": false, "not_installable_because": "NOT YET INSTALLABLE", "unlocked_by": "K13", "monthly_usd": 733.64} ``` **What a shape (b) install does, in order** (`argondbcloud plan --shape b needs.json`, then `argondbcloud apply plan.json`): under a live provider `plan` first reads the account's six service quotas (1.0.3) and, NEW in this release, the install's VPC route table — one `s3-endpoint:` line says whether the install will create its own S3 gateway endpoint (`NEW`) or adopt a neighbouring install's standing one (`ADOPTED (owner ) on `), or `plan` refuses by name before any call when the standing endpoint cannot be adopted exactly; `plan.md` also carries one `answers:` line (every overlay answer, a secret by its name only) and one `ingress:` line (section 3). Then the apply: the security group, the bucket (versioning on under `backups`, the lifecycle rule `argondbcloud-noncurrent` expiring non-current versions after 7 days, server-side encryption, public access blocked, request metrics), the IAM role and instance profile scoped to that one bucket (with the SSM core permissions the post-install and upgrade paths use), the S3 gateway endpoint — created, or ADOPTED and recorded `adopted`, never re-tagged — the instance (its first boot downloads the ArgonDB the plan names, refuses it unless its sha256 is the one pinned in the plan, points the lake at `/lake/` through the instance role, and, NEW, runs the overlay's `user_data_append` AFTER the engine's own block and after the overlay's secret files are written, writing the append's exit to `/var/lib/argondbcloud/overlay-user-data.exit` and its output to `/var/log/argondbcloud/overlay-user-data.log`), the data volume and its attachment, the address, the daily snapshot policy under `backups`, `box-ready` (its wait now reads the instance's status checks every minute and refuses EARLY by name on a stopped or impaired instance), then NEW the step `user-data-append`, which reads the append's exit and its last lines back through the instance's console output and records them in `state/v1` as `overlay_user_data` (a non-zero exit fails the apply by name with the resume command), then every `run-after-install` step the overlay declares, in its order, before the overlay's ingress resources (a tunnel; or, for a customer whose DNS is on AWS, the hosted zone, the record, the certificate and its issuance wait), unless a step names an ingress resource in `after:`. Shape (a) gains the append and the `user-data-append` step the same way. After the apply, `state/v1` carries `outputs.ipv4`, the root `overlay_answers` object, `overlay_user_data`, each post-install step's record, and the `upgrades` and `restore_points` lists the day-2 verbs write. ## 2. Compatibility **`supported_argondb: 1.5.7.20`** — the default, UNCHANGED from 1.0.3: the Linux channel's LATEST read at this cut on 2026-10-29 (6:1xpm ET) was still `v1.5.7.20` (published 2026-10-29T03:27:07Z), so the matrix this release installs is 1.0.3's, newest first (`argondbcloud supported`; `supported --json` prints the same as a table with each row's artifact URL and sha256): - **1.5.7.20** (default — the Linux channel's LATEST at the 1.0.3 cut and still at this one; sha256 `2f81b7ab972f382a7c728d99db589f8ead7881e327172ff3f788c7b8be4fb201`) - **1.5.7.19** (what 1.0.2 installed by default; the first release whose box puts the lake in the (b) bucket; sha256 `64bee886e2debc6dd6ec7e81b2b7e1710b274d3655fdf769be14b57cce055a51`) - **1.5.7.18** (what 1.0.1 installed by default; sha256 `f66cc2cd299697146df47bf4f356145168badfaf2a798b5e9bb9bff805324797`) - **1.5.7.17** (sha256 `ec98f1be39a7502cfdd0a9783b9930d6e2f4a2eaa41b6bcd41f7410f54572778`) - **1.5.7.16** (what 1.0.0 installed; sha256 `1eb3e48b9b060a66fa6b2a6ee74dbd997a6c38329dc151e79f0ee0a97cfcc065`) No tape or golden pinned to an artifact version moved at this cut, because the default did not. `argondbcloud plan --argondb-version ` (and `advise --argondb-version `, which writes the version into the alternatives document for `plan`) picks one: the plan's `argondb` block and the VM's first boot carry that row's version, URL and sha256, and `state/v1` carries the version after the apply. **A version outside the matrix is refused by name** — `refused: ArgonDB is not a version this ArgonDBCloud 1.0.4 installs; supported: 1.5.7.20 (default), 1.5.7.19, 1.5.7.18, 1.5.7.17, 1.5.7.16` on stderr, exit 2, no document. **A (b) plan at 1.5.7.18 or older does not put the lake in the bucket**: it says so by name in `capability_notes`, and asking for it on such a version (`--override lake_in_bucket=true`) is refused by name. `upgrade --to ` takes the same matrix. A 1.0.3 install at 1.5.7.20 has nothing to upgrade to from this release (`upgrade --to 1.5.7.20` is refused by name as not newer); a 1.0.2 install at 1.5.7.19 is the shape `upgrade --to 1.5.7.20` moves forward. ArgonDB's own releases do not depend on ArgonDBCloud; a later ArgonDB needs a later ArgonDBCloud to install it. ## 3. What changed since 1.0.3 (visible changes first) - **The overlay's `user_data_append` reaches the VM — appended after the engine's own block, its exit read back and recorded** (P5b row 2). An overlay's `user_data_append` — the lines that install the application on the install's VM — is appended by `apply` to the VM's user data AFTER the engine's own block and after the overlay's secret files are written, so the application's lines run as root under `bash -e` once ArgonDB is installed and answering on its port. **What is substituted, and only this**: `${install.id}` and `${install.name}`; `validate` refuses any other `${...}` by name (`placeholder ${argondb.version} is not one the engine substitutes (${install.id}, ${install.name}); a shell variable is written $NAME, without braces`). ArgonDB's version is NOT substituted (it is `argondb_version` in `state/v1`; the application pins its own release in its own text), the estate's DSN is NOT substituted (its password is minted on the box; the append reads `/etc/argondb/pg-password` on the VM as a post-install step's wrapper does), and an overlay answer is NOT substituted (a step's `args` carry those). The VM writes the append's exit and moment to `/var/lib/argondbcloud/overlay-user-data.exit` and its output to `/var/log/argondbcloud/overlay-user-data.log`, and prints the log's last 20 lines and one marker line to cloud-init's output; the plan's new `user-data-append` step, right after `box-ready`, reads them back through the instance's console output on AWS (every instance has one; no agent, no command channel and no IAM action on the VM's role is needed, so a document that declares no post-install step is read the same as one that declares four) and records them in `state/v1` under the install as `overlay_user_data` (`status`, `exit`, `log`, `finished_at`, `finished_on_vm`, `last_lines`, …) and in the apply-result's `outputs`. Every post-install step waits on it. **A non-zero exit fails the apply by name with the resume command**; `box-ready` is unchanged (ArgonDB's port, which opens before the append runs). `plan.md` says in one line how many lines the overlay appends. The whole user data is bounded by the cloud and refused by name past it, at `plan` and again at the instance call: EC2 takes 16 KiB and the engine's own shape (b) block is about 12.7 KB of it, so an append has roughly 3 KiB on (b); Azure's customData takes 64 KiB. An overlay without the field leaves the user data, the plan and the recorded tapes byte-identical. **Candor: from ArgonDBCloud 1.0.0 through 1.0.3 the field was validated and never read.** The schema carried it and guide 8 promised it as "the lines that install the application on the instance", but nothing in the engine appended it: the production rehearsal of 2026-10-28 measured the ERP's own document — six lines, no post-install step, its whole install path in this field — reaching neither VM. An ERP install on 1.0.0 through 1.0.3 installed ArgonDB and nothing of the ERP's. Measured live on the scratch account on 2026-10-29: a marker append read back 32 s after `box-ready`, `overlay_user_data.exit` 0, both placeholders substituted on the VM. - **`plan/v1` and `state/v1` record every overlay answer, so an application's render can read them** (P5b row 3). Every answer an operator gives to an overlay's questions is recorded: `plan/v1`'s `needs_resolved.overlay_answers` and `state/v1`'s root `overlay_answers` carry one flat object keyed by question — a `number` answer as a JSON number (given or inferred, the value the install was sized with), a `string` answer as a JSON string, and a `secret` question as its NAME over the marker `{"secret": true}`, never its value. An application's render on the VM or beside it reads `state.overlay_answers.documents_gb` and finds `5`. `plan.md` and the plan screen print the answers on one `answers:` line, a secret shown by its name only. The three schemas name the shape; the addition is additive and the document versions do not move. An answer to a question the overlay does not ask is still refused by name, and `plan` is unchanged for an overlay with no questions. **Candor: this closes a defect that shipped in every ArgonDBCloud from 1.0.0 through 1.0.3** — only `string` answers were recorded (as `{ value, source, basis }` records), and every `number` answer was consumed into the price lines and dropped. The P5b rehearsal of 2026-10-28 installed the ERP's own document on the served 1.0.2 and found its two answers (`documents_gb` 5, `emails_per_day` 50) nowhere in `plan.json` or `state.json`, while the ERP's render reads the install's state for its configuration — so on those versions the render had nothing to read. The `{ value, source, basis }` string records are REPLACED, not kept beside the new shape (no reader in the field read that shape); which answer was given and which inferred is still in `plan.overlay.questions[]`. The ERP's document as given (sha256 `2943651cea54…`) is a fixture, planned in the tests with both numbers read back. - **Two installs in one VPC share the S3 gateway endpoint: `plan` adopts a standing endpoint by service name and route table, or refuses by name, before any call** (P5b row 4). A VPC route table takes ONE S3 prefix-list route, and 1.0.0 through 1.0.3 created one S3 gateway endpoint per install on the default VPC's main route table, so a second (b) install in the same VPC stopped at `s3-endpoint` with `RouteAlreadyExists` (measured 2026-10-28 with two lanes on one scratch account). `argondbcloud plan` under a live provider now reads the install's route table before any call and prints one line into `plan.md` and on stdout: `s3-endpoint: ADOPTED (owner ) on ` when another install's endpoint stands on the table — the plan's `s3-endpoint` step becomes a shared adoption of it (`adopt: { shared, from_install, provider_id, route_table, owner_tag }`), the apply probes it by id and records it `adopted` (never re-tagged), the census lists it under `adopted` with its owner and never counts it, and the teardown leaves it standing with one row saying whose it is; `s3-endpoint: NEW (…)` when the table routes none, and the install creates its own as before. This is the shape the 1.0.3 `restore` already used for the source's endpoint, now every install's. An adopted endpoint that is gone at `apply` or `apply --resume` (its owner torn down, the route free) is created as the install's own and the apply continues. **`plan` refuses by name, exit 2 and no document**, for the one case where the adoption cannot be made exact: an endpoint with no `argondbcloud:install` tag (not an ArgonDBCloud install's, or one the engine cannot name) or a policy that is not the default allow-all (the install's bucket may be excluded by it) — `refused: the VPC's route table already routes S3 through , another install's (); ; nothing was created`. A read the role cannot make prints `s3-endpoint: NOT READ ()` and the plan continues as before this release; so does a tape recorded before the read existed. Proven live on the scratch account on 2026-10-29: two (b) installs in one VPC, the second planned while the first stood, both answering `select 1`, the second's teardown leaving the first's endpoint standing and the first's census unchanged, then the first torn down to census zero. - **The `box-ready` refusal says what the operator asks first: the instance's status checks, its console tail and whether the command channel registered — and the wait refuses EARLY on a stopped or impaired instance** (P5b row 5). When a `box-ready` (AWS) or `vm-ready` (Azure) wait refuses — the VM never opened its PostgreSQL port within the apply's 1500 s bound — the refusal's line now carries, beside the log path on the instance it named before, the instance by id with its state and its two status checks (EC2 `DescribeInstanceStatus`: system and instance reachability, `ok` / `impaired` / `initializing`), the command channel's state (`registered` / `not registered` when the plan's role carries one; `none: the plan carries no step` when it does not) and the last 12 lines of its console output (EC2 `GetConsoleOutput`, the boot's own stamps, each line cut to 120 characters). The same diagnostics are recorded in `state/v1` under the step's `failed` record (`reason` is the printed line, `diagnostics` the fields), so a later `census` or a report reads them without the console; **a successful step's record is unchanged**. While it waits, the probe reads the status checks every minute and refuses EARLY by name — `the wait was ended early at s of its 1500 s bound: the provider reports the instance stopped` (or `… status checks impaired`) — when EC2 reports the instance stopped, terminated or `impaired`; the bound stays for the case where EC2 says `ok` and the port never opens. `upgrade`'s step 6 (the box-ready probe through the address) refuses with the same diagnostics. The recovery when it refuses: teardown by plan, a new install name, re-apply (design §4.2). Measured on 2026-10-28: P5b's VM spent 415 s in cloud-init's local stage and never opened its port in 1500 s, and the 1.0.2 refusal said only "the box at : did not answer within 1500 s (… its log is /var/log/cloud-init-output.log on the instance)" — a path unreadable without a command channel. - **A tunnel-fronted overlay carries no Route 53 zone or ACM certificate: the worked overlay follows the zone ruling, `plan` prints one `ingress:` line and refuses a certificate or record on a tunnel hostname, and the tunnel kind gains a DNS-only direct-reach record** (P10, under the zone ruling [D-2026-10-29-7d9912]). The component's worked overlay for the ERP (guide 8 §3.3 and `crates/argondbcloud/examples/splink-erp-post-install-overlay.json`, version 2026.10.29) carries the Cloudflare `tunnel` line and nothing else for ingress; the `erp-dns` and `erp-cert` lines are gone, because the domain stays in Cloudflare — the tunnel's hostname routes are the DNS records and TLS terminates at Cloudflare. A test holds the guide's fence equal to the example file byte for byte. **`plan` prints one `ingress:` line per overlay**, in `plan.md`, on the plan screen and as `plan/v1`'s `ingress` field, read from what the planner built: a tunnel-fronted overlay reads `ingress: tunnel (cloudflare) — hostname routes are the DNS records; TLS terminates at Cloudflare; no Route 53 zone, no ACM certificate`, with `; DNS-only A record for direct reach` appended when the tunnel carries one; a customer whose DNS is on AWS reads `ingress: route53 + acm — , `; an overlay with no ingress resource reads `ingress: none`. **Two shapes are refused by name**, at `argondbcloud validate` (which now runs the overlay validator on an `overlay/v1` document) and at `plan` (exit 2, no document): a `tls-certificate` whose domain is also a `tunnel` hostname of the same overlay (it would never be served, because TLS terminates at Cloudflare), and a `dns-record` for that name (it duplicates the route Cloudflare already serves); the line names both resources and the ruling. An overlay that carries neither kind is accepted silently, as before. **The `tunnel` kind gains an optional `direct_record`** — `{"name": , "ttl": }` — planned as the step `overlay--direct` of the new kind `tunnel-record`: a DNS-only (unproxied) A record in the tunnel's Cloudflare zone at the install's public address, created through Cloudflare's API with the same token in the same apply, probed on a resume, listed by the census, torn down before the tunnel, and unpriced with the tunnel [D-2026-10-28-c73b0b]. A `teardown` or `census` without the token reports the record `unread` beside the tunnel. A step's `after:` that names a tunnel with the arm waits on the record. **The Route 53 `hosted-zone`/`dns-record` and ACM `tls-certificate` kinds are unchanged**: kept as built, and documented as not for the ERP's overlay — section 5 (ii). - **`argondbcloud -V` prints `ArgonDBCloud 1.0.4 ()`**, the sha equal to `BUILD.txt`'s first line and the channel's `source_sha`, as at 1.0.1 through 1.0.3. ## 4. Credentials and what the installer does to your account (candor) Unchanged from 1.0.3 (`docs/releases/argondbcloud-1.0.3.md` §4 and the three files before it, carried forward in full), plus what the five served rows add — every one of them a READ on the installer's own credential, none a new write. The `user-data-append` step calls `ec2:GetConsoleOutput` on the install's instance (the VM's role needs nothing for it). The `box-ready` wait calls `ec2:DescribeInstanceStatus` every minute and, on a refusal, `ec2:GetConsoleOutput` and `ssm:DescribeInstanceInformation`; a role without them gets `console: not read: ` / `command channel: not read: ` on the line — named, never silent — and a production role minted before this release may lack `ec2:GetConsoleOutput` (the installer policy's §4.1 row lists them). `plan` under a live provider reads the VPC's main route table and its S3 gateway endpoints (`ec2:DescribeRouteTables`, `ec2:DescribeVpcEndpoints`) before any call; an ADOPTED endpoint is probed by id and never re-tagged, and its owner's teardown, not this install's, deletes it. The answers record makes no call. The tunnel kind's direct-reach record is a Cloudflare API call under the overlay's own token, tape-only until the production account exists (section 5 (i)). The (a) and (b) install lists are MEASURED; the ingress kinds' list is PROPOSED in design §4.1, and the action lists above are proposed from what the client calls under the scratch role's `AdministratorAccess` until the next CloudTrail read. ## 5. Limits and what 1.0.4 does not do - Every alternative the advisor shows as NOT YET INSTALLABLE at this cut, by name, from section 1's output: (c) on aws; (b) on azure; (c) on azure — `argondbcloud advise --json` at the cut, pasted in section 1. - **(i) The tunnel arm and the DNS-only direct-reach record have never been applied live, and the tunnel census reads `unread` without a token.** The tunnel kind and its new `direct_record` are proven by their recorded tapes only (`aws/ingress-tunnel.json` with the record, `aws/ingress-tunnel-no-direct-record.json` without); every Cloudflare call in the engine is written from Cloudflare's v4 API reference and has not been made against an account. The token is a `secret` overlay answer at apply time, written nowhere — tape-only until the production account exists [D-2026-10-28-7e53d0]; `census` or `teardown` without `--answers` lists the tunnel kind and its record as `unread`. The record's probe and census read Cloudflare record comments in every zone the token reaches; a token scoped to many zones pays one listing per zone. The record takes the install's public address as an A record: no AAAA arm, no record for a name outside the tunnel's own zone. The served check at this cut planned the tunnel line and did not apply it. - **(ii) The zone shape, as ruled [D-2026-10-29-7d9912]:** the domain stays in Cloudflare; production ingress is the Cloudflare tunnel — its hostname routes are the DNS records, TLS terminates at Cloudflare, and a DNS-only A record gives direct reach. **The component's `hosted-zone`, `dns-record` (Route 53) and `tls-certificate` (ACM) kinds are kept as built and documented as not for the ERP's overlay; an Azure-DNS or Route 53 customer is the row that exercises them** (Steve's block of 2026-10-29 ~5:1xam ET, Q1, as worded; its id lands at the registry regeneration carrying that block). The Azure DNS and certificate halves are `not-buildable` rows (A8, owed to a DNS customer). ACM issuance has never been measured ISSUED by the component on any zone (every live run used a scratch zone nobody delegates to, and the issuance wait refused by name at its bound), and no measurement is owed on the ERP's path (row P9 retired). The `ingress:` line reads from the steps the planner built, so on Azure an overlay's `dns-record` or `tls-certificate` lines, which are not built there, do not appear in it; their `NOT BUILT` rows say why. - **(iii) The Azure halves of the five rows are written against ARM's documented shape and NOT run live**: the append's read-back on Azure goes through Run Command with the P3 wrapper and was not run on this tier (as the post-install steps' Azure half is not); Azure's `vm-ready` reads the VM's instance view for the state, the two checks and the early refusal but reads NO console — the engine's VM carries no boot-diagnostics profile, so the line says `console: not read: boot diagnostics are not enabled on the engine's VM` by name; Azure has no S3 gateway endpoint step and the route-table read does not run there; the quota read on Azure prints every line `NOT READ` (1.0.3's limit, unchanged). Shape (b) on Azure stays NOT YET INSTALLABLE; `upgrade`, `backup` and `restore` are AWS-only. - **(iv) No `resize` and no `teardown` as a planned operation, no health monitor** — O3–O6 follow after 11/09 in the plan's order. - **(v) No cross-region copy of the bucket in 1.0.x** — a region-wide loss of the bucket is not covered, and `backup` and `restore` stay inside one region; the advisor still prices a `backups-copy` line the engine does not build. - **(vi) `restore --at ` is refused by name** — ArgonDBCloud restores NAMED points. **A restore's lake is read-only**: the restored catalog names the SOURCE bucket's immutable files at the point through a read-only grant, and a lake write from the restored install is refused by IAM. **The restore target is named by the operator** (`--name `), refused by name if an install of that name exists in state [D-2026-10-29-882415]. A restore re-plans the (b) list only: an overlay's ingress and post-install resources are not re-created on the restored install, and the restored VM's user data carries no overlay append. - **(vii) Shape (c) is priced from a bench on one box** (design §3.3). Its pageserver line reads the c50 bench's 50 clients as 50 tenants' load — an ASSUMED basis until a cut destined for ArgonDBCloud runs the multi-tenant bench on our fleet (design §7's cut checklist, D14): **not yet measured at this cut.** The 1.0.4 cut ran no bench; the figure stays owed to the row the plan names. - **The append's own limits.** Exactly two placeholders are substituted (`${install.id}`, `${install.name}`); a braced shell form (`${HOME}`, `${1:-x}`) is read as a placeholder and refused — write it without braces or in a script the append fetches. The append is bounded by the cloud's user-data size, not its own: roughly 3 KiB remain on shape (b) under EC2's 16 KiB; a larger installer fetches a script from a place the VM reaches (the install's own bucket). The read-back is bounded at 900 s after `box-ready` and refused by name past it (`apply --resume` reads again); on AWS it reads the serial console, which carries cloud-init's output with the kernel's prefix on every line, and the engine finds its marker inside the line. Shape (c) has no single VM: an overlay with the field under shape (c) gets a named `not-buildable` row (`user_data_append`) and nothing is appended. The state file `~/.argondbcloud/installs//state.json` is on the operator's machine, not on the VM: an append that renders from it there reads a path that does not exist — where the application's render reads the install's answers from on the VM is an open question for the ERP coordinator and the program agent. The engine's own first-boot `curl` of the 471 MB ArgonDB tarball from the release channel is one `curl` with no retry and no resume: a connection reset costs the whole install and 1500 s of `box-ready` (measured twice on 2026-10-29; escalated, not this cut's change). - **The answers record's own limits.** A `secret`'s shape is its name and the marker only; the value stays on the VM under `/etc/argondbcloud/secrets/` and is written to no document, screen, log or tape. A reader of `overlay_answers..value` built against 1.0.1 through 1.0.3 reads a bare string now. Inferred answers are recorded too, not only the ones the operator typed. - **The endpoint adoption's own limits.** The read covers the AWS S3 gateway endpoint on the VPC's MAIN route table — the table the engine attaches the endpoint to; an endpoint attached only to a subnet's own route table is not read, and a plan that names `parameters.vpc_id` reads that VPC's main table. The adoption is decided at `plan`: an endpoint that appears between the plan and the apply still stops the apply at `s3-endpoint` with the provider's `RouteAlreadyExists`, before `RunInstances`, and `apply --resume` after the neighbour's teardown continues. An adopted endpoint is another install's: its owner's teardown deletes it, and the adopting install's bucket traffic then leaves through the VPC's ordinary route until that install's own `apply --resume` creates its own endpoint; nothing warns the adopting install when its owner goes. The policy judged "default allow-all" is a statement allowing `*` on `*` with no condition; any other policy is refused, including one that would have admitted the bucket. The census lists a shared endpoint from the install's own state record, so a state file lost everywhere loses the row too. - **The `box-ready` diagnostics' own limits.** The 1500 s bound is unchanged (a P2 figure; a question for Steve, not this release's). EC2 posts an instance's console output minutes after boot and refreshes it only every few minutes; a refusal in the first minutes can read `console: not read: GetConsoleOutput returned no output yet`. The refusal shape is proven on a recorded tape (a VM that never boots is not reproducible by design); the live polarity — a `box-ready` success record beside the instance's status checks `ok` — is in this cut's lane report. - **The swap step of `upgrade` is not reversible and there is no rollback; a restore point is crash-consistent; the quota read covers six quotas; the post-install steps still stop the apply at the first failed row** — every one of 1.0.3's §5 limits on the day-2 verbs, the quota read and the post-install order carries forward unchanged. The worked overlay's four scripts in guide 8 are placeholders that exit 2 on the missing ERP package, which is the ERP's installer-package row; the ERP's own overlay is the ERP's to change, and nothing in this release edits it. - **Linux x86_64 only.** The macOS `argondbcloud` binary RESTS [D-2026-10-25-a7334e]; it is not planned for a 1.0.x. - The matrix is five versions: 1.5.7.20, 1.5.7.19, 1.5.7.18, 1.5.7.17, 1.5.7.16. Nothing older and nothing newer installs; the next ArgonDB release needs the next ArgonDBCloud cut. The lake in the bucket needs 1.5.7.19 or later: a (b) plan pinned to an older row keeps its lake on the cache disk and says so. - The (a) VM's first boot takes the Linux artifact from `releases.argondb.ai`: the VM needs outbound HTTPS, and a boot whose download or sha256 check fails writes `/etc/argondb/bootstrap-failed` and the apply's `box-ready` step times out after 25 minutes naming the port (now with the status checks and the console tail on the line); the cloud resources are then yours to `teardown`. `upgrade --yes` needs the same outbound reach from the VM for the target artifact. - Shape (a) has no backup of its own beyond the daily snapshot policy (AWS) / Recovery Services policy (Azure) under `backups`, and no `backup` or `restore` as an operation: losing the VM and its disk loses the database. - The (b) VM stopped answering for under a minute at about 1.75 GiB written in two of three K8 runs; later runs did not see it recur; the cause is unmeasured. - A new Azure subscription can refuse the planner's VM size (every v5 size was NotAvailableForSubscription in eastus on 2026-10-24); the plan's cost line still prices the size the planner chose. Azure Backup's soft delete cannot be turned off on such a subscription: the teardown leaves the VM's backup item soft-deleted for 14 days inside the vault, then deletes the vault over it. On Azure, `outputs.ipv4` stays null under the live client. - The shipped tapes cover shapes (a) and (b) on AWS only (the (b) one with the lake in the bucket, and the two-step post-install one), and replay only against plans made from the alternatives shipped beside them, under their own install name, seed and the DEFAULT ArgonDB version: a plan with `--argondb-version` other than 1.5.7.20 has a different instance call, and the replay refuses it by name (record your own with `--record`). - The engine builds the overlay types `s3-bucket`, `blob-container`, `dns-record`, `tls-certificate`, `tunnel` (with its `direct_record`) and `run-after-install`; email relays, queues and web front ends are `not-buildable` rows the application provisions itself. On shape (a) an overlay's permissions are recorded `not-granted` (the (a) VM has no identity). Azure's overlay storage account is Standard_LRS with no versioning or lifecycle rule; the overlay bucket on AWS is unversioned (its own `noncurrent_days` stays 30 and is moot). - One design question stays OPEN and is not settled here: §3.3's request rule beyond its measurements. - This cut's live install adds minutes of VM time and a bucket held for under an hour on AWS on 2026-10-29; the bill is read after the day settles. ## 6. Build facts Measured from the artifact by `scripts/release/release-verify-argondbcloud.sh` against the publish rehearsal at the cut (the real `publish-release.sh` into a scratch tree, `file://` base), and from the build itself: ``` artifact argondbcloud-1.0.4-linux-x86_64.tar.gz 16,874,869 bytes sha256 9610bd085323f6a054fb1f1b676b03821b03f3c4360c2c5bdc4ce0782bda54c0 source_sha 2360b40c8d14e8172979826dd96b4ff62431288e (the cut commit; built ALONE on splink-coordinator under fleet slot 2 with ARGONDB_BUILD_SHA set to it, packaged by scripts/release/build-artifact-argondbcloud.sh) build_sha 2360b40c8d14 (argondbcloud -V prints it; BUILD.txt's first line; refused at packaging if it differed) supported_argondb 1.5.7.20 (https://releases.argondb.ai/linux/LATEST re-read at the build moment, 2026-10-29 22:2xZ: still v1.5.7.20, published 2026-10-29T03:27:07Z, sha256 2f81b7ab972f382a7c728d99db589f8ead7881e327172ff3f788c7b8be4fb201) supported_argondb_all 1.5.7.20 1.5.7.19 1.5.7.18 1.5.7.17 1.5.7.16 glibc_floor 2.39 (measured from the binary; the build host's glibc is 2.43) rustc 1.94.0; features live-aws,live-azure; binary says ArgonDBCloud 1.0.4 (2360b40c8d14) built_utc 2026-10-29 22:23:51 UTC tapes 6 files under share/argondbcloud/tapes/ (aws-a, aws-b, aws-b-post-install, their alternatives) + README prices 4 recorded price files (aws/us-east-1 2026-10-20, 2026-10-24, 2026-10-27; azure/eastus 2026-10-24 — the same recorded price book 1.0.2 and 1.0.3 shipped) release-verify-argondbcloud.sh against the publish rehearsal, GREEN: sha256: downloaded 9610bd085323f6a054fb1f1b676b03821b03f3c4360c2c5bdc4ce0782bda54c0; LATEST 9610bd085323f6a054fb1f1b676b03821b03f3c4360c2c5bdc4ce0782bda54c0; SHA256SUMS 9610bd085323f6a054fb1f1b676b03821b03f3c4360c2c5bdc4ce0782bda54c0 build sha: 2360b40c8d14 = BUILD.txt line 1 = LATEST source_sha[0:12] binary: ArgonDBCloud 1.0.4 (2360b40c8d14); supported_argondb 1.5.7.20 (the LATEST agrees); the matrix: 1.5.7.20 1.5.7.19 1.5.7.18 1.5.7.17 1.5.7.16; tree SHA256SUMS OK tapes: 6 shipped under share/argondbcloud/tapes/ provenance: source_sha 2360b40c8d14e8172979826dd96b4ff62431288e provenance: built_utc 2026-10-29 22:23:51 UTC provenance: glibc_floor 2.39 (measured: the highest GLIBC_x.y the binary imports) advise: a (aws) installable=True advise: b (aws) installable=True advise: c (aws) installable=False [NOT YET INSTALLABLE] advise: a (azure) installable=True advise: b (azure) installable=False [NOT YET INSTALLABLE] advise: c (azure) installable=False [NOT YET INSTALLABLE] not yet installable at this LATEST: (c) on aws; (b) on azure; (c) on azure release-verify-argondbcloud: PASS — file:///tmp/p104-rehearsal.25tFZp/argondbcloud/v1.0.4/argondbcloud-1.0.4-linux-x86_64.tar.gz sha256 9610bd085323… installs: ArgonDBCloud 1.0.4 (2360b40c8d14), supported_argondb 1.5.7.20 (the matrix: 1.5.7.20 1.5.7.19 1.5.7.18 1.5.7.17 1.5.7.16), (a) installable on aws and azure against the recorded price book; not yet installable: (c) on aws; (b) on azure; (c) on azure; published 2026-10-29T22:24:22Z and RED against a fixture LATEST whose sha256 is wrong: release-verify-argondbcloud: FAIL — step 2: the downloaded artifact's sha256 9610bd085323f6a054fb1f1b676b03821b03f3c4360c2c5bdc4ce0782bda54c0 differs from the LATEST's 0000000000000000000000000000000000000000000000000000000000000000 (refusing to unpack) The same script against the PUBLISHED channel, and the (b) install from the published artifact on AWS, are in the lane report (they run after this file is frozen and served). The twin landing at the ERP shape, run at this cut as a step before the publish [D-2026-10-28-eaaed6], on ms-01 against the box binaries built from the cut's tree (the argondbcloud artifact carries no box binary, so the gate measures the tree's release build at the cut's Rust bytes): cut-twin-landing: PASS — twin landing at the ERP shape: 24 twins in 7.8 s against 30 s (1.0.4, sha adecda033ea97ccb468e930d77c18ce964b73d2b, ms-01) (the sha is the version-bump commit adecda033ea9, whose Rust tree is byte-identical to the cut commit 2360b40c8d14: `git diff --stat adecda033ea9 2360b40c8d14 -- crates/ storage/ Cargo.lock` is empty) ``` The multi-tenant bench of design §7's cut checklist (D14): **not yet measured at this cut.** The RELEASE-NOTES.md inside the tarball is this file as it stood at the cut commit (before sections 1 and 6 were filled); the served `RELEASE-NOTES.md` beside the artifact is this frozen file.