anbaric 1.68.1 → 1.68.3

package/docs/README.md

@@ -44,7 +44,7 @@ How to put the features together to build something real.
 - [Integrating external systems](patterns/integrating-external-systems.md) — waiting on callbacks and webhooks
 - [Authorization with actors and roles](patterns/authorization.md) — who is allowed to do what
 - [UX practices](patterns/ux-practices.md) — feedback and polling for an asynchronous UI
-- [Staying within memory](patterns/memory.md) — the 512 MB footprint, and not turning the process into a cache
+- [Staying within memory](patterns/memory.md) — the 1 GB footprint, and not turning the process into a cache
 - [Testing your app](patterns/testing.md) — driving a machine in memory
 
 ## API reference

package/docs/features/deploying.md

@@ -49,14 +49,14 @@ anbaric jobs watch <job-id>     # follow a job as it progresses
   so your code is identical locally and in the cloud. **Never set these
   yourself.** See [Environment and factories](../api/environment.md).
 - **A fixed footprint.** Each app runs in its own container with **0.25 vCPU
-  and 512 MB of memory**, shared between your process and the small launcher
+  and 1 GB of memory**, shared between your process and the small launcher
   beside it. Node sizes its heap from that limit, so your code gets a heap of
-  roughly **270 MB** before it is out of memory. That is plenty for a workflow
+  roughly **510 MB** before it is out of memory. That is plenty for a workflow
   app whose steps call services and move a job on; it is not enough to hold
   thousands of jobs, a whole dataset or a large file in memory at once. See
   [Staying within memory](../patterns/memory.md) for what to do instead and
   how an out-of-memory crash shows up. Every app starts small; one that needs
-  more can be switched to a **large** instance (faster compute, 4× the memory,
+  more can be switched to a **large** instance (faster compute, 2× the memory,
   $50/£50 a month instead of $20/£20, and not covered by the free allowance)
   on the console's Manage apps page. Deploying never asks about size.
 

package/docs/patterns/memory.md

@@ -1,7 +1,7 @@
 # Staying within memory
 
-A deployed app gets **512 MB** of memory and a quarter of a vCPU, and Node gives
-your code a heap of roughly **270 MB** of that. This is a deliberate shape: an
+A deployed app gets **1 GB** of memory and a quarter of a vCPU, and Node gives
+your code a heap of roughly **510 MB** of that. This is a deliberate shape: an
 Anbaric app is a set of small steps that each read a job, do one thing and
 record the result. The job's data lives in the platform, not in your process,
 so a well-shaped app rarely needs more than a few tens of megabytes however
@@ -20,7 +20,7 @@ Two different limits, two different symptoms:
   collector that stopped working: the collector only frees what nothing refers
   to any more.
 - **The container limit.** Buffers and native memory live outside the heap. If
-  they take the container past 512 MB the container is killed outright, with no
+  they take the container past 1 GB the container is killed outright, with no
   stack trace: `anbaric app status <name>` shows the task stopped with
   `OutOfMemoryError: Container killed due to memory usage`.
 
@@ -92,18 +92,18 @@ Your app serves HTTP as well as running steps, and the two share the heap.
 
 ## When you need to know
 
-`process.memoryUsage()` is the honest answer: `heapUsed` against the ~270 MB
-heap, `rss` against 512 MB. Logging it at the start and end of a suspect step
+`process.memoryUsage()` is the honest answer: `heapUsed` against the ~510 MB
+heap, `rss` against 1 GB. Logging it at the start and end of a suspect step
 tells you in one run whether the step is the problem. If `heapUsed` climbs
 across steps and never comes back down, something is holding on; if a single
 step spikes, that step needs breaking up.
 
 If a workload genuinely needs more — a large model run, a heavy transform — an
 app can be moved to a **large** instance from the console's Manage apps page:
-faster compute and four times the memory (2 GB, so a heap of roughly 1 GB),
+faster compute and twice the memory (2 GB, so a heap of roughly 1 GB),
 for $50/£50 a month instead of $20/£20, paid from its first day (the free
 allowance covers small apps only). It is the right answer for one heavy app;
-it is not the answer to a leak, which will fill 2 GB as surely as 512 MB.
+it is not the answer to a leak, which will fill 2 GB as surely as 1 GB.
 
 ## See also
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "anbaric",
-  "version": "1.68.1",
+  "version": "1.68.3",
   "description": "Everything needed to write an Anbaric app: state machines, jobs, document and secret stores, local in-memory implementations and the Anbaric Cloud clients",
   "license": "MIT",
   "type": "module",
@@ -24,9 +24,9 @@
     "prepublishOnly": "npm run build"
   },
   "dependencies": {
-    "anbaric-impl-cloud": "^1.68.1",
-    "anbaric-data-store": "^1.68.1",
-    "anbaric-state-machine": "^1.68.1",
-    "anbaric-tsapi": "^1.68.1"
+    "anbaric-impl-cloud": "^1.68.3",
+    "anbaric-data-store": "^1.68.3",
+    "anbaric-state-machine": "^1.68.3",
+    "anbaric-tsapi": "^1.68.3"
   }
 }