How applications work

Source types, desired vs observed state, and the create–deploy lifecycle.

Repository-validated operator guidance View source ↗

#Source types

Type	Stored as	Needs to deploy
DOCKER_IMAGE	source_config.image	A compose document (the deploy path runs Compose, not bare images).
GIT	source_config gitUrl, gitBranch, gitProvider	The git-deploy engine builds from the repository.
COMPOSE	source_config content or composeContent	The document itself, validated server-side.

#Desired vs observed

Every application carries desired_state (running, stopped, removed — what you asked for) and observed_status (idle, then whatever the node last reported — what is true). The dashboard shows observed status; it never upgrades an unknown reading to healthy. Creation also accepts the wizard's flat fields (type, image, gitUrl, composeContent, nodeId, regionId) and folds them into source_config; edits merge into the stored document without wiping keys you did not touch.

FLOW

Application lifecycle

01Create appfold fields

02source_config storedtrigger

03Deploy requestedprovision

04Stack deployedreport

05Observed status

Start, stop, restart

Start sets desired running then powers on; stop sets stopped then powers off; restart only sends power. All three require the app to be bound to a runnable server, otherwise the API answers 501 instead of pretending.

#Key endpoints

Under /api/v1

GET  /organizations/:orgId/apps        list
POST /organizations/:orgId/apps        create {name, sourceType|type, sourceConfig|flat fields}
GET  /apps/:id                         detail
PUT  /apps/:id                         update (merges source_config)
POST /apps/:id/start|/stop|/restart    lifecycle
POST /apps/:id/deploy                  deploy (git engine for GIT, Compose path otherwise)
GET  /apps/:id/deployments             deployment history
GET  /apps/:id/domains                 exposure
GET  /apps/:id/compose  PUT ...        compose document view/edit
GET  /apps/:id/git      PATCH ...      git source view/branch