App lifecycle

Every Comindwork 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

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

Comindwork 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 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 for the full list of available commands.

DevOps lifecycle

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

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

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

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.

App settings levels

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

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)

• 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)

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

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.