@voltro/cli 0.2.1 → 0.3.0

package/dist/serveEntry.d.ts

@@ -0,0 +1,22 @@
+declare type AppModule = Record<string, unknown>;
+
+/** A lazy loader — used by the serve bundle so an app module is EVALUATED on
+ *  first `importAppModule` (i.e. during `runServe`, AFTER `registerCoreTables`),
+ *  not eagerly at bundle-import time (which would run before the core-table
+ *  registration and blow up store construction). esbuild code-splitting keeps the
+ *  loaded chunk on the SAME framework/effect instance as the bundle. */
+declare type LazyAppModule = () => Promise<AppModule>;
+
+export declare const loadDotEnv: (argv: ReadonlyArray<string>) => void;
+
+/** Register prebuilt app modules keyed by ABSOLUTE source path. Values may be the
+ *  module namespace directly (the eager `apiEntry.js` bundle) OR a lazy
+ *  `() => import(...)` loader (the serve bundle). Called once by `voltro serve`. */
+export declare const registerAppModules: (mods: Readonly<Record<string, AppModule | LazyAppModule>>) => void;
+
+/** Register a driver module pre-bundled by `voltro build` (keyed by package spec). */
+export declare const registerDriver: (spec: string, mod: Record<string, unknown>) => void;
+
+export declare const runServe: (args: ReadonlyArray<string>) => Promise<number>;
+
+export { }

package/dist/serveEntry.js

@@ -0,0 +1,4 @@
+import { At as e, nt as t } from "./dev-x_VqbV_8.js";
+import { a as n } from "./startupRunner-DhlX9nqd.js";
+import { t as r } from "./serveCommand-Dttqe5Ms.js";
+export { e as loadDotEnv, n as registerAppModules, t as registerDriver, r as runServe };

package/dist/startup.js

@@ -1,2 +1,2 @@
-import { n as e, t } from "./startupRunner-DAexyPkM.js";
+import { n as e, t } from "./startupRunner-DhlX9nqd.js";
 export { t as loadStartupFiles, e as runStartups };

package/dist/{startupRunner-DAexyPkM.js → startupRunner-DhlX9nqd.js}

@@ -2,31 +2,43 @@ import { basename as e } from "node:path";
 import { pathToFileURL as t } from "node:url";
 import { publishServerError as n } from "@voltro/protocol";
 //#region src/appModuleLoader.ts
-var r = /* @__PURE__ */ new Map(), i = (e) => {
+var r = /* @__PURE__ */ new Map(), i = /* @__PURE__ */ new Map(), a = (e) => {
 	for (let [t, n] of Object.entries(e)) r.set(t, n);
-}, a = async (e) => r.get(e) || await import(t(e).href), o = (e) => e.replace(/\.startup\.tsx?$/, ""), s = async (t, n) => {
+}, o = () => r.size > 0, s = async (e) => {
+	let n = i.get(e);
+	if (n) return n;
+	let a = r.get(e);
+	if (a !== void 0) {
+		if (typeof a == "function") {
+			let t = await a();
+			return i.set(e, t), t;
+		}
+		return a;
+	}
+	return await import(t(e).href);
+}, c = (e) => e.replace(/\.startup\.tsx?$/, ""), l = async (t, n) => {
 	let r = [];
 	for (let i of t) {
 		let t;
 		try {
-			t = await a(i);
+			t = await s(i);
 		} catch (e) {
 			n.warn("startup: failed to import", { file: i }, e);
 			continue;
 		}
-		let s = t.default;
-		if (typeof s != "function") {
+		let a = t.default;
+		if (typeof a != "function") {
 			n.warn("startup: no default-export function", { file: i });
 			continue;
 		}
 		r.push({
 			file: i,
-			id: o(e(i)),
-			fn: s
+			id: c(e(i)),
+			fn: a
 		});
 	}
 	return r;
-}, c = async (e, t, r) => {
+}, u = async (e, t, r) => {
 	let i = [];
 	for (let a of e) {
 		let e = r.child(`startup:${a.id}`), o = {
@@ -70,4 +82,4 @@ var r = /* @__PURE__ */ new Map(), i = (e) => {
 	} };
 };
 //#endregion
-export { i, c as n, a as r, s as t };
+export { a, s as i, u as n, o as r, l as t };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@voltro/cli",
-  "version": "0.2.1",
+  "version": "0.3.0",
   "description": "The `voltro` CLI — dev server, codegen, migrations, project scaffolding, agent-docs seeding, and production serve.",
   "keywords": [
     "voltro",
@@ -35,6 +35,11 @@
       "types": "./dist/startup.d.ts",
       "import": "./dist/startup.js",
       "default": "./dist/startup.js"
+    },
+    "./serveEntry": {
+      "types": "./dist/serveEntry.d.ts",
+      "import": "./dist/serveEntry.js",
+      "default": "./dist/serveEntry.js"
     }
   },
   "main": "./dist/index.js",
@@ -47,27 +52,30 @@
     "@effect/platform-node": "^0.107.0",
     "@effect/sql": "^0.51.1",
     "@effect/workflow": "^0.18.2",
+    "@voltro/ai": "0.3.0",
+    "@voltro/cache": "0.3.0",
+    "@voltro/data-transfer": "0.3.0",
+    "@voltro/database": "0.3.0",
+    "@voltro/env": "0.3.0",
+    "@voltro/kv": "0.3.0",
+    "@voltro/logger": "0.3.0",
+    "@voltro/plugin-auth": "0.3.0",
+    "@voltro/plugin-broadcast": "0.3.0",
+    "@voltro/plugin-mail": "0.3.0",
+    "@voltro/plugin-storage": "0.3.0",
+    "@voltro/plugin-webhooks": "0.3.0",
+    "@voltro/protocol": "0.3.0",
+    "@voltro/runtime": "0.3.0",
+    "@voltro/serverless": "0.3.0",
+    "@voltro/workflow": "0.3.0",
+    "chokidar": "^5.0.0",
+    "ioredis": "^5.11.1",
+    "ts-morph": "^28.0.0"
+  },
+  "optionalDependencies": {
     "@tailwindcss/vite": "^4.3.2",
     "@vitejs/plugin-react": "^6.0.3",
-    "@voltro/ai": "0.2.1",
-    "@voltro/cache": "0.2.1",
-    "@voltro/data-transfer": "0.2.1",
-    "@voltro/database": "0.2.1",
-    "@voltro/env": "0.2.1",
-    "@voltro/kv": "0.2.1",
-    "@voltro/logger": "0.2.1",
-    "@voltro/plugin-auth": "0.2.1",
-    "@voltro/plugin-broadcast": "0.2.1",
-    "@voltro/plugin-mail": "0.2.1",
-    "@voltro/plugin-storage": "0.2.1",
-    "@voltro/plugin-webhooks": "0.2.1",
-    "@voltro/protocol": "0.2.1",
-    "@voltro/runtime": "0.2.1",
-    "@voltro/serverless": "0.2.1",
-    "@voltro/workflow": "0.2.1",
-    "chokidar": "^5.0.0",
     "esbuild": "^0.28.0",
-    "ioredis": "^5.11.1",
     "tsx": "^4.23.0",
     "vite": "^8.1.4"
   },

package/templates/AGENTS.core.md

@@ -220,8 +220,22 @@ primitive → just save; the supervised dev loop respawns and regenerates.
   But DO call `assertOwnTenant(input.tenantId, ctx.request.subject)` (from
   `@voltro/plugin-multitenancy/guard`) in custom mutations that write raw rows,
   and declare `error: TenantMismatch` — subscriptions are auto-scoped, writes are not.
+- **Gate authorization declaratively with `guards:`.** Add
+  `guards: [{ scope: 'notes:write' }]` to `defineMutation`/`defineQuery`/`defineAction`
+  — the framework enforces it BEFORE the executor (before the txn opens), fails
+  with a typed `ScopeError` (auto-merged into the wire error union), and checks the
+  caller's EFFECTIVE scopes (raw ∪ rbac roles). Guards are browser-safe DATA (scope
+  strings + a pure `resource: (input) => id` extractor — never a server fn). Use the
+  in-handler `ctx.access.has(scope)` / `yield* ctx.access.require(scope)` (or rbac's
+  `permission()`) only for checks that need LOADED data (row ownership).
 - **Don't store secrets in the schema or in `Subject`.** Declare env via
   `defineEnv` (`configuration.md`); carry only ids in `Subject`.
+- **In production, `voltro build` BEFORE `voltro serve`.** A production
+  (`NODE_ENV=production`) serve REQUIRES the precompiled serve bundle and fails
+  loud if it's missing — production never transpiles on demand. The generated
+  Dockerfiles already do `voltro build` then `voltro serve`; if you write your
+  own prod start, build first. (`voltro dev` + a non-prod local `serve` still use
+  tsx.) Depth: the deployment topic.
 - **Don't copy prod data down unmasked.** `voltro data export` (and
   `--target api`) reads REAL rows — PII included. Copying prod → dev/stage MUST
   go through a masking profile (`--profile`; classify columns `.sensitive()` /

package/templates/AGENTS.md

@@ -220,8 +220,22 @@ primitive → just save; the supervised dev loop respawns and regenerates.
   But DO call `assertOwnTenant(input.tenantId, ctx.request.subject)` (from
   `@voltro/plugin-multitenancy/guard`) in custom mutations that write raw rows,
   and declare `error: TenantMismatch` — subscriptions are auto-scoped, writes are not.
+- **Gate authorization declaratively with `guards:`.** Add
+  `guards: [{ scope: 'notes:write' }]` to `defineMutation`/`defineQuery`/`defineAction`
+  — the framework enforces it BEFORE the executor (before the txn opens), fails
+  with a typed `ScopeError` (auto-merged into the wire error union), and checks the
+  caller's EFFECTIVE scopes (raw ∪ rbac roles). Guards are browser-safe DATA (scope
+  strings + a pure `resource: (input) => id` extractor — never a server fn). Use the
+  in-handler `ctx.access.has(scope)` / `yield* ctx.access.require(scope)` (or rbac's
+  `permission()`) only for checks that need LOADED data (row ownership).
 - **Don't store secrets in the schema or in `Subject`.** Declare env via
   `defineEnv` (`configuration.md`); carry only ids in `Subject`.
+- **In production, `voltro build` BEFORE `voltro serve`.** A production
+  (`NODE_ENV=production`) serve REQUIRES the precompiled serve bundle and fails
+  loud if it's missing — production never transpiles on demand. The generated
+  Dockerfiles already do `voltro build` then `voltro serve`; if you write your
+  own prod start, build first. (`voltro dev` + a non-prod local `serve` still use
+  tsx.) Depth: the deployment topic.
 - **Don't copy prod data down unmasked.** `voltro data export` (and
   `--target api`) reads REAL rows — PII included. Copying prod → dev/stage MUST
   go through a masking profile (`--profile`; classify columns `.sensitive()` /

package/templates/agent-docs/_manifest.json

@@ -35,7 +35,7 @@
       "group": null,
       "description": "The voltro CLI — every command, grouped by purpose, with the flags that actually matter.",
       "path": "agent-docs/cli.md",
-      "files": 8
+      "files": 9
     },
     {
       "id": "configuration",

package/templates/agent-docs/cli.md

@@ -25,6 +25,7 @@ The dispatcher routes `voltro <command> [args]` to the matching subcommand and p
 | [Build & run](/docs/cli/build-and-start) | `build`, `start`, `serve` |
 | Deploy | `deploy` (`plan` — auto-detect the target tier per app + function), [`serverless`](/docs/deployment/serverless-functions) (`list` / `dev` / `serve` / `build` / `deploy`), [`static`](/docs/deployment/static-sites) (`hosts` / `deploy`) |
 | [Database](/docs/cli/migrate) | `migrate`, `db` (`plan` / `apply` / `plans` / `drift` / `squash` / `restore-snapshot` / `migrate` / `rollback` / `status` / `seed`) |
+| [Update](/docs/cli/update) | `update` (`--to` / `--dry-run` / `--force` / `--exact`) — bump every `@voltro/*`, install, run the codemods that adapt your source to the new version |
 | [Data transfer](/docs/cli/data) | `data` (`export` / `import` / `unpack` / `inspect` / `backup` / `restore`) — directory + single-file `.vbundle` bundles, streaming assets, masking, at-rest encryption |
 | Ops / infra | `cache` (`status` / `flush` / `invalidate`), `add` (`redis`), `baseline` (`list` / `status` / `set`), `schedule-manifest`, [`storage`](/docs/plugins/storage) (`doctor` / `cors`) |
 | AI / data | `embeddings backfill <table> --text <field> --vector <field>` — (re)embed rows the `vectorEmbedding()` mixin missed (pre-existing rows / a model change); `--dry-run` to preview |
@@ -149,6 +150,7 @@ The HTTP surface is reachable directly too — e.g. `curl -s localhost:4000/_vol
 - [Dev](/docs/cli/dev) — what happens during `voltro dev`
 - [Build & start](/docs/cli/build-and-start) — production paths
 - [Migrate](/docs/cli/migrate) — schema changes end-to-end
+- [Update](/docs/cli/update) — upgrade the framework + run codemods
 - [Inspect & test](/docs/cli/inspect) — debugging + harness
 
 
@@ -1648,3 +1650,60 @@ The manifest is read through a TTL-cached source (~10 seconds): a procedure you
 ## Protocol scope
 
 MCP over JSON-RPC 2.0. `initialize` negotiates the protocol revision (`2025-06-18`, `2025-03-26`, `2024-11-05`) and advertises the `tools`, `resources`, and `prompts` capabilities; methods are `ping`, `tools/list`, `tools/call`, `resources/list`, `resources/read`, `prompts/list`, `prompts/get`. The stdio bin frames this as newline-delimited JSON-RPC; the HTTP bin serves it over Streamable HTTP. Both transports route to the same pure protocol core (`handleMcpRequest`, `callTool`, `listResources`/`readResource`, `listPrompts`/`getPrompt`, `routeHttp`), all exported from `@voltro/mcp`.
+
+
+
+---
+
+<!-- source: en/cli/update.md -->
+## Update
+
+_voltro update — bump the framework to the latest version and run the codemods that adapt your source to any changed APIs._
+
+`voltro update` upgrades an app to the latest framework release. It does three things in order:
+
+1. **Bump** every `@voltro/*` dependency in `package.json` to the target version.
+2. **Install** with your package manager (detected from the lockfile — pnpm / npm / yarn / bun).
+3. **Run the codemods** shipped with the target version — automatic source rewrites for any breaking API change, plus printed manual steps for anything that can't be automated.
+
+```bash
+voltro update                 # bump to the latest published version, install, run codemods
+voltro update --to 0.4.0      # pin an explicit target version
+voltro update --dry-run       # preview the bump + which codemods would run — writes nothing
+voltro update --force         # allow a dirty working tree (not recommended)
+voltro update --exact         # pin exact versions (drop the ^ / ~ range prefix)
+```
+
+## The clean-tree guard
+
+Codemods **rewrite your source**, so you need a clean diff to review afterwards. `voltro update` refuses to run on a dirty git working tree — commit or stash first. Use `--dry-run` to preview without touching anything, or `--force` to override the guard (you accept a mixed diff).
+
+## What gets bumped
+
+Every `@voltro/*` entry in `dependencies` and `devDependencies`, with the range style preserved (`^0.3.0` stays caret, `~0.3.0` stays tilde) unless you pass `--exact`. Non-registry specs (`workspace:*`, `catalog:`, `link:`, …) are left untouched — they're already resolved by your monorepo or catalog.
+
+## Codemods
+
+Each breaking public-API change in a release ships a **codemod**. When you update across that release, `voltro update` applies it:
+
+- A **transform codemod** rewrites your source automatically — renamed imports, moved modules, changed component props, restructured call signatures. The rewrite is scoped to files that actually import the affected symbol.
+- A **manual codemod** prints written steps during the update, only when your app is affected — for changes that can't be mechanically transformed (a behavior change, a descriptor/executor restructure). Where the affected sites can be found but the fix needs your judgment, a codemod inserts `// TODO(voltro-migration): …` markers so you can locate every spot.
+
+Codemods that span multiple versions run in order (e.g. upgrading `0.2.0 → 0.4.0` runs the `0.3.0` and `0.4.0` codemods in sequence). Review the resulting diff before committing.
+
+## The database is separate
+
+`voltro update` does **not** touch your database. Framework-owned `_voltro_*` tables (workflow runs, schedules, …) are reconciled by the declarative differ, not by codemods: when a release changes one of those tables, your next `voltro db apply` (or `voltro dev` boot, which auto-applies) picks up the change. After an update:
+
+```bash
+voltro update
+voltro db apply        # reconcile any changed framework tables — NOT voltro db migrate
+# then run your typecheck to confirm your code compiles against the new API
+```
+
+Use `voltro db apply` (the declarative diff), not `voltro db migrate` (the imperative file-runner) — only the former reconciles framework tables.
+
+## Where to read next
+
+- [Migrate](/docs/cli/migrate) — schema changes end-to-end
+- [Build & start](/docs/cli/build-and-start) — production paths

package/templates/agent-docs/data.md

@@ -389,6 +389,17 @@ The descriptor is the wire contract. The `.mutation.server.ts` file is the serve
 5. Commit the transaction.
 6. Drain the batched change events so matching query subscriptions receive new snapshots or deltas.
 
+## Partial updates: `ctx.store.applyDefined`
+
+A partial-update mutation should set only the fields the caller actually sent — not overwrite an omitted field with `undefined`. Instead of hand-writing `if (input.x !== undefined) patch.x = input.x` per field, use `ctx.store.applyDefined(input, keys)`:
+
+```ts
+const execute = async (input: UpdateNote, ctx: AppContext) =>
+  ctx.store.update('notes', input.id, ctx.store.applyDefined(input, ['title', 'body', 'dueAt']))
+```
+
+It returns a patch containing only the listed keys whose value is not `undefined` (a defined falsy value like `0` / `''` / `false` IS kept). Also importable standalone (`import { applyDefined } from '@voltro/runtime'`) for seeds/tests.
+
 ## Calling From React
 
 ```tsx
@@ -465,6 +476,34 @@ const create = useMutation('app', 'notes.create').withOptimistic((cache, input)
 
 Use `.withoutOptimistic()` for effects that should not preview locally.
 
+### Nested / path-targeted optimistic
+
+By default a `target` patches the **flat top-level row array** a query returns, keyed by `id`. When a query returns a **nested array** — a JSON array column (`snapshot.projects`) or a computed/shaped value — add `path` (and, if the item key isn't `id`, `by`) to patch at **item** granularity, with no hand-written `.withOptimistic` reducer:
+
+```ts
+target: {
+  table: 'projectRoadmaps', op: 'update',
+  path: 'snapshot.projects',                 // dot-path to the nested array in the value
+  identify: (input) => input.projectId,      // which item to patch (default input.id)
+}
+```
+
+- `op: 'insert'` appends (or `order: 'prepend'`) a new item into the nested array — safe even on a computed query (a path insert targets a KNOWN document, not a blind top-level add).
+- `op: 'delete'` filters the item out by its key.
+- `by` overrides the item-key field (default `'id'`).
+
+Add `match` to patch **only** the entries whose current value satisfies a predicate — the guard that stops a patch bleeding across sibling subscriptions sharing a source table:
+
+```ts
+target: {
+  table: 'projectRoadmaps', op: 'update', path: 'snapshot.projects',
+  identify: (i) => i.projectId,
+  match: (value, input) => value.id === input.roadmapId,   // only THIS roadmap's subscription
+}
+```
+
+`path`, `by`, and `match` are browser-safe descriptor data (a dot-path string + a pure predicate) — the same discipline as `identify`/`shape`.
+
 ## Typed Errors
 
 ```ts

package/templates/agent-docs/database/advancedqueries.md

@@ -219,6 +219,33 @@ text().unique()                                 // single-column, on the column
 
 Multi-column uniqueness is declared at the table level with `.unique(name, [cols])` — see [Composite UNIQUE constraints](#composite-unique-constraints) below.
 
+## Unique among ACTIVE rows — `.uniqueActive([...])`
+
+Enforce uniqueness only among the rows that aren't soft-deleted — "one active roadmap per (project, year)", where a soft-deleted roadmap frees the key for a new one:
+
+```ts
+table('project_roadmaps', {
+  id: id(), projectId: text(), year: integer(), deletedAt: timestamp(),
+})
+  .softDelete()
+  .uniqueActive(['projectId', 'year'])            // partial UNIQUE among deletedAt IS NULL
+```
+
+Emits a `CREATE UNIQUE INDEX … WHERE "deletedAt" IS NULL`, so a soft-deleted row leaves the active set and a NEW row with the same key inserts cleanly — no hand-written `generatedAs("CASE WHEN …")` column, and no [resurrection bug](/docs/database/migrations/troubleshooting) where a re-imported soft-deleted key collides. The predicate defaults to the `softDelete()` active set; override it for a custom one:
+
+```ts
+.uniqueActive('byActiveSlug', ['orgId', 'slug'], { where: `"status" = 'open'` })
+```
+
+Cross-dialect:
+
+| Dialect             | Support                                                        |
+|---------------------|----------------------------------------------------------------|
+| postgres / sqlite / mssql | native partial `CREATE UNIQUE INDEX … WHERE`             |
+| mysql / mariadb     | FAILS LOUDLY at migrate — no partial-index support; a full unique index would forbid re-creating a soft-deleted key. Use a generated STORED column + `.unique([...])` there. |
+
+The predicate is emitted verbatim (ANSI double-quoted identifiers, valid on the three supported dialects).
+
 ## When NOT to index
 
 - Tables with <10k rows on a fast disk — the cost of maintaining the index outweighs the seq-scan cost.

package/templates/agent-docs/deployment.md

@@ -392,7 +392,7 @@ The phases, in boot order:
 
 | Phase | What it covers |
 | --- | --- |
-| `modules` | node init + loading and compiling the JS module graph (the framework + your app). On a scale-to-zero container this is almost always the dominant phase — it is the cost of evaluating the dependency graph on a cold process, and it scales inversely with your CPU allotment. No app-level change shrinks it — **precompiling the app (`voltro build`) removes only the transpile of your own source files, not the framework graph load.** |
+| `modules` | node init + loading and compiling the JS module graph (the framework + your app). On a scale-to-zero container this is almost always the dominant phase — it is the cost of evaluating the dependency graph on a cold process, and it scales inversely with your CPU allotment. **Precompiling the app (`voltro build`) collapses this phase** — see [Precompiled boot](#precompiled-boot) below. |
 | `config` | loading `app.config.ts` + the typed-env gate |
 | `discover` | walking the app + loading discovered primitives (plus the precompiled bundle, when `voltro build` produced one) |
 | `store` | opening the data store + cache/kv facades — a real SQL dialect includes the connection handshake here |
@@ -402,6 +402,19 @@ The phases, in boot order:
 
 Read this from the container's own logs at its real CPU allotment, not a beefy dev machine: a `modules` phase that dwarfs everything else means the cold start is dominated by evaluating the dependency graph (raise the container's CPU, or keep one instance warm); a fat `store` phase points at the database connection instead. `VOLTRO_BOOT_TIMING` adds a handful of `performance.now()` calls and one log line — it is safe to leave on in production.
 
+## Precompiled boot
+
+`voltro build` precompiles the whole serve path — the framework, Effect, and your app — into a single **serve bundle**, and `voltro serve` boots from it directly. Instead of resolving and compiling the full module graph on every cold process, the boot loads one prebuilt file with your app modules as lazy chunks. This collapses the `modules` phase — `serve: ready` drops from ~1000 ms to ~180 ms; the win is larger on a scale-to-zero container with a cold filesystem, where per-module resolution costs the most. It applies whether your app uses a SQL driver or the memory store: your declared driver (e.g. `@voltro/sql-postgres`) is inlined into the bundle, and only its native binding (`pg`) stays external.
+
+```bash
+voltro build ./apps/api    # produces .framework/dist-api/serveBundle/
+voltro serve ./apps/api    # boots from the bundle automatically
+```
+
+Building an API app produces the bundle, and `voltro serve` boots from it. In **production** (`NODE_ENV=production`) the bundle is **required** — you run `voltro build` before `voltro serve`, and a bundle-build failure is fatal: production **never transpiles on demand**, so it fails loud rather than silently falling back to the slow tsx path. (`voltro dev` and a non-production local `voltro serve` still fall back to tsx as a convenience.) The generated Dockerfiles already do this: `voltro build` at build time, `voltro serve` at start.
+
+Because production never transpiles, the serve image needs none of the build toolchain. The framework declares `tsx`, `esbuild`, `vite`, and Tailwind as **optional** dependencies of `@voltro/cli`, and the production Dockerfiles isolate the app with `pnpm --prod --no-optional deploy` — which drops that whole tree (and its native binaries) from the image. A serve image ships only what it runs at runtime: your app, the framework, and the one SQL driver you declared.
+
 ## Tiers (Voltro Cloud — coming soon)
 
 Managed cloud hosting is not yet available; the Pro / Enterprise rows below are the planned managed tiers. Today you self-host and run `voltro dormancy` yourself.

package/templates/apps/api-ai/package.json

@@ -11,16 +11,16 @@
   "dependencies": {
     "@effect/platform": "^0.96.1",
     "@effect/rpc": "^0.75.1",
-    "@voltro/ai": "0.2.1",
-    "@voltro/cli": "0.2.1",
-    "@voltro/database": "0.2.1",
-    "@voltro/env": "0.2.1",
-    "@voltro/protocol": "0.2.1",
-    "@voltro/runtime": "0.2.1",
+    "@voltro/ai": "0.3.0",
+    "@voltro/cli": "0.3.0",
+    "@voltro/database": "0.3.0",
+    "@voltro/env": "0.3.0",
+    "@voltro/protocol": "0.3.0",
+    "@voltro/runtime": "0.3.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.2.1",
+    "@voltro/testing": "0.3.0",
     "typescript": "^5.7.0",
     "vitest": "^3.0.0"
   }

package/templates/apps/api-auth/package.json

@@ -12,17 +12,17 @@
   "dependencies": {
     "@effect/platform": "^0.96.1",
     "@effect/rpc": "^0.75.1",
-    "@voltro/cli": "0.2.1",
-    "@voltro/database": "0.2.1",
-    "@voltro/env": "0.2.1",
-    "@voltro/plugin-auth": "0.2.1",
-    "@voltro/protocol": "0.2.1",
-    "@voltro/runtime": "0.2.1",
-    "@voltro/sql-postgres": "0.2.1",
+    "@voltro/cli": "0.3.0",
+    "@voltro/database": "0.3.0",
+    "@voltro/env": "0.3.0",
+    "@voltro/plugin-auth": "0.3.0",
+    "@voltro/protocol": "0.3.0",
+    "@voltro/runtime": "0.3.0",
+    "@voltro/sql-postgres": "0.3.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.2.1",
+    "@voltro/testing": "0.3.0",
     "typescript": "^5.7.0",
     "vitest": "^3.0.0"
   }

package/templates/apps/api-backend/package.json

@@ -12,16 +12,16 @@
   "dependencies": {
     "@effect/platform": "^0.96.1",
     "@effect/rpc": "^0.75.1",
-    "@voltro/cli": "0.2.1",
-    "@voltro/database": "0.2.1",
-    "@voltro/env": "0.2.1",
-    "@voltro/plugin-multitenancy": "0.2.1",
-    "@voltro/protocol": "0.2.1",
-    "@voltro/runtime": "0.2.1",
+    "@voltro/cli": "0.3.0",
+    "@voltro/database": "0.3.0",
+    "@voltro/env": "0.3.0",
+    "@voltro/plugin-multitenancy": "0.3.0",
+    "@voltro/protocol": "0.3.0",
+    "@voltro/runtime": "0.3.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.2.1",
+    "@voltro/testing": "0.3.0",
     "typescript": "^5.7.0",
     "vitest": "^3.0.0"
   }

package/templates/apps/api-backend-deactivation/package.json

@@ -12,16 +12,16 @@
   "dependencies": {
     "@effect/platform": "^0.96.1",
     "@effect/rpc": "^0.75.1",
-    "@voltro/cli": "0.2.1",
-    "@voltro/database": "0.2.1",
-    "@voltro/env": "0.2.1",
-    "@voltro/plugin-deactivation": "0.2.1",
-    "@voltro/protocol": "0.2.1",
-    "@voltro/runtime": "0.2.1",
+    "@voltro/cli": "0.3.0",
+    "@voltro/database": "0.3.0",
+    "@voltro/env": "0.3.0",
+    "@voltro/plugin-deactivation": "0.3.0",
+    "@voltro/protocol": "0.3.0",
+    "@voltro/runtime": "0.3.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.2.1",
+    "@voltro/testing": "0.3.0",
     "typescript": "^5.7.0",
     "vitest": "^3.0.0"
   }

package/templates/apps/api-backend-mail/package.json

@@ -12,18 +12,18 @@
   "dependencies": {
     "@react-email/components": "^1.0.12",
     "@react-email/render": "^1.4.0",
-    "@voltro/cli": "0.2.1",
-    "@voltro/database": "0.2.1",
-    "@voltro/env": "0.2.1",
-    "@voltro/plugin-mail": "0.2.1",
-    "@voltro/plugin-multitenancy": "0.2.1",
-    "@voltro/protocol": "0.2.1",
-    "@voltro/runtime": "0.2.1",
+    "@voltro/cli": "0.3.0",
+    "@voltro/database": "0.3.0",
+    "@voltro/env": "0.3.0",
+    "@voltro/plugin-mail": "0.3.0",
+    "@voltro/plugin-multitenancy": "0.3.0",
+    "@voltro/protocol": "0.3.0",
+    "@voltro/runtime": "0.3.0",
     "effect": "^3.21.2",
     "react": "^19.0.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.2.1",
+    "@voltro/testing": "0.3.0",
     "typescript": "^5.7.0",
     "vitest": "^3.0.0"
   }

package/templates/apps/api-backend-mariadb/package.json

@@ -12,18 +12,18 @@
   "dependencies": {
     "@effect/platform": "^0.96.1",
     "@effect/rpc": "^0.75.1",
-    "@voltro/cli": "0.2.1",
-    "@voltro/database": "0.2.1",
-    "@voltro/env": "0.2.1",
-    "@voltro/plugin-multitenancy": "0.2.1",
-    "@voltro/plugin-storage": "0.2.1",
-    "@voltro/protocol": "0.2.1",
-    "@voltro/runtime": "0.2.1",
-    "@voltro/sql-mysql": "0.2.1",
+    "@voltro/cli": "0.3.0",
+    "@voltro/database": "0.3.0",
+    "@voltro/env": "0.3.0",
+    "@voltro/plugin-multitenancy": "0.3.0",
+    "@voltro/plugin-storage": "0.3.0",
+    "@voltro/protocol": "0.3.0",
+    "@voltro/runtime": "0.3.0",
+    "@voltro/sql-mysql": "0.3.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.2.1",
+    "@voltro/testing": "0.3.0",
     "typescript": "^5.7.0",
     "vitest": "^3.0.0"
   }

package/templates/apps/api-backend-storage/package.json

@@ -10,17 +10,17 @@
     "test": "voltro test"
   },
   "dependencies": {
-    "@voltro/cli": "0.2.1",
-    "@voltro/database": "0.2.1",
-    "@voltro/env": "0.2.1",
-    "@voltro/plugin-multitenancy": "0.2.1",
-    "@voltro/plugin-storage": "0.2.1",
-    "@voltro/protocol": "0.2.1",
-    "@voltro/runtime": "0.2.1",
+    "@voltro/cli": "0.3.0",
+    "@voltro/database": "0.3.0",
+    "@voltro/env": "0.3.0",
+    "@voltro/plugin-multitenancy": "0.3.0",
+    "@voltro/plugin-storage": "0.3.0",
+    "@voltro/protocol": "0.3.0",
+    "@voltro/runtime": "0.3.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.2.1",
+    "@voltro/testing": "0.3.0",
     "typescript": "^5.7.0",
     "vitest": "^3.0.0"
   }

package/templates/apps/api-data-advanced/package.json

@@ -11,17 +11,17 @@
   "dependencies": {
     "@effect/platform": "^0.96.1",
     "@effect/rpc": "^0.75.1",
-    "@voltro/cli": "0.2.1",
-    "@voltro/database": "0.2.1",
-    "@voltro/env": "0.2.1",
-    "@voltro/plugin-governance": "0.2.1",
-    "@voltro/plugin-multitenancy": "0.2.1",
-    "@voltro/protocol": "0.2.1",
-    "@voltro/runtime": "0.2.1",
+    "@voltro/cli": "0.3.0",
+    "@voltro/database": "0.3.0",
+    "@voltro/env": "0.3.0",
+    "@voltro/plugin-governance": "0.3.0",
+    "@voltro/plugin-multitenancy": "0.3.0",
+    "@voltro/protocol": "0.3.0",
+    "@voltro/runtime": "0.3.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.2.1",
+    "@voltro/testing": "0.3.0",
     "typescript": "^5.7.0",
     "vitest": "^3.0.0"
   }