Alpha. Vary is under active development and not ready for production use. Syntax, APIs, performance, and behaviour may change between releases.
Overview
Via is a self-hosted application server for Vary apps. It is the operator-owned platform that takes an app from submitted code to a running service: clean checkout, validation gates, typecheck, tests, build, signing, runtime launch, config, add-on bindings, routes, domains, logs, rollback, backup, and audit.
| Via does | What that means | Why it matters |
|---|---|---|
| Source intake | App owners deploy committed source to the Via host. | Production releases come from server-built source, not workstation-built binaries. |
| Vary checks and builds | Via typechecks, tests, compiles, packages, and signs the app. | A failed build does not replace the currently running app. |
| Runtime launch | Via verifies the signed artifact and starts the app container. | The server knows which artifact is running and how it got there. |
| Config and secrets | Via gives the running app only the config and secrets it is allowed to read. | Secrets stay out of source, build logs, image layers, and deploy commands. |
| Add-on bindings | Via binds resources such as SQLite under names like DATABASE. | App code uses stable names while Via owns storage, credentials, snapshots, and restore. |
| Domains and routes | Via checks hostname policy, DNS proof, approval, certificates, and route conflicts. | Public traffic only reaches an app after the platform gates pass. |
| Operations | Via records status, logs, deploy history, rollback, audit, and backup state. | Operators and app owners can see what happened without guessing from containers. |
Via knows what a Vary app is. Operators do not have to assemble a separate build system, artifact store, runtime launcher, route manager, config mechanism, SQLite lifecycle, test reporting path, rollback flow, and backup trail. Via keeps those pieces tied to the Vary app model.
Deployment starts from source, but source-first is only one part of the model. Via decides what becomes a release, which toolchain produced it, which checks and tests ran, which artifact was signed, which bindings were attached, which route policy passed, and which runtime instance is serving traffic. A failed build, failed test run, failed preflight, or failed route reload does not replace a healthy app.
Via has two roles. Operators own the host, services, policy, routing, backups, add-ons, and app provisioning. App owners own source, deployments, logs, status checks, app config requests, and app-scoped hostname requests. The workflows meet at the control plane, but routine app deployment does not require shell access to the server.
| CLI | Who uses it | What it does |
|---|---|---|
via | Server operators | Installs, initializes, starts, diagnoses, backs up, and manages the server host. |
vary | App owners | Logs in from a workstation, links a Vary project, deploys source, reads app status/logs, and requests app-owned routes. |
Start with the basic loop: understand the model, install a host, deploy one app, then read how Via runs it. Come back for routing, config, storage, and operations once that works.
| Order | Page | Use it for |
|---|---|---|
| 1 | Introduction | What Via provides for Vary apps and how to think about it. |
| 2 | Install | Host prerequisites, install, init, doctor, admin login, daemon start, and app provisioning. |
| 3 | Deploy an app | Workstation login, deploy, status, logs, domains, and routes for an existing Via app. |
| 4 | Architecture | How Via runs Vary apps with services, Docker, public routing, domains, config, and add-ons. |
| 5 | Advanced topics | Day-2 operations once the basic loop works. |
Basic flow
The normal workflow starts with an operator preparing one Ubuntu host. After initialization, that host can run Vary apps. The operator provisions an app record, then the app owner connects a local Vary project and deploys from their workstation.
| Step | What happens |
|---|---|
| Install | An operator prepares one Ubuntu host and starts the server daemons. |
| Provision | The operator creates an app record and managed source repo. |
| Connect | The app owner links a local Vary project to that server app. |
| Deploy | The app owner pushes source; Via tests, builds, signs, and launches it. |
| Bind | Via attaches declared config, secrets, and managed add-ons to the running app. |
| Route | The app owner requests a hostname, proves ownership, and Via attaches traffic after policy checks pass. |
What exists
Via currently runs on one host. It can accept source pushes, test and build Vary apps, start runtime containers, serve managed configuration, bind add-ons, and publish routes through the proxy.
| Component | Purpose |
|---|---|
| Control plane | Owns apps, releases, operations, audit, source intake, domains, routes, and add-on state. |
| Builder | Tests, compiles, packages, and signs Vary app artifacts from clean source. |
| Runner | Verifies signed artifacts and runs Vary app containers. |
| Config server | Provides app config, secrets, and add-on descriptors through workload identity. |
| Add-ons | Provides managed app resources, starting with SQLite, through runtime bindings. |
| Proxy | Publishes Vary apps through managed public routes. |
| Domain governance | Connects app-owned routes to hostname policy, DNS proof, approvals, and certificates. |
Add-ons and bindings
Add-ons are resources that Via manages for an app. App code does not need host paths, credentials, or service details in source. Operators create and bind add-ons to an app. A deploy snapshots those bindings into the release. At runtime, the app asks for the binding by name, and Via returns only the descriptor that release can use.
App code stays stable while Via owns the operational details. An app can use a binding name such as DATABASE; Via decides where the SQLite file lives, how credentials rotate, how snapshots are made, how restore is audited, and which running release can fetch the descriptor.
| Add-on concept | What Via provides |
|---|---|
| Binding name | A stable app-facing name such as DATABASE. |
| Runtime descriptor | The connection information served through workload identity. |
| Operator lifecycle | Create, bind, snapshot, restore, rotate credentials, unbind, and destroy. |
| Release safety | Bindings are snapshotted into releases so a running app sees a consistent view. |
You do not need the operations pages on the first pass. Use the overview, install guide, and deploy guide to get one app running. Come back to the advanced pages when you need public hostnames, secret rotation, managed SQLite, rollback, backup, or service-level diagnostics.
Core pages
| Page | What it covers |
|---|---|
| Introduction | Platform model, app lifecycle, trust boundary, and value for Vary apps. |
| Install | One host setup from prerequisites through app provisioning. |
| Deploy an app | The short app-owner workflow from login through deploy and smoke. |
| Architecture | How Via runs Vary apps with services, Docker, config, routes, domains, and add-ons. |
Advanced topics
Read these only after the basic install and deploy loop works.
| Page | What it covers |
|---|---|
| Deploy lifecycle | Build phases, runtime launch, readiness gates, and source checkout layout. |
| Deploy diagnostics | App status, logs, smoke checks, debug bundles, retries, and command groups. |
| Config redeploys | Roll out config and secret changes without a new source push. |
| Domains and routes | Domain policy, app domain requests, approval, certificate coverage, and route activation. |
| Domain proof token | What the DNS proof token is, why Via requires it, and how to handle it. |
| TLS, routing, and the proxy | HTTPS, validated route application, and maintenance behavior. |
| Runtime trust | Host-published CA roots mounted into managed app runtimes. |
| Add-ons | The managed resource and binding model that SQLite uses. |
| Secrets and config | Workload identity, config server, secret CLI, runtime cache, and rotation. |
| Managed SQLite | The current SQLite add-on provider, runtime proxy, snapshots, restore, credential rotation, and limits. |
| Operations | Status, doctor, history, rollback, key rotation, backup, and load-balancer operations. |
| Services and logs | Control-plane, builder, runner, systemd units, logs, and app provisioning. |