--- class: reference purpose: ArgonDB v1.5.7.13 AWS CloudFormation template notes - the aws channel moved from v1.5.7.3 to the current Linux cut. template: product --- # ArgonDB v1.5.7.13 on AWS — CloudFormation template > **Published 2026-10-16.** One AWS VM running the published ArgonDB > v1.5.7.13 Linux release — the current Linux cut, tagged `v1.5.7.13` at > `924d757361` and published on the linux channel 2026-10-13 10:16pm ET. > The aws channel stayed at v1.5.7.3 while ten Linux cuts shipped (v1.5.7.4 > on 2026-10-04 through v1.5.7.13 on 2026-10-13); this template moves it to > v1.5.7.13 in one step, for the cloud estate stand-up that installs from > it. Nothing was rebuilt for this channel: the template pins the Linux > artifact the v1.5.7.13 cut published and installs it with the artifact's > own `install.sh`. **Everything the v1.5.7, v1.5.7.1, v1.5.7.2 and v1.5.7.3 > channel notes say — what deploys, the security model, the data format, > the costs, the limits, the restart fix, the per-tenant tail, the > deleted-publisher fix and the ERRATA on the v1.5.7 page — is unchanged > and is not restated here**: read `docs/releases/aws-v1.5.7.3.md`, > `aws-v1.5.7.2.md`, `aws-v1.5.7.1.md` and `aws-v1.5.7.md` for it. This page > carries what this cut carries since v1.5.7.3, the transcripts of what was > validated for THIS template, the hand upgrade for a VM that stays on the > v1.5.7.3 template, and the limits. > > **Stated plainly.** The Linux notes from v1.5.7.6 through v1.5.7.13 > record the aws and azure one-click channels as retired for new cuts, with > AWS and Azure to ship through ArgonDBCloud [D-2026-10-05-e957f6], and the > v1.5.7.13 Linux notes say no aws or azure sibling of that release will be > cut. Those pages are frozen and are not edited by this publish; this page > is the record that the channels did move, to v1.5.7.13, on 2026-10-16. > ArgonDBCloud is not in the artifact this template installs (v1.5.7.13 > Linux notes, section 5) and is not what this template deploys. ## 1. What this cut carries since v1.5.7.3 Ten Linux cuts, in order. v1.5.7.4 through v1.5.7.10 have notes pages in the repository (`docs/releases/v1.5.7.N.md`); v1.5.7.11, v1.5.7.12 and v1.5.7.13 have no Linux notes page in the repository — their notes are served at `https://releases.argondb.ai/linux//RELEASE-NOTES.md` and each is cited here by its tag's commit. Every cut from v1.5.7.4 on except v1.5.7.5 was cut from `main`'s tip, not picks-only, and its notes say so (each notes' section 1). **On the VM this template creates — a NEW VM on a NEW empty disk, holding ONE database, `[compute] per_tenant` off — none of it opens a port, none changes the first boot (measured in section 3), no catalog or lake migration runs, and every new configuration key ships default-off.** Most of what follows is reachable only after you create tenants, views or publications on the VM. - **v1.5.7.4** (tag `31753a4aa147`, `docs/releases/v1.5.7.4.md`): the box's own log rotates without a NUL gap and holds its cap (section 2); the maintenance worker sweeps only the tables it can resolve, so two tenants no longer starve the view maintainer (3); an append publication's body is the generated one (4.6); a deleted tenant's lake data has a door, `argondb lake drop-orphan --database` (4.7); `system list` reads every system 5/5 (4.8); the sidecar creates its tenant user through a scoped helper, `argondb box install-useradd-helper --user `, run once as root (4.9) — **the one install-time difference since v1.5.7.3: the artifact's `install.sh` now PRINTS that root step at its end rather than taking it; this template does not take it, and a one-database VM with `per_tenant` off does not need it**; three cloud-facing configuration keys ship default-off — `[storage] remote` now also backs up the WAL, `[storage] sole_owner`, `[lake] scheme = "azure"` — and a box that sets none behaves as before (7; this template sets none); the ArgonDBCloud crates are not in the artifact (8); the restart procedure (11). - **v1.5.7.5** (tag `c607c0aa2fcb`, `docs/releases/v1.5.7.5.md`, picks-only on v1.5.7.4): the view maintainer is never silent when stuck, and a failed cut says why (section 2). - **v1.5.7.6** (tag `ca99f48deb53`, `docs/releases/v1.5.7.6.md`): the maintenance sweep skips a table whose rows have not changed since its last scan (2); a box's maintenance metrics are served by the process that writes them (3); the tail's per-table row watermark in `argondb tail freshness` and `argondb view list` (4); the maintenance worker's metrics endpoint omits the ingest-plane series it never writes (5). - **v1.5.7.7** (tag `3e3afe458017`, `docs/releases/v1.5.7.7.md`): a publication landing under load is no longer refused `consent-pin-behind-run-start` when no consent has changed (2); `tenant create` keeps its create journal under a second writer, and `tenant delete` repairs a tenant left without one (3); `argondb view list` survives a table that vanished mid-listing, and `--database` filters it (4); the catalog authorizer's check cache ships ON at 1 s (5; a restart is what turns it on, section 11). - **v1.5.7.8** (tag `52736d8427fe`, `docs/releases/v1.5.7.8.md`): a session over two tenant warehouses no longer refuses the pin (2); the view maintainer's memory pool is a bounded Greedy pool (3), a refused recompute releases every consumer it registered (4), an abandoned recompute leaves no consumer live (5); `publication land` reads the published table at its own coordinate and the `landed` line names the pin (6); `tenant create` past about a hundred tenants, under the estate pass, and after a restart (7); the UNDECODED-WINDOW line after a restart with tenants is WARN (8); the hourly orphan sweep fits its cadence on an idle box (9); the memory knob `ARGONDB_VIEWS_MEMORY_MB` (14). - **v1.5.7.9** (tag `5a18eb1c253e`, `docs/releases/v1.5.7.9.md`): a cross-tenant landing's pin no longer refuses on one `NamespaceNotFound` for a namespace its own walk just listed, and its refusal names the read principal (2). - **v1.5.7.10** (tag `8952dab85e81`, `docs/releases/v1.5.7.10.md`, the hotfix): an aggregate view keyed on an alias of a source column refreshes again — the v1.5.7.9 regression (2); a cut that fails in one warehouse no longer duplicates rows in the other warehouses' keyed lake copies (3); a cross-tenant landing's pin no longer refuses when the catalog answers one load of a listed `_argon_gaps` table "not found" (4). One erratum stands against its served notes (appended 2026-10-12). - **v1.5.7.11** (tag `f7459f35de87`; no Linux notes page in the repository, served at `https://releases.argondb.ai/linux/v1.5.7.11/RELEASE-NOTES.md`): `argondb clone-box`, a throwaway box per gate run from a cold golden copy on its own port band (2); cut on demand — a publication landing asks the tail for a cut instead of waiting for the next one (3); the view maintainer's `pass ended` line counts the refreshes a pass ran (4); a reader pin no longer refuses "aged past the retention window" for a table created after its coordinate (5). - **v1.5.7.12** (tag `5d431498dce7`; no Linux notes page in the repository, served at `https://releases.argondb.ai/linux/v1.5.7.12/RELEASE-NOTES.md`): a view maintainer's ring read has its own deadline, 94 s by default (`ARGONDB_VIEWS_RING_STEP_SECS`, the one new knob — leave it unset), which abandons the one view and not the pass, and both ends of every ring read write a line (2). - **v1.5.7.13** (tag `924d757361`; no Linux notes page in the repository, served at `https://releases.argondb.ai/linux/v1.5.7.13/RELEASE-NOTES.md`): a view's `ring` step ends when its ring read ends, so a stall after the read is reported as `awaiting recompute` with the bound that applies — **the earned-view stall itself is NOT fixed and its cause is not established** (2); a one-row publication landing pays its own tables' cut, not the whole tail pass (3); no new knob (6). ## 2. What deploys Exactly what `docs/releases/aws-v1.5.7.1.md` "What deploys" says, with the artifact pins moved to v1.5.7.13: `argondb-1.5.7.13-linux-x86_64.tar.zst` (490,163,149 bytes, sha256 `1e5321b0ddb913c3d68f3a0fa573e8101ea70d42a2300b9ec21ad4d0ba8c0b62`, source `924d757361`, tag `v1.5.7.13`), downloaded from `https://releases.argondb.ai/linux/v1.5.7.13/`, verified against the sha256 hard-coded in the template before anything is installed, installed by the artifact's own `install.sh` into `/opt/argondb`, supervised by systemd as `argondb-box.service`. The embedded payload is the canonical `user-data/argondb-bootstrap.sh`, byte-identical in both templates at 14,184 rendered bytes (`./sync-user-data.sh --check`). The code citations in the templates were re-read at the cut sha: `resolve_bind` moved from `serve.rs:4968` to `serve.rs:5997` and `resolve_surface_listen` from `lib.rs:6212` to `lib.rs:6307`, both bodies byte-identical to the v1.5.7.3 tag's; `install.sh`'s two `argondb-env.sh` exports are at lines 343-344. The box still binds `127.0.0.1` by default and the MCP admin and write surfaces stay loopback. AWS's `aws/argondb-vm.cfn.yaml` is published at `https://releases.argondb.ai/aws/v1.5.7.13/argondb-vm.cfn.yaml`; to launch, download `https://releases.argondb.ai/aws/v1.5.7.13/argondb-vm.cfn.yaml` and use "Upload a template file" in the CloudFormation console (two steps, an AWS constraint on console deep-links). ## 3. What was validated **Structural, credential-free**, each behind a positive control, in two containers on the build node (`python:3.12-slim` with `cfn-lint`, `mcr.microsoft.com/azure-cli`; the two template files copied in with their sha256 printed equal to the committed bytes), on the XPS under a held fleet slot through `scripts/fleet-exec.sh`: ``` VALIDATE START 2026-10-16T11:57:44Z 2bf362f8b790f97bb1e0211d4e0cab74d53d51d66c1bb08abc8ae60c0786717d argondb-vm.cfn.yaml be71b8a0eae9cbb09848be8ba9a21f23d05cc3431e952613a16742045a7711a9 azuredeploy.json ########## cfn-lint ########## cfn-lint cfn-lint 1.57.2 cfn-lint rc=0 (MUST be 0) ########## POSITIVE CONTROL: cfn-lint MUST fail on a broken copy ########## E3006 Resource type 'AWS::NoSuch::Thing' does not exist in 'us-east-1' /t/broken.yaml:279:5 broken cfn rc=2 (MUST be non-zero) CFN-OK ########## az bicep decompile / build ########## az 2.90.0 decompile rc=0 (MUST be 0) build rc=0 (MUST be 0) 1:metadata comments = 'ArgonDB v1.5.7.13 on one Azure VM, installed from the PUBLISHED Linux tarball at https://releases.argondb.ai. No container image and no registry credential. The customData below is GENERATED: variables.cloudConfig is the canonical cloud-config from deploy/cloud-oneclick/lib/user-data-tool.py and the identical bytes appear in aws/argondb-vm.cfn.yaml. Edit user-data/argondb-bootstrap.sh, then run ./sync-user-data.sh --write; ./sync-user-data.sh --check refuses drift. SECURITY POSTURE: the box binds 127.0.0.1 by default (crates/argondb-ctl/src/serve.rs:5997, resolve_bind, re-read at the v1.5.7.13 cut sha), so this NSG opens only SSH and the recommended connect route is an SSH tunnel. databaseAllowedCidr is the deliberate deployer-supplied exception; it opens 5432/8018/8019 to that CIDR alone. The MCP admin (8020) and write (8017) surfaces stay loopback in every case — each has its own loopback-unless-configured variable, so a 0.0.0.0 global listen reaches neither the control plane nor the write plane (crates/argondb-mcp/src/lib.rs:6307, resolve_surface_listen); that is why v1.4.0\'s argondb-write door adds no rule to this NSG. Every credential is generated on the VM and no output carries one. SINCE v1.5.5 (docs/releases/v1.5.5.md, section 18): with the bind widened by databaseAllowedCidr AND [compute] idle_stop on, an off-box client is now asked for a password where v1.5.0-v1.5.4 served it as a loopback client; this template leaves idle_stop off, so the default posture was never exposed either way. V1.5.7.13 AND DATA ON DISK: this template always creates a NEW VM on a NEW managed OS disk, so there is no prior data directory: NEITHER of the box\'s two refusals over old data is reachable here, and the one-time uuid re-derive (docs/releases/v1.5.4.md, v1.5.3 section 16, carried forward through v1.5.7.13) finds nothing to re-derive. All three ARE reachable if you later attach a RESTORED disk. A v1.3.x lake store: v1.4.0 changed the on-disk layout, so run \'argondb lake-store migrate\' first (docs/releases/v1.4.0.md, \'Upgrading\'); no release since has changed that layout. A v1.4.x LAKE: since v1.5.0 a lake table is named by database/schema/table and the box refuses to start its tail over old flat-named tables, printing \'LAKE IDENTITY GATE - REFUSED\' and leaving Postgres and the lake plane up as the migration window; run \'argondb lake migrate-identity\' (a catalog-only move; docs/releases/v1.5.4.md, \'Upgrading from v1.4.x\'). A v1.5.0-v1.5.2 LAKE holding a table with a uuid column: the first v1.5.4-or-later tail start re-derives that table once, at the current position, and its snapshot history below that point is gone. v1.5.5 through v1.5.7.13 add no lake schema change and no migration a one-database box needs: \'argondb estate migrate\' (v1.5.6) versions ArgonDB\'s own per-company schema inside tenant databases, and the v1.5.7 boot migration of a publication\'s consent tables (docs/releases/v1.5.7.md, section 1) finds no publication here; upgrading a box is replacing the binaries. WHAT v1.5.6 THROUGH v1.5.7.13 CHANGE ON THIS VM (docs/releases/v1.5.6.md, v1.5.6.1.md, v1.5.7.md, v1.5.7.1.md, v1.5.7.2.md, v1.5.7.3.md and the v1.5.7.4 to v1.5.7.13 notes; v1.5.6 and v1.5.6.1 never shipped on this channel; a VM from the previous template ran v1.5.7.3, from the three before it v1.5.7.2, v1.5.7.1 and v1.5.7, and from the one before those v1.5.5). None of it opens a port here. (1) The shipped extension set, the glibc floor (2.43) and the eight host libraries are as at v1.5.5: pgvector and the HTAP offload hook still do not ship. (2) The pooler key is \'on\', \'auto\' or \'off\', and a missing PgBouncer never refuses a boot (v1.5.6 section 10): the artifact\'s install.sh writes [pooler] enabled = \'on\' as a record of intent, this template installs no pgbouncer, and the box boots on the direct port (5432) saying so; install PgBouncer 1.25.2 or newer from the PostgreSQL apt repository and restart the box to get the pooled port (5632). (3) A fresh \'argondb tenant create\' and a default \'argondb estate migrate\' FINISH on v1.5.7 (v1.5.6.1 section 1, in this release from main); on v1.5.6 both refused. (4) A tenant key holding an underscore is REFUSED AT THE DOOR (v1.5.7 section 10): on v1.5.6 and v1.5.6.1 such a key took a lake box off the air at its next boot; a box that already holds one now boots with that database dark instead of down, and \'argondb destroy-tenant\' is the remedy. (5) Every company gets its own MCP token scoped to its own database (v1.5.6 section 3), and on v1.5.7 that token reads the company\'s own derived schema (section 8). (6) Sharing between tenants as data -- a publication names its grantees, lands by replace, merge or append, a cross-party mount needs the requester\'s accept, a continuous view lands as one slice per grantee (v1.5.7 sections 1-5) -- and the catalog-authz \'takes effect at next boot\' notice (section 13) are reachable only after you create a second database or publish a table. (7) [compute] per_tenant stays off by default; with it on, per-tenant compute has no count cap on Linux (section 7; the notes say an AWS/Azure approach to uncapped per-tenant compute is not designed), a sleeping company\'s application port answers 503 with a Retry-After (section 11), and there is no tenant move (section 9). (8) STOP THE BOX CLEANLY: v1.5.5 section 19 stated that an unclean stop of the catalog\'s PostgreSQL -- a kill, a power loss -- leaves a box that does not boot again until its catalog data directory is repaired by hand; v1.5.6 through v1.5.7.13 neither fix it nor restate it, so treat it as standing. \'systemctl stop argondb-box\' sends TERM to \'argondb serve\' with a 180 s stop timeout; whether every stop path through the autoShutdownTime schedule or a portal stop reaches the catalog\'s clean stop is NOT proven by this template\'s rehearsal, so prefer \'argondb stop\' on the VM before a scheduled (autoShutdownTime) or portal stop on a box that holds data you cannot recreate. (9) v1.5.7.1 (docs/releases/v1.5.7.1.md, section 1): a box that has run \'argondb tenant create\' comes back from a restart. On v1.5.7 the box\'s argondb-tail bound the FIRST timeline the pageserver listed rather than the box primary\'s, and \'tenant create\' cuts a timeline on this one-database VM too (per_tenant off or not), so a restart after \'tenant create\' could refuse the boot (\'QUARANTINED postgres__argon_estate__system at boot\', \'argondb-tail exited before it bound Flight ... refusing the boot\'); the aws/azure v1.5.7 channel notes carry it as an ERRATA. \'argondb serve\' now names the primary\'s timeline to the tail, which binds exactly that one and names every other as a tenant\'s or ORPHAN without streaming it; \'argondb tenant delete \' removes a tenant whole (rows, database, timeline, directory), and a hand \'DROP DATABASE\' is not a supported way to remove a tenant. (10) v1.5.7.2 (docs/releases/v1.5.7.2.md, section 1), the one product change of that fix release: a tenant on its own compute does its own lake work. With [compute] per_tenant = true the box spawns one argondb-tail beside each tenant compute, bound to that tenant\'s timeline, with the tenant\'s own lake paths and watermarks; the box tail serves only the box primary. No separate switch: this is what [compute] per_tenant = true means. A tenant\'s tail stops and wakes with its compute; while the tenant sleeps its lake does not advance, and the first query after wake pays the catch-up. On v1.5.7 and v1.5.7.1 such a tenant had no tail of its own and rows written through its compute never landed in its lake. This VM runs ONE database with per_tenant off, so nothing changes on it unless you turn per_tenant on in /var/lib/argondb/argon.toml; a tenant created under per_tenant on v1.5.7 or v1.5.7.1 gains its tail on the first v1.5.7.2 boot. (11) v1.5.7.3 (docs/releases/v1.5.7.3.md, section 1), the one product change of that fix release: deleting a tenant that publishes a continuous view no longer breaks the box. On v1.5.7.1 and v1.5.7.2, \'argondb tenant delete\' of such a tenant while its publication was in force left the dead publisher\'s view grant in the cross-tenant reader\'s roster (reader.views in /var/lib/argondb/lake-store-credentials.json), and every later \'argondb tenant create\', tenant-wall pass and \'publication land\' panicked (\'index out of bounds: the len is N but the index is N\', crates/argondb-query/src/lib.rs:496). v1.5.7.3 keeps the pin\'s roster and handles as one list, skips by name a granted view it cannot look up, and has \'tenant delete\' and the tenant-wall pass remove a dead owner\'s grants and print them by name. This VM runs ONE database, so the defect is reachable only after you create tenants and publish a view. A VM already running v1.5.7.2 was NOT upgraded by that template: replace its binaries with the v1.5.7.13 artifact\'s install.sh before restarting it; after the upgrade the first tenant-wall pass removes a dead publisher\'s grant by name and logs it, no hand edit needed; until then, revoke a tenant\'s view publications before deleting the tenant. A deleted tenant\'s lake data is still not removed. Nothing else changed: v1.5.7.3 is the v1.5.7.2 tag plus that fix, and the shipped guides are the v1.5.7 tag\'s own. (12) v1.5.7.4 THROUGH v1.5.7.13 (ten Linux cuts; the first aws/azure template since v1.5.7.3 is this one, so a VM from the previous template ran v1.5.7.3): the notes are served at releases.argondb.ai/linux//RELEASE-NOTES.md (v1.5.7.4 to v1.5.7.10 also in docs/releases/), and the channel notes docs/releases/aws-v1.5.7.13.md and azure-v1.5.7.13.md list what reaches this VM. None of it opens a port here, none changes the first boot of a one-database VM, no catalog or lake migration runs, and every new configuration key ships default-off (v1.5.7.4 section 7: [storage] remote WAL backup, [storage] sole_owner, [lake] scheme = azure). The one install-time difference: the artifact\'s install.sh now PRINTS one optional root step at its end, \'argondb box install-useradd-helper --user argondb\' (v1.5.7.4 section 4.9), needed only by a box that runs multi-tenant sidecars; this template does not take it, and a one-database VM does not need it. The ArgonDBCloud crates in the source tree are not in the artifact (v1.5.7.13 section 5). THE CATALOG LOGIN (unchanged since v1.5.4): the box turns its Iceberg catalog login ON by default once it holds more than one database, and the policy engine it needs (bin/openfga, OpenFGA v1.14.2, unchanged from v1.5.4) is IN the tarball this template installs. The VM this template creates holds ONE database, so its catalog boots open, by design; the first boot after you create a second database walls it, with nothing to install and no new port opened here (docs/releases/v1.5.4.md, v1.5.3 section 13, and sections 5 and 6 of v1.5.4; carried forward through v1.5.7.13); none of that is reachable on the one-database VM this template creates. THE TAIL\'S MEMORY BOUND (v1.5.4, section 11; unchanged since v1.5.5, whose section 4 retires only the gate\'s positive control, not the bound): the box places argondb-tail in a 6 GiB kernel cgroup cap where it can write the cgroup tree, and prints UNCAPPED with a WARNING where it cannot. The kernel cap has NOT been measured under load; at the cap the kernel kills the tail and the supervisor respawns it from its resume point. v1.5.3\'s \'plan at least 24 GiB of headroom for the tail\' limit stays WITHDRAWN.' ########## POSITIVE CONTROL: bicep MUST fail on a broken ARM copy ########## broken arm decompile rc=1 (MUST be non-zero) noSuchVariable refusal names noSuchVariable: grep rc=0 (MUST be 0) ARM-OK ########## JSON well-formedness + contentVersion ########## contentVersion 1.5.7.13 ARM-JSON-OK VALIDATE END 2026-10-16T11:58:37Z ``` **The payload drift gate** (`./sync-user-data.sh --check`): ``` PASS aws: user-data is byte-identical to the canonical render PASS aws: embedded payload decodes to argondb-bootstrap.sh byte for byte PASS aws: rendered user-data 14184 bytes < 16384 (87% of the platform limit, worst-case CIDR) PASS azure: user-data is byte-identical to the canonical render PASS azure: embedded payload decodes to argondb-bootstrap.sh byte for byte PASS azure: rendered user-data 14184 bytes < 65536 (22% of the platform limit, worst-case CIDR) check rc=0 (MUST be 0) ########## POSITIVE CONTROL: aws check MUST fail on a tampered copy ########## FAIL aws: user-data DIFFERS from the canonical render (14188 vs 14188 bytes) — run sync-user-data.sh --write FAIL aws: embedded payload is NOT argondb-bootstrap.sh PASS aws: rendered user-data 14184 bytes < 16384 (87% of the platform limit, worst-case CIDR) PASS azure: user-data is byte-identical to the canonical render PASS azure: embedded payload decodes to argondb-bootstrap.sh byte for byte PASS azure: rendered user-data 14184 bytes < 65536 (22% of the platform limit, worst-case CIDR) tampered aws rc=1 (MUST be non-zero) ########## POSITIVE CONTROL: azure check MUST fail on a tampered copy ########## PASS aws: user-data is byte-identical to the canonical render PASS aws: embedded payload decodes to argondb-bootstrap.sh byte for byte PASS aws: rendered user-data 14184 bytes < 16384 (87% of the platform limit, worst-case CIDR) FAIL azure: user-data DIFFERS from the canonical render (14177 vs 14177 bytes) — run sync-user-data.sh --write FAIL azure: embedded payload is NOT argondb-bootstrap.sh PASS azure: rendered user-data 14184 bytes < 65536 (22% of the platform limit, worst-case CIDR) tampered azure rc=1 (MUST be non-zero) SYNC-USER-DATA-OK ``` **The rehearsal** — `testing/cloud/oneclick-vm-rehearsal.sh aws --sha-control` against the REAL published v1.5.7.13 tarball in `ubuntu:26.04.1`, 2026-10-16, under the same slot (INFO lines dropped): ``` ########## EXTRACT the payload from aws's rendered template ########## VERSION="1.5.7.13" TARBALL="argondb-1.5.7.13-linux-x86_64.tar.zst" SHA256="1e5321b0ddb913c3d68f3a0fa573e8101ea70d42a2300b9ec21ad4d0ba8c0b62" ########## BOOT a clean ubuntu:26.04 container ########## PRETTY_NAME="Ubuntu 26.04.1 LTS" ########## RUN the payload (ARGONDB_BOOTSTRAP_SKIP_SYSTEMD=1; a container has no systemd) ########## bytes: 490163149 sha256 VERIFIED SHA256SUMS: 93 files verified assert-relocatable: controls ok (+bin/psql RUNPATH='$ORIGIN/../lib' / -include/pg_config.h not-ELF) assert-relocatable: /opt/argondb/pg_install/v17 — dynamic-ELF=77 $ORIGIN-relative=77 absolute=0 no-runpath=0 other=0 assert-relocatable: PASS — 77 of 77 dynamic ELF are $ORIGIN-relative, 0 absolute argondb v1.5.7.13 (924d75736151) INSTALL-OK ARGONDB-BOOTSTRAP-OK bootstrap rc=0 (MUST be 0) after 48s ########## INDEPENDENT SQL ROUND TRIP (not the payload's own probe) ########## psql round trip rc=0 (MUST be 0) ########## EVERY LISTENER ON THE BOOTED BOX (the security posture, measured) ########## listeners: 23 total, 0 NOT on loopback (MUST be 0, and total MUST be > 0) ########## THE SYSTEMD UNIT, STRUCTURALLY (systemd never supervised this box) ########## systemd-analyze verify rc=0 (MUST be 0) ########## V1.5.0 FIRST BOOT — the release's three not-automatic upgrade steps, on a FRESH box ########## V150-FIRST-BOOT-OK ########## V1.5.3 FIRST BOOT — what the release changes on a ONE-database box, measured ########## V153-FIRST-BOOT-OK ########## V1.5.4 FIRST BOOT — what THIS release changes on a ONE-database box, measured ########## V154-FIRST-BOOT-OK ########## box.env — mode and listen address, never its contents ########## ########## STOP the box ########## ########## NEGATIVE CONTROL: the payload MUST refuse a tarball whose sha256 does not match ########## expected sum rewritten 1e5321b0ddb9... -> be5321b0ddb9... bytes: 490163149 argondb-bootstrap: FATAL: sha256 MISMATCH — refusing to install bad-sha bootstrap rc=1 (MUST be non-zero) refusal names 'sha256 MISMATCH': grep rc=0 (MUST be 0) ONECLICK-VM-REHEARSAL-OK (aws, ubuntu:26.04) AWS-REHEARSAL-RC=0 ``` **The box probe, on the served payload** — the exact payload the aws template serves (the azure payload is byte-identical, section 2), extracted from the rendered template, `ubuntu:26.04.1`, bootstrap with `ARGONDB_BOOTSTRAP_SKIP_SYSTEMD=1`, started with `docker run --init`, the v1.5.7.3 page's default-box sequence: two tenants created, a lake-landed continuous view, a publication with a grantee, the subscription, one `publication land`, the publisher deleted with the publication in force, the next `tenant create`, the tenant-wall pass, the roster, then SIGTERM to `argondb serve` and a boot with zero quarantines and one more `tenant create`. Every line is the probe's own output (INFO log lines and blank lines dropped): ``` PIN-BOX-UP START 2026-10-16T11:57:45Z mode=off template=/home/steveis/argon-lanes/oneclick-v15713-b/src/deploy/cloud-oneclick/aws/argondb-vm.cfn.yaml VERSION="1.5.7.13" TARBALL="argondb-1.5.7.13-linux-x86_64.tar.zst" SHA256="1e5321b0ddb913c3d68f3a0fa573e8101ea70d42a2300b9ec21ad4d0ba8c0b62" PRETTY_NAME="Ubuntu 26.04.1 LTS" argondb v1.5.7.13 (924d75736151) INSTALL-OK ARGONDB-BOOTSTRAP-OK bootstrap rc=0 (MUST be 0) after 68s Python 3.14.4 PIN-BOX-UP-OK (off) argondb-pin-probe-off-v15713 argondb v1.5.7.13 (924d75736151) === DEFAULT BOX (per_tenant off): no /var/lib/argondb/argon.toml — the installed default === tenant wall: ON — one warehouse, bucket and scoped store credential per non-primary database (keys in /var/lib/argondb/lake-store-credentials.json; `argondb lake tenant list`); connection limit 20 === STEP 1: tenant create pubco (the publisher) and subco (the grantee) === tenant create pubco rc=0 [argondb] tenant create: MCP token for pubco (reads pubco only, as pubco_mcp) written to /var/lib/argondb/tenants/pubco/mcp-token [argondb] tenant create: connect — no pooler on this box ([pooler] enabled = "off", or no pgbouncer binary): postgresql://@localhost:/pubco tenant create subco rc=0 [argondb] tenant create: MCP token for subco (reads subco only, as subco_mcp) written to /var/lib/argondb/tenants/subco/mcp-token [argondb] tenant create: connect — no pooler on this box ([pooler] enabled = "off", or no pgbouncer binary): postgresql://@localhost:/subco pubco answers at postgresql://cloud_admin@localhost:5432/pubco: 1 subco answers at postgresql://cloud_admin@localhost:5432/subco: 1 === STEP 2: pubco's source table, and a continuous (lake-landed) view pubco_v_change_log over it === pubco.public.sales is lake name pubco__public__sales lake-writer namespace: dv_main ok the pin serves all_tenants.public__sales view create rc=0 lake config: catalog + object store: /var/lib/argondb/argon.toml + this box's own port configuration (no lake env var set in this process — this is a `docker exec`-safe resolution, not the compose stack's bundled default) lake warehouses: PER-DATABASE — primary "postgres" keeps the box warehouse "argon" (bucket "argon"); every other database publishes to its own, 0 override(s) — from /var/lib/argondb/argon.toml validated: the DataFusion half only — a Postgres `EXPLAIN` of this text on the analyst compute is the other half (§2.3), and this command has no backend to run it on. view: pubco_v_change_log class: C1 (maintained from the delta, landing verb `upsert`) key: inherited:pubco__public__sales[id] ok pubco_v_change_log refreshed pubco_v_change_log [lake] refreshed class: C1 key: id behind: current to 0/2ACF100 (head 0/2ACF100): current === STEP 3: publication create (body reads the view; grantee subco), and subco's subscription === publication create rc=0 publication create: pubco publishes "prba_pubco" (contract_version 1) to grantee(s) ["subco"] ok the pin serves the consent tables ok roster carries the grant --- reader.views BEFORE the delete --- pubco/pubco_v_change_log (publication prba_pubco) [argondb-box] tenant wall: cross-tenant reader may now LIST lake-owned view dv_main.pubco_v_change_log (owner "pubco", publication "prba_pubco"; objects under s3://argon/lake/01a14495-5616-7592-ba15-660f142d7041/, reads only) ok the landing's reader serves pubco_v_change_log: 7 row(s) === STEP 4: one publication land === publication land rc=0 == contract_version 1 — prba_pubco from pubco: 1 landing(s) of 3 row(s) == DATABASE TABLE MODE PUBLISH OUTCOME subco derived.prba_pubco create yes landed derived.prba_pubco landing=pg mode=create rows=7 pin=0/2B1BE90 token=publication/pubco/prba_pubco:0/2B1BE90:subco:prba_pubco snapshot=none key=[id] key-from=declared [publicatio 2 other database(s) in the cluster: not grantees of prba_pubco, not listed (names with --all) publication land: 1 landing(s) of 3 (database, publication) row(s) at pin 0/2B1BE90, data pinned at pubco_v_change_log W 0/2B1BE90 (run start 0/2B1BE90), consent pinned at 0/2B1BE90 subco derived.prba_pubco rows=7 sum=280 === STEP 5: argondb tenant delete pubco — the publisher, with the publication in force === tenant delete rc=0 [argondb] tenant delete: step 1/4 — the estate rows: none (already removed, or never written) [argondb] tenant delete: step 2/4 — database pubco DROPPED on the box primary [argondb] tenant delete: pubco: 1 granted view(s) of this publisher removed from the reader roster: dv_main.pubco_v_change_log (publication "prba_pubco") [argondb] tenant delete: step 3/4 — timeline cd11a83619a30fc8df0ac2041f55bdae DELETED on the pageserver [argondb] tenant delete: step 3/4 — timeline cd11a83619a30fc8df0ac2041f55bdae: not on the safekeeper (no compute ever wrote to it) [argondb] tenant delete: step 4/4 — /var/lib/argondb/tenants/pubco REMOVED [argondb] tenant delete: pubco is DELETED. Its lake data, if any, is kept: `argondb lake list --dead` shows it, and `argondb lake drop-orphan --database pubco --yes` removes it (run it without --yes first to see what it drops). ok the delete named the view grant it removed === STEP 6: the next tenant create, the wall pass, the roster === tenant create after1 rc=0 [argondb] tenant create: MCP token for after1 (reads after1 only, as after1_mcp) written to /var/lib/argondb/tenants/after1/mcp-token [argondb] tenant create: connect — no pooler on this box ([pooler] enabled = "off", or no pgbouncer binary): postgresql://@localhost:/after1 ok the next tenant create (after1) SUCCEEDED, no panic wall pass (lake tenant provision) rc=0 [argondb-box] tenant wall: 2 principal(s) — 0 provisioned this pass, 2 already walled, 0 in the box warehouse, 0 refused; connection limits: 2 database(s) — 0 set this pass, 0 overridden, 2 kept, 0 failed; cross-tenant reader: roster re ok the tenant-wall pass is green --- reader.views AFTER the delete --- (end of roster: 0 entr(ies)) reader.views entries whose owner is pubco: 0 (of 0) ok lake-store-credentials.json reader.views carries no entry owned by pubco publication land of the deleted publisher's publication rc=1 (a refusal is expected; a panic is not) Error: taking the pin ok no panic in publication land, the box log or any tail log === STEP 7: SIGTERM the box, boot it: zero quarantines, the next tenant create still succeeds === argondb serve exited after 12s argondb-user processes left after 0s more: 0 boot: UP after 9s (/var/log/argondb-box-restart.log) QUARANTIN lines in the restarted box log: 0; across every tail log: 0 ok the box came up with zero quarantines argondb-box is up: serving — argondb-tail bound Flight on 127.0.0.1:8817 (0s after the box began waiting for it) tenant create after2 rc=0 [argondb] tenant create: MCP token for after2 (reads after2 only, as after2_mcp) written to /var/lib/argondb/tenants/after2/mcp-token [argondb] tenant create: connect — no pooler on this box ([pooler] enabled = "off", or no pgbouncer binary): postgresql://@localhost:/after2 ok after the restart the next tenant create (after2) SUCCEEDED PIN-PANIC-PROBE-RESULT (off): PASS failures=0 PIN-PROBE-DONE (off) rc=0 2026-10-16T12:01:48Z ``` ## 4. What this does NOT prove Everything `docs/releases/aws-v1.5.7.3.md` "What this does NOT prove" says still holds: no credentialed deploy of this template has ever run; the systemd leg is checked structurally only; cloud-init's own `write_files` / `runcmd` handling is not exercised; the restart in section 3 is a SIGTERM to `argondb serve` (the signal `systemctl stop argondb-box` sends) and not a cloud stop path (an EC2 stop or the `IdleStopMinutes` alarm). In addition: the per-tenant box (`[compute] per_tenant = true`) was measured on the v1.5.7.3 page and was NOT re-measured on this cut; none of the ten cuts' fixes in section 1 was exercised on this VM shape beyond what the probe's sequence reaches (tenant create, a continuous view, a publication landing, the publisher's delete, a restart) — the cuts' own gates on the Linux build node are what hold them; an in-place upgrade of a VM from the v1.5.7.3 template to v1.5.7.13 (section 6) was not run on this VM shape. ## 5. Known limits - Every limit in `docs/releases/aws-v1.5.7.3.md`, `aws-v1.5.7.2.md`, `aws-v1.5.7.1.md` and `aws-v1.5.7.md` "Known limits" applies, and every product limit in the v1.5.7.4 through v1.5.7.13 notes' limits sections — first among them (v1.5.7.13 Linux notes, section 7): **the earned-view stall is NOT fixed and its cause is NOT established**; a view stalled in `recompute` is still ended only by the 1800 s pass deadline, with every other view of the pass waiting behind it. - The three cloud-facing keys of v1.5.7.4 (section 7) are unmeasured on this VM: this template sets none of them, and the Azure lake and the `azure://` remote are proven against an emulator, not an Azure account (that notes' Candor). - The one-database VM this template creates still does not need the useradd helper; a box you later turn multi-tenant with sidecars needs `sudo /opt/argondb/bin/argondb box install-useradd-helper --user argondb` once (v1.5.7.4, section 4.9) — not taken by this template, and not exercised on a real `sudoers` by any gate. - Ubuntu 26.04 is required, not preferred: the artifact's glibc floor is 2.43 and `install.sh` refuses 24.04 (2.39) and 22.04 (2.35) by name. - The frozen v1.5.7.6 through v1.5.7.13 Linux notes and the macOS v1.5.7.13 notes describe the aws and azure channels as retired at v1.5.7.3; they are not edited by this publish, and this page is the correction of record. - A VM from the v1.5.7.3, v1.5.7.2, v1.5.7.1 or v1.5.7 template is NOT upgraded by this publish: replacing its binaries is a step on that VM (section 6). ## 6. Upgrading a VM that stays on the v1.5.7.3 template, by hand The v1.5.7.3 page's upgrade procedure, with ten notes' restart sections behind it, none of which asks for a data-directory change or a hand edit on this VM. On the VM: stop the box (`argondb stop --data-dir /var/lib/argondb`, or `systemctl stop argondb-box`) and wait for `argondb serve` to exit; download `https://releases.argondb.ai/linux/v1.5.7.13/argondb-1.5.7.13-linux-x86_64.tar.zst`, check its sha256 is `1e5321b0ddb913c3d68f3a0fa573e8101ea70d42a2300b9ec21ad4d0ba8c0b62`, unpack it and run its `install.sh --prefix /opt/argondb` (the same prefix the template installed into; `/etc/argondb/box.env` and `/var/lib/argondb` stay as they are); start the box on the same data directory (`systemctl start argondb-box`). What is different at the first start, taken from the notes' restart sections in order — v1.5.7.4 section 11, v1.5.7.5 section 8, v1.5.7.6 section 14, v1.5.7.7 section 11, v1.5.7.8 section 14, v1.5.7.9 section 7, v1.5.7.10 section 10, v1.5.7.11 section 8, v1.5.7.12 section 5, v1.5.7.13 section 6: a box launched with its output redirected into `/var/lib/argondb/logs/` starts a second process, `argondb box-log-writer` (do not kill it); a dirty reader roster left by an earlier `tenant delete` heals on the first tenant-wall pass; the catalog authorizer's check cache comes on; `derived.transform_runs` gains a column; the maintenance and tail logs gain the `ring-read:` and step-mark lines. Leave every knob as it is (`ARGONDB_VIEWS_MEMORY_MB`, `ARGONDB_VIEWS_RING_STEP_SECS` unset). A box still on v1.5.7 follows the v1.5.7.1 notes, section 3, first, and is not restarted on v1.5.7. This procedure was not run on the VM shape (section 4). ## Build facts Measured from the artifact by the release-verification pipeline at the Linux cut, none declared: `https://releases.argondb.ai/linux/v1.5.7.13/RELEASE-NOTES.md`, "Build facts" — 490,163,149 bytes, sha256 `1e5321b0ddb913c3d68f3a0fa573e8101ea70d42a2300b9ec21ad4d0ba8c0b62`, source `924d7573615186fe0851bddf3e34b13346c8c78f` (tag `v1.5.7.13`), glibc floor 2.43, rustc 1.94.0, PostgreSQL 17.5, Lakekeeper 0.13.1, OpenFGA v1.14.2, PgBouncer not bundled, built 2026-10-14 01:23:48 UTC on `ms-01`. The template adds no build of its own.