Via is an application platform for Vary apps. Operators get one host that knows how to run Vary. App owners get a short path from committed source to a tested, running service with routes, domains, config, secrets, and add-on bindings.
It follows one rule: app owners submit source, and Via decides what becomes a running release. The host owns the whole path:
Via understands Vary apps as applications. It can typecheck and test Vary source, build a signed artifact, launch the runtime, provide config and add-on bindings, and expose the app through domains and routes.
That matters when something is serving traffic. Operators need to know where the code came from, which Vary toolchain built it, which checks ran, what bindings were attached, which route points at it, and whether the server produced the artifact.
Via avoids workstation-built binaries. An app owner pushes source to the server-hosted Git endpoint. The builder compiles from a clean checkout. The runner launches only server-signed artifacts.
The guardrails are practical. Failed tests do not replace a healthy runtime. Secrets are delivered through workload identity instead of command-line arguments. Managed SQLite is bound by name instead of hard-coded paths. Public traffic attaches only after domain and route policy gates pass.
| Piece | Responsibility |
|---|---|
| Control plane | Owns apps, users, source intake, releases, operations, audit, domains, routes, and add-on state. |
| Builder | Tests, compiles, packages, and signs Vary app artifacts from clean source. |
| Runner | Verifies signed artifacts and starts or supersedes Vary app runtime containers. |
| Config server | Gives running workloads authorized config, secrets, and add-on descriptors. |
| Add-ons | Provides managed resources through app bindings. SQLite is the first provider, not the whole add-on system. |
| Proxy | Publishes validated app routes through managed public routing. |
App owners use Via from a workstation. Create a named target first, then use that target for app commands:
vary target add prod https://vary.example.com
vary login --target prod --name alice --token-stdin
vary app init --server https://vary.example.com --app my-api
vary app deploy my-api --target prod
vary app status my-api --target prod
vary app logs my-api --target prod --source runtime
For public traffic, deployment is separate from hostname ownership. The app
owner declares routes in via.app.toml; deploy applies the manifest and pauses
for operator approval when policy requires it:
vary app deploy my-api --target prod --apply-manifest
via domain approve my-api my-api.apps.example.com
vary app deploy my-api --target prod --resume
Operators install and initialize the host, mint the first login token, start the platform services, provision apps, define domain policy, approve protected hostnames, manage add-ons, and inspect operations.
Operator examples assume via install has added your host user to the Via
admin/shared group. Reconnect to the host or run newgrp vary after first
install so that group membership is active in your shell.
The basic host path is:
via install --print-prereq-script | sudo bash
via install
via init --domain vary.example.com
via doctor
via admin create alice
via app ensure my-api --owner alice
For an already-installed host, install the newer toolchain with varyup, then
run via upgrade and via doctor.
Continue to Install, or read Add-ons for the managed resource model.