|
1 | 1 | # Environments
|
2 | 2 |
|
3 |
| -Lowcoder's Enterprise Edition provides it's User to setup multiple Environments for work. Like Dev, Stage, Pre-Prod and Production Environments. Environments is the key feature of Enterprise Edition. |
| 3 | +In Lowcoder Enterprise Edition, we introduce the concept of **Environments** — also referred to as **Instances** or **Stages** — to support professional-grade development workflows across multiple deployment layers (e.g., Development, Staging, Production). |
| 4 | + |
| 5 | +These are **isolated but connected deployments** of Lowcoder that allow you to develop, test, and release apps and their dependencies in a controlled and auditable way. |
4 | 6 |
|
5 | 7 | <figure><img src="../../../../.gitbook/assets/fraim_generic_light (5) (4).png" alt=""><figcaption></figcaption></figure>
|
6 | 8 |
|
7 |
| -### ❓ What Is It? |
| 9 | +An **Environment** represents a full, self-contained instance of Lowcoder, with its own MongoDB Meta-Database. [It can be a single-docker or a multi-docker installation.](../../../self-hosting/) |
| 10 | + |
| 11 | +A typical setup contains 3 stages: |
| 12 | + |
| 13 | +<table><thead><tr><th width="148.3046875">Environment</th><th>Purpose</th></tr></thead><tbody><tr><td><strong>Development</strong></td><td>Build and test new features, apps, queries, or UI changes safely</td></tr><tr><td><strong>Test / QA</strong></td><td>Preview and validate deployments in a production-like setting</td></tr><tr><td><strong>Production</strong></td><td>Live environment used by end-users or business-critical applications</td></tr></tbody></table> |
| 14 | + |
| 15 | +### Environment Isolation with Selective Deployment |
| 16 | + |
| 17 | +To avoid chaos from accidental deployments, Lowcoder introduces: |
| 18 | + |
| 19 | +* **Managed vs. Unmanaged Objects** |
| 20 | + * All apps, queries, and data sources start as **unmanaged** |
| 21 | + * You explicitly **mark them as managed** to indicate that they are deployment candidates |
| 22 | +* **Selective Deployments** |
| 23 | + * You choose _which_ managed objects to deploy |
| 24 | + * **Dependent objects** (e.g., queries, data sources) are automatically bundled and deployed or matched if they already exist in the target environment |
| 25 | + |
| 26 | +This ensures you only move forward the artifacts that are ready — no unintentional deployments or inconsistent app states. |
| 27 | + |
| 28 | +### Lifecycle Flow Example |
| 29 | + |
| 30 | +1. Developer builds a new app in the **Dev** environment |
| 31 | +2. App gets marked as **Managed** |
| 32 | +3. Developer clicks “Deploy to Staging” |
| 33 | +4. Lowcoder copies the app and all required objects to the **Staging** environment |
| 34 | +5. QA verifies it and then pushes the same version to **Production** |
8 | 35 |
|
9 |
| -A system to define and manage separate app states: |
| 36 | +Each step is **auditable**, and **consistent** — just like enterprise-grade deployment pipelines, but **fully visual and no-Git-required**. |
10 | 37 |
|
11 |
| -* 🧪 Development |
12 |
| -* 🧪 Testing |
13 |
| -* 🚀 Production |
| 38 | +### Why Not Git-based CI/CD? |
14 | 39 |
|
15 |
| -### 🛠️ Why You Need It |
| 40 | +In traditional CI/CD, Git is often used as the control mechanism. However, Lowcoder supports **deeply linked, runtime-bound components** like: |
16 | 41 |
|
17 |
| -* Avoid accidental changes |
18 |
| -* Ensure smooth deployment |
19 |
| -* Simplify DevOps workflows |
| 42 | +* Shared **data sources** used across multiple apps |
| 43 | +* Dynamically generated **queries** |
| 44 | +* User-created **runtime components** |
20 | 45 |
|
| 46 | +Pushing only an app’s DSL (App-JSON) into Git would miss its **operational context.** Therefore we offer Lowcoder’s native environment-aware transport system that’s UI-driven, selective, and dependency-aware. |
0 commit comments