
<div class="callout callout-attn"><p><strong>Alpha.</strong> VIA is under active development. APIs, operational flows, and host requirements may change between releases.</p></div>

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:

```mermaid
flowchart TD
    PUSH[Source push] --> CHECKOUT[Clean checkout]
    CHECKOUT --> TESTS[Vary typecheck and tests]
    TESTS --> ART[Signed artifact]
    ART --> LAUNCH[Verified runtime launch]
    LAUNCH --> BIND[Config and add-on bindings]
    BIND --> ROUTES[Validated routes and domains]
    ROUTES --> AUDIT[Durable status, logs, and audit]
```

## Why it exists

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.

## Main pieces

| 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 owner model

App owners use Via from a workstation. Create a named target first, then use
that target for app commands:

```bash
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:

```bash
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
```

## Operator model

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:

```bash
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](/docs/via/install/), or read [Add-ons](/docs/via/addons/) for the managed resource model.
