v147-alpha.1 is out. This is the largest release since v122, and most of the work points in one direction: Vary apps are becoming real deployable services.
The headline is Via, the application server system for Vary apps. Via is still early alpha. Commands, config, host requirements, and operator flows may change between releases. The shape matters: Vary now has a server-side path where committed source becomes a checked, packaged, signed, running app with routes, logs, config, secrets, and add-on bindings owned by the platform.
The full table of changes is on the v147-alpha.1 release page. This article covers the parts most likely to matter if you are coming from v122.
Vary apps still compile to JVM artifacts and can run anywhere Java runs. Via adds an opinionated home for the cases where you want the platform to own the operational path.
The developer-facing shape is:
vary target add prod https://vary.example.com
vary login --target prod --name alice
vary app preflight echo --target prod --apply-manifest
vary app deploy echo --target prod
vary app smoke echo --target prod
Operators use the via command on the host. They install the platform, initialize the control plane, create users and apps, manage routes, attach certificates, configure add-ons, and inspect health.
The release path is intentionally direct:
| Step | What Via owns |
|---|---|
| Source intake | Receives committed source and records the resolved revision. |
| Build and checks | Builds in a clean environment and runs the compiler and tests. |
| Artifact | Packages and signs the server-built artifact. |
| Runtime | Launches the verified app runtime and preserves a healthy prior release when a new one fails. |
| Bindings | Delivers config, secrets, identity, and add-on descriptors through platform-owned channels. |
| Routes | Publishes only routes that pass domain, certificate, and readiness policy. |
| Audit | Records deploy states, release ids, logs, status, and operator actions. |
Since v122, that system went from design to a packaged Via binary, deploy flow, host install helpers, app manifests, route policy, domain proof tokens, managed certificates, runtime trust reconciliation, backup preservation, and status and doctor commands.
Again: this is early alpha. The release is useful for test deployments and for understanding the direction of the platform. It is not a promise that the Via command surface is settled.
The language side grew to match the server work. Vary now has first-class declarations for public API contracts, table schemas, and read-model queries.
An api block declares routes, methods, request types, response types, auth, cache, capabilities, and idempotency in one place. The compiler projects that shape into route manifests, JSON schema, OpenAPI output, typed service clients, compatibility metadata, and docs metadata.
Tables can be declared on data types with metadata such as primary keys, unique constraints, indexes, defaults, and foreign keys. query declarations describe typed read models using structured clauses instead of hand-written row mapping. The compiler validates those projections and generates the SQL and row decoders.
The point is the same as the rest of Vary: the boundary should be a typed declaration, not a group of strings that happen to agree today.
v147 also changes how Vary HTTP services run. The old Quarkus backend has been replaced by a smaller Javalin runtime path for service jars. That keeps the smoke fixture and generated resource path focused while the HTTP DSL evolves.
Generated HTTP service jars now serve their OpenAPI spec, so the route contract is available at runtime as well as at build time. The small examples/http-service-smoke fixture covers the important path: typed api contracts across modules, service implementations, generated resources, optional and invalid query parameters, request id handling, and a real SQLite-backed handler path.
This matters because the HTTP surface is now tied to the same declarative model as the compiler projections. The app, generated resource, OpenAPI document, and typed client all come from the same contract.
The persistence story also became more platform-shaped. On Via, a Vary app can refer to SQLite by binding name instead of by file path.
Application code can ask for a managed connection:
let db = Sql.connect_managed("DATABASE", tracker_schema())
Locally, that can fall back to a normal SQLite file for tests. On Via, the binding is resolved through the platform. The host owns the file, add-on lifecycle, snapshot and restore path, and runtime authorization. The app sees a binding name, not a path or a credential.
This release also hardens the operational side around add-on readiness, stale binding reconciliation, retained evidence during delete flows, snapshot and restore commands, credential rotation, and managed SQLite startup.
The public API story changed as much as the product surface. v147 adds compiler-owned route manifests, OpenAPI snapshots, generated TypeScript clients, route catalogs, docs metadata, and compatibility metadata.
The issue tracker example was promoted onto the declarative API and persistence path so the public API shape is exercised by a real app, not only tiny examples. The platform is still alpha, but the API and deployment model are more explicit than they were in v122.
vary check gained rules that push code toward the declarative path: manual route catalogs, hand-built JSON strings, manual handler adapters, row mapping by getter calls, setter-sequence projections, and structured markup strings now have canonical replacements.
The standard library grew around API boundaries: auth, config, content, mapping, metrics, paging, projection, URL policy, XML, API context, and API responses. These modules exist so application code can use supported primitives instead of inventing one-off boundary helpers.
The website and docs were expanded around those changes. There are new Via docs for install, deploy lifecycle, architecture, operations, add-ons, managed SQLite, routes, certificates, config redeploys, runtime trust, diagnostics, and the CLI reference. The courses also now cover Via install and deploy flows.
If varyup is already installed:
varyup install latest
That installs v147-alpha.1 and verifies the release archive. Anyone coming from before v117 should upgrade varyup first so release signatures are checked correctly.
v122 was a trust-loop release: vary var, mutation scheduling, Frugal, and explainable checks. v147 is the server-shaped release. It adds the early Via platform and moves API and persistence shape into declarations.
The next work is to make those paths smaller, steadier, and less surprising. Via needs more hardening before it can stop carrying the early-alpha label, but the direction is now visible: Vary source should become a checked, signed, running service without every app rebuilding the same operational machinery.
The full change list is on the v147-alpha.1 release page.