Deployment Defaults on Varity

Varity Team Core Contributors Updated June 2026

Varity turns a supported source project or a runnable Docker service image into a live app URL. This page explains the public settings Varity applies during that deploy, what you can override, and what remains private.

Public docs boundary

This page describes the user visible deployment contract. Varity does not publish private system behavior, infrastructure credentials, reliability mechanics, or hosting internals.

What Varity Decides

When you deploy, Varity applies defaults across five areas:

Area	Default behavior
Input type	Source project, GitHub repo, dashboard input, MCP request, or runnable Docker image
Hosting mode	Static for static output, dynamic for servers, APIs, SSR apps, and images
Build process	Framework specific build defaults for supported source projects
Runtime settings	App name, URL shape, exposed port, environment variables, and health checks
Services	Databases, cache, object storage, and model runtime when detected

For supported source projects, Varity handles the build and runtime setup. For Docker image deploys, you provide an image that already runs an HTTP service.

Deployment Flow

1. Read the input

   Varity accepts a project folder, GitHub repo, dashboard form, MCP tool request, or image reference.

2. Classify the app

   Varity checks framework files, package manifests, Python requirements, Go modules, static build output, Docker image settings, and any deploy flags you supplied.

3. Apply public settings

   Varity chooses static or dynamic hosting, sets the public app URL, forwards allowed environment variables, and applies framework specific build defaults.

4. Attach detected services

   If your dependencies indicate Postgres, Redis, MongoDB, MySQL, object storage, or a model runtime, Varity starts the matching service and injects the runtime URL.

5. Launch and return status

   Varity deploys the app, returns the live URL, and exposes status, logs, environment updates, and redeploy tools through the CLI and MCP server.

What You Can Control

Setting	How to control it	Notes
App name	--name <name> or dashboard field	Controls the Varity app URL
Hosting mode	--hosting auto, static, or dynamic	Leave as auto unless you need to force the mode
Environment variables	.env.varity, .env.local, .env, CLI, dashboard, or MCP	Varity filters known platform leftovers from other hosts
Port	CLI, dashboard, or MCP image deploy input	Required for some Docker images
Docker credentials	Dashboard or MCP deploy input	Used for private registry images
Image reference	--image <ref> or dashboard image field	Must be a runnable HTTP service image
Redeploy behavior	varitykit app deploy, varity_redeploy, or dashboard action	Keeps the same app name when you deploy under the same name

Source Project Defaults

Varity detects supported source projects from files already in your repo:

Node and frontend

Next.js, React, Vue, Astro, Qwik, Vite, Express, Fastify, NestJS, Koa, and Hono are detected from package.json and framework config.

Python

FastAPI, Django, and Flask are detected from requirements.txt, pyproject.toml, and app entry files.

Go

Go modules deploy when the project builds to a runnable HTTP service.

Static HTML

Plain static output deploys as static hosting at a varity.app path.

Source deployments do not require a local Docker install. Unsupported source languages return a clear unsupported stack error. You can still deploy those workloads by providing a runnable Docker or OCI image.

Docker Image Defaults

Docker image deploys skip source detection and build steps. Varity expects the image to:

• Pull successfully from the public registry or from the private registry credentials you provide
• Start an HTTP service
• Listen on the configured port
• Stay healthy long enough for the deploy health check

Use Deploy a Docker Image for image examples, private registry setup, port configuration, and unsupported image patterns.

Service Defaults

Varity starts supported services when your dependencies indicate they are needed:

Detected need	Runtime variable
Postgres	DATABASE_URL
Redis	REDIS_URL
MongoDB	MONGODB_URI
MySQL	MYSQL_URL
Object storage	MINIO_URL, MINIO_ACCESS_KEY, MINIO_SECRET_KEY
Model runtime	OLLAMA_URL

The full detection table lives in Auto wired Services.

What Stays Abstracted

The public contract is the deploy input, the app URL, supported configuration, logs, status, billing profile, and support path. The following are not public API:

• Infrastructure credentials
• Private system behavior
• Reliability and recovery mechanics
• Private operational data
• Hosting internals

These details may change as Varity improves reliability, pricing, and workload support. Public tools should rely on the documented CLI, MCP, and HTTP API surfaces instead.

When to Override Defaults

Most deploys should keep --hosting auto. Override only when the detected setting does not match your app:

• Use --hosting static for a prebuilt site with no server runtime
• Use --hosting dynamic for an API, SSR app, websocket app, or backend worker exposed over HTTP
• Set the port when deploying an image that does not listen on the default port
• Set environment variables when your app needs third party API keys or product specific configuration

Related Pages

• How Varity Works
• Deploy Your App
• Deploy a Docker Image
• Auto wired Services
• Environment Variables