Deployment course

Push and Test an App on Via

Create the first operator session, connect a local Vary project, test it, push a deploy, and inspect deploy output.

This course starts after the Via server is installed and running. We assume Via is running on a server host, and you are running Vary from your local workstation. Keep two terminals open: one connected to the Via server for every via command, and one on your workstation for every vary command. Replace vary.example.com, alice, and my-api before running the commands.

Section 1

Provision

Create an operator session and a server-side app record.

server terminal
# Create a one-time admin token for the first operator. via admin create alice # Create the server-side app record and bare Git repo. via app ensure my-api --owner alice

Lesson 1 / server terminal

Create an operator and app on the server

Mint a one-time admin token and create the app record that will receive source pushes.

via admin create prints a one-time adm_... token; copy it now because the next lesson exchanges it for workstation credentials. via app ensure is idempotent for the same app and owner, so it is safe to re-run when checking setup. Both commands run on the Via server.

Via Install Deploy an App
Run via app ensure my-api --owner alice
Expected output
Accepted pattern (?i)created|exists|ensured|my-api
workstation terminal
# Exchange the one-time admin token for workstation credentials. vary login https://vary.example.com --name alice --token-stdin

Lesson 2 / workstation terminal

Log in from your workstation

Exchange the one-time admin token for workstation credentials.

Run this on your workstation, not the server. vary login trades the adm_... token printed in the previous lesson for a session that lets the vary CLI talk to the Via server.

Deploy an App Via Install
Run vary login https://vary.example.com --name alice --token-stdin
Expected output
Accepted pattern (?i)session|credentials|logged in|expires
workstation terminal
# Work from the local Vary project you want to deploy. cd my-api # Record the Via server URL and app name in vary.toml. vary app init --server https://vary.example.com --app my-api # Confirm only the deployment config changed. git status --short # Commit the config so deploys can push a clean tree. git add vary.toml git commit -m "Configure Via deployment"

Lesson 3 / workstation terminal

Connect a local project

Record the Via server and app id in the project's vary.toml.

Run this in the Vary project you want to deploy. vary app init writes the local app deployment settings but does not create the server-side app; that was the operator step. Commit the config change so the deploy command can push a clean Git tree.

Deploy an App Project Layout
Run vary app init --server https://vary.example.com --app my-api
Expected output
Accepted pattern (?m)^.*vary\.toml.*$

Section 2

Test and push

Run local tests, push committed source, and inspect Via's deploy records.

workstation terminal
# Run local tests before pushing source to Via. vary test # Via deploys expect committed source by default. git status --short # Push the current commit and wait for the deploy result. vary app deploy # Confirm the app's current deploy and runtime state. vary app status

Lesson 4 / workstation terminal

Test locally and deploy committed source

Run the project's tests, push the current Git commit to Via, and wait for the deploy result.

Run the local test suite before pushing. vary app deploy rejects dirty working trees by default, mints a one-use deploy token, pushes the current commit to the Via host, and streams status until the deploy reaches a terminal state. A successful deploy becomes the current running release.

Deploy an App Via Operations
Run vary app deploy
Expected output
Accepted pattern (?i)\brunning\b
workstation terminal
# List recent server builds for the app. vary app builds --app my-api # Inspect one build record in detail. vary app build <build-id> --app my-api # Stream the test logs when a result needs detail. vary app logs --tests <build-id> --app my-api

Lesson 5 / workstation terminal

Inspect build output from your workstation

Find the build id, inspect the build detail, and stream test logs for the deploy.

vary app builds lists recent builds for the app over the Via API. Use the build id with vary app build to inspect a single record and vary app logs --tests to stream its test output. All three commands run on your workstation.

Via Operations Deploy an App
Run vary app builds --app my-api
Expected output
Accepted pattern (?i)build|running|passed|failed
server terminal
# Read the server-side test result directly from the Via state directory. vary app tests <build-id> --app my-api --local --state-dir /var/lib/via

Lesson 6 / server terminal

Read the test result on the server

Confirm the server saw the same test result by reading Via's local state directory.

Run this on the Via server. vary app tests --local --state-dir /var/lib/via skips the API and reads the recorded test result straight from Via's state directory, so you can prove the server itself agreed with the workstation view before the runtime was promoted.

Via Operations Deploy an App
Run vary app tests --app my-api --local --state-dir /var/lib/via
Expected output
Accepted pattern (?i)passed|failed|tests

Section 3

Route and observe

Attach a hostname when routing is ready and watch runtime logs.

workstation terminal
# Ask Via to create a domain ownership challenge. vary app domain request my-api my-api.apps.example.com --target prod # Confirm the required DNS record is visible. vary app domain verify my-api my-api.apps.example.com --target prod # Attach the verified hostname to the running app target. vary app route add my-api my-api.apps.example.com --target prod --port 8080 # Stream runtime logs from the active container. vary app logs --runtime

Lesson 7 / workstation terminal

Attach traffic and read logs

Request a hostname, verify ownership, add a route, and stream runtime logs.

Deploying and routing are separate steps. Domain commands prove app ownership of the hostname, while route creation attaches public traffic only after Via checks policy, verification, certificate coverage, target service, port range, and conflicts. Runtime logs then confirm what the running container is doing.

Domains and Routes Via Operations
Run vary app logs --runtime
Expected output
Accepted pattern (?m)^.*my-api.*$

Course score

0/7 lessons complete

Validate each lesson output to finish this course.