# 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 with bidirectional sync:

* **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.

A typical sync flow looks like this:

1. A system admin creates an app visually using the zero-code editor.
2. A developer pulls it as TypeScript (`npx comind pull`) for customization.
3. The developer pushes changes back (`npx comind push`).
4. The web low-code editor reflects the pushed changes.

This bidirectional sync means you can start in either mode and switch freely. See the [CLI reference](/developer-guide/reference/cli-reference.md) for the full list of available commands.

## 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 app code should be committed to your Git repository. The AppCode store on the server and the web UI editor are convenient for quick edits, but Git is the canonical version:

* Every change should end up in a Git commit
* If local code and AppCode diverge, the Git version wins
* Production deploys should come from committed code, not from ad-hoc pushes

This matters because Git gives you history, rollback, code review, and collaboration. AppCode does not.

### CLI commands: install vs push vs pull[​](#cli-commands-install-vs-push-vs-pull "Direct link to CLI commands: install vs push vs pull")

Three commands move code between your local machine and the server. Each serves a different purpose:

| Command              | Direction      | What it does                                                                              | When to use                                                                     |
| -------------------- | -------------- | ----------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- |
| `npx comind install` | Local → Server | Compiles the app and installs it on the target environment. Fast, direct deploy.          | Deploy a tested change to dev or prod                                           |
| `npx comind push`    | Local → Server | Uploads local source files to AppCode **without compiling**. Preserves server-side state. | Sync your code to the web editor for someone else to review or continue editing |
| `npx comind pull`    | Server → Local | Downloads AppCode source to your local project.                                           | Fetch changes made through the web UI editor before starting local work         |

When in doubt, use install

`install` is the most common command - it compiles and deploys in one step. Use `push` and `pull` only when you need to sync with the web-based AppCode editor.

### AppCode sync[​](#appcode-sync "Direct link to AppCode sync")

Comind.work also supports editing app source directly on the server. The AppCode store holds the uncompiled source - it is separate from the compiled deployment artifact.

<!-- -->

If another developer or admin edits the app through the web UI, those changes live in AppCode until you pull them. Always pull before starting local work to avoid conflicts.

## 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. They cannot be pulled with `npx comind pull`. 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