An app is the unit you name, deploy, and manage. Every app has a source tree, a database, and a deploy history, whatever it is built from.

Every app runs as one of three things, marked by a glyph in kedge apps and the web console:

mark type you give it it runs
site files, some of which can execute at the edge, handlers per request in a VM
service source, a Dockerfile, or an image as a pooled process, scaled to demand and to zero
machine either, plus a persistent volume as one VM per ordinal, kept for life

A label beside the mark names the variation, such as site · files + handlers, and a second mark records how the content arrived.

Most apps are sites, and a site needs no server code of its own. A service is the escape hatch when a workload wants a long-lived process; a Compose file defines several services as one app.

instances and machines

A service runs in a hardware-isolated VM. How those VMs are held is one choice:

instances machines
identity disposable an ordinal, kept for life
storage none of its own a persistent volume
scaling follows demand, down to zero a fixed count, minimum one
address one virtual address one each, plus one for the set

Instances are the default: Kedge starts them near demand and removes them when idle. Declaring a persistent volume moves the app onto machines instead, each keeping its identity and disk across deploys and host moves.

A machine always belongs to an app and is addressed by its ordinal within it. There is no separate machine resource to create or destroy.

A workspace is a machine you develop on rather than serve from, carrying your checkout, tools, and build caches on the same durable disk. It needs no service at all.

Every app includes /shared.db and /shared/ for state shared across instances and regions. Reach for a persistent volume only when software requires a private local filesystem.

Apps are global resources. Public routes receive HTTPS, private services resolve through account-local DNS, and an authentication policy can gate any app type at ingress.