# App lifecycle

Every Comind.work app moves through a series of stages - from local development to production use. Understanding this lifecycle helps you plan your development workflow, collaborate with system admins and workspace admins, and ship apps that are easy to configure at every level.

## Roles and artifacts[​](#roles-and-artifacts "Direct link to Roles and artifacts")

Four roles participate in the app lifecycle. Each produces or consumes specific artifacts:

| Role                | What they do                                                               | Artifact they produce                                      |
| ------------------- | -------------------------------------------------------------------------- | ---------------------------------------------------------- |
| **Developer**       | Edits app code locally (TypeScript/NPM)                                    | App low-code (local)                                       |
| **System admin**    | Edits apps via zero-code editor or web code editor; deploys and customizes | App zero-code, app low-code (web), app deployment settings |
| **Workspace admin** | Installs deployed apps into workspaces; customizes per-workspace settings  | App installation settings                                  |
| **End-user**        | Personalizes app behavior for themselves                                   | App personalization settings                               |

These roles feed into two shared artifacts:

* **App compile-time** - the compiled schema object containing fields, actions, layouts, and logic. Produced by the developer CLI (`npx comind i`) or by web publish.
* **App run-time** - the configured, running app. Combines the compile-time schema with deployment settings, workspace settings, and user personalization. All three settings layers bypass compile-time and feed directly into run-time.

## Zero-code and low-code authoring[​](#zero-code-and-low-code-authoring "Direct link to Zero-code and low-code authoring")

Comind.work supports two authoring modes:

* **Zero-code** - a visual app editor in the web UI. Create and edit apps by clicking - fields, actions, layouts, no code written.
* **Low-code** - TypeScript NPM packages using the `@comind/api` SDK. The approach is highly declarative. See [Package structure](/developer-guide/app-architecture/package-structure.md) for how an app project is organized.

Most teams pick one mode and stay there. Apps started in the zero-code editor can be exported to TypeScript using `npx comind dump <app-id> <target-directory>` when a team is ready to move to code-based development - see the [CLI reference](/developer-guide/reference/cli-reference.md) for command details. Once an app is in the low-code track, code in Git is the source of truth and `npx comind install` is the only deploy path.

## DevOps lifecycle[​](#devops-lifecycle "Direct link to DevOps lifecycle")

![Diagram showing the four stages: develop, deploy, install, use - with roles and artifacts at each stage](/assets/images/dev-deploy-install-use-7c107a1904721a6206b417246a86cf4e.png)

An app moves through three stages before it reaches end-users:

### 1. Developing[​](#1-developing "Direct link to 1. Developing")

Developers change the app and preview it in the DEV environment. App-settings variables can be introduced at this stage. When the app is ready, it is marked as released.

### 2. Deployed[​](#2-deployed "Direct link to 2. Deployed")

A system admin picks an available released app and deploys it to production. At this point the admin configures deployment-level app settings - values that apply across all workspaces where the app will be installed.

### 3. Installed[​](#3-installed "Direct link to 3. Installed")

Workspace admins select available deployed apps and install them into their workspaces. They can customize workspace-level settings. Some apps also support personalization settings that individual users can adjust.

## Deployment pipeline[​](#deployment-pipeline "Direct link to Deployment pipeline")

The diagram below shows the path an app takes from a developer's machine to production. For the full list of CLI commands, see the [CLI reference](/developer-guide/reference/cli-reference.md). For branch and commit conventions, see [Git workflow](/developer-guide/getting-started/git-workflow.md).

<!-- -->

### Git is the source of truth[​](#git-is-the-source-of-truth "Direct link to Git is the source of truth")

All low-code app code lives in your Git repository, and `npx comind install` is the single command that compiles and deploys to a workspace. There is no separate "sync the source" step:

* Every change ends up in a Git commit before it reaches production
* Production deploys come from the `prod` branch with signed commits, never from ad-hoc edits
* Git gives you history, rollback, code review, and collaboration that a server-side store cannot

## App settings levels[​](#app-settings-levels "Direct link to App settings levels")

Settings exist at three levels, each with a different scope and effect:

### App-system-settings (compile-time)[​](#app-system-settings-compile-time "Direct link to App-system-settings (compile-time)")

* **Who:** system admins only
* **Scope:** all workspaces where the app is installed
* **Effect:** changing these triggers redeployment (recompilation)
* **Also known as:** deployment settings, compile-time settings, system constants

### App-workspace-settings (run-time)[​](#app-workspace-settings-run-time "Direct link to App-workspace-settings (run-time)")

* **Who:** workspace admins, for their own workspaces only
* **Scope:** a single workspace
* **Effect:** immediate, no redeployment needed
* **API:** `ComindView.getVars()` (client) or `ComindServer.getVars()` (server)

### App-personalization-settings (run-time)[​](#app-personalization-settings-run-time "Direct link to App-personalization-settings (run-time)")

* **Who:** individual end-users
* **Scope:** per-user per-workspace, or per-user across all workspaces

For a deeper look at how to define and consume settings in your app code, see [Settings model](/developer-guide/building-blocks/settings-model.md).

## App settings types[​](#app-settings-types "Direct link to App settings types")

| Type                   | Scope                                        | Examples                                                               |
| ---------------------- | -------------------------------------------- | ---------------------------------------------------------------------- |
| Common settings        | System-wide, every app                       | Hide conversation/history in form, disable email notifications         |
| App-specific variables | Per-app, introduced by developer             | Currency for a field, default assigned user, default record visibility |
| App-specific secrets   | Per-app, server-only (never sent to browser) | Auth tokens for external systems, passwords, API credentials           |

Customized settings are not part of the code. Changing a setting does not change the code - it only affects the run-time behavior of the app.

## Related[​](#related "Direct link to Related")

* [Install and manage apps](/admin-guide/workspace-admin/install-manage-apps.md) - how workspace admins install, update, and remove apps
* [Standard apps catalog](/developer-guide/app-architecture/standard-apps-catalog.md) - the full list of platform apps available for installation and customization