The starter gallery is a curated set of apps you can deploy as your own. Choose a card, confirm the app name and any requested values, and deploy. Your app gets its own source checkout, database, route, and deploy history.

Each starter is pinned to an exact Git commit, so two people choosing the same card begin with the same code and initial data. The source repository carries the application and its compose.yaml.

share an app

The gallery is curated by Kedge. To share your own app, link directly to its public Git source:

https://kedge.dev/deploy?repo=https://github.com/acme/notes.git&ref=0123456789abcdef0123456789abcdef01234567&root=app

repo identifies the repository, ref selects a branch, tag, or commit, and root selects an app directory within a monorepo. A full commit SHA gives everyone the same revision and can use a prepared release.

A repository README can carry the same link as a badge:

[![Deploy to Kedge](https://kedge.dev/button.svg)](https://kedge.dev/deploy?repo=https://github.com/acme/notes.git&ref=0123456789abcdef0123456789abcdef01234567)

Opening the link previews the source and Compose configuration before anything is created.

deploy inputs and generated secrets

A shared app can ask for per-deploy values. Top-level x-kedge.inputs names Compose interpolation values shown by the deploy form:

name: notes

x-kedge:
  inputs:
    TITLE:
      description: Site title
      default: My notes
    ADMIN_EMAIL:
      description: Initial administrator

services:
  web:
    build: .
    ports: ["8000"]
    environment:
      SITE_TITLE: ${TITLE}
      ADMIN_EMAIL: ${ADMIN_EMAIL}

Each input can set description, default, and optional. Required inputs must be non-empty after interpolation.

Secret values do not belong in inputs or source:

services:
  web:
    secrets: [session-key]

secrets:
  session-key:
    x-kedge:
      generate: {bytes: 32}

The value is generated once for each app, mounted at /run/secrets/session-key, and preserved across deploys.

fast repeat deploys

Kedge may cache a successful pinned revision: source, runtime snapshot, and initial database state. A later app can reuse them instead of fetching, building, booting, and seeding again. It still gets an independent source checkout, database, route, and deploy history.

This covers pinned single-service web apps with the default database and settings. Personalized apps and incompatible revisions use the normal build path.

source import or app fork?

A source import starts from a pinned repository revision and its initial seed state. An app fork copies the current state of one of your running apps, including its latest database contents, and may reuse its snapshot. Both become independent apps after creation.

kedge fork myapp myapp-experiment

See shared data and volumes. The generated REST reference provides the same operation for automation.