Every source deploy is an ordinary Git history. kedge up, a manual push, GitHub, the browser editor, and an import all feed the same build and cutover pipeline. The files select a site, automatic source build, Dockerfile build, or Compose deploy; each path creates or updates an app. See builds & images.

from a directory

From a project directory, the shortcut can initialize Git when needed, commit the working tree, add a username-scoped kedge remote, and push the current branch:

kedge up --dry-run
kedge up

The first push creates the app. The production branch defaults to main and can be changed with top-level x-kedge.production-branch. Any other branch of a single-service app is an isolated preview at https://<name>--<branch>.kedge.run. Its managed database and files branch from production once; redeploys retain preview changes. Multi-service previews are not available. Previews expire automatically. See shared data for storage boundaries.

Identical Git trees reuse the prior build, so a retry or amended commit with unchanged content redeploys in milliseconds.

Apps deployed by push keep their source durably: the app page shows a git clone snippet, and the edit code button opens a browser editor over the repo; saving a file commits and redeploys through the same pipeline as a push.

other ways in

• kedge import <git-url> [name] clones a public repository into an app you own and can continue pushing.
• kedge publish --app <name> --image <ref> deploys a public prebuilt image.
• Inline content, piped stdin, and scp publish documents, functions, and file trees without creating a local repository first.
• The web editor commits each save into the same durable repository.

app names

kedge up derives the app name from the directory and prefixes your username. The manual equivalent is a namespaced Kedge remote and a push:

git remote add kedge ssh://kedge.dev/$(kedge whoami)/myapp.git
git push kedge main

The namespaced path creates <you>-myapp, and no other account can create any <you>-* name. A bare repo name (ssh://kedge.dev/myapp.git) instead claims myapp first-come from the shared global pool.

zero-downtime cutover

The current version keeps serving through the build. The new version boots, is snapshotted, and must serve a request before traffic moves. If it cannot, the deploy fails and the current version stays live.

kedge rollback <app> sends the previous version through the same gate. Services with persistent volumes roll machines in place because each volume has one writer.

Runtime & scaling explains the snapshot and health checks behind this gate.

GitHub deploys

The Kedge GitHub App connects selected repositories without a long-lived personal access token. It deploys the production branch, creates pull-request previews, and reports status to GitHub. See GitHub deploys.

update a Compose app

Redeploying compose.yaml reconciles its Kedge app. New services are added, shared builds are reused, and generated secrets keep their values. Kedge refuses edits that would implicitly discard persistent state. The exact model and supported fields live in the Compose reference.

environment and secrets

Commit non-secret defaults under a service's environment. Store deploy-time values with kedge env <app> or the app page. Standard Compose interpolation can make a value mandatory:

services:
  web:
    environment:
      API_KEY: ${API_KEY:?set with kedge env}

Compose secrets and configs deliver values as guest files. The x-kedge generator can mint a secret once without putting the value in Git; see Compose secrets.

time-limited apps

An app expiration deletes its route, compute, snapshot, and app record at the deadline. Set it on the app page or with kedge expire <app> <48h|7d|timestamp|clear>. Previews use the same cleanup.