|
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><imgsrc="../../../../.gitbook/assets/frame_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><thwidth="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 andmanage 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. |