@nocobase/plugin-ai 2.1.0-beta.45 → 2.1.0-beta.47

package/dist/ai/docs/nocobase/api/cli/proxy/nginx/status.md

@@ -0,0 +1,36 @@
+---
+title: "nb proxy nginx status"
+description: "nb proxy nginx status command reference: show the current Nginx proxy runtime status."
+keywords: "nb proxy nginx status,NocoBase CLI,nginx,status"
+---
+
+# nb proxy nginx status
+
+Show the current Nginx proxy runtime status.
+
+## Usage
+
+```bash
+nb proxy nginx status
+```
+
+## Output
+
+The output usually includes:
+
+- `driver`
+- `status`
+- `config`
+- `nginx` or `container`
+
+## Examples
+
+```bash
+nb proxy nginx status
+```
+
+## Related commands
+
+- [`nb proxy nginx info`](./info.md)
+- [`nb proxy nginx start`](./start.md)
+- [`nb proxy nginx stop`](./stop.md)

package/dist/ai/docs/nocobase/api/cli/proxy/nginx/stop.md

@@ -0,0 +1,32 @@
+---
+title: "nb proxy nginx stop"
+description: "nb proxy nginx stop command reference: stop the Nginx proxy with the current driver."
+keywords: "nb proxy nginx stop,NocoBase CLI,nginx,stop"
+---
+
+# nb proxy nginx stop
+
+Stop the Nginx proxy with the current driver.
+
+## Usage
+
+```bash
+nb proxy nginx stop
+```
+
+## Examples
+
+```bash
+nb proxy nginx stop
+```
+
+## Notes
+
+- With the `local` driver, this stops the local Nginx process
+- With the `docker` driver, this stops the proxy container
+- If the proxy is already stopped, the command reports that it is already stopped
+
+## Related commands
+
+- [`nb proxy nginx start`](./start.md)
+- [`nb proxy nginx status`](./status.md)

package/dist/ai/docs/nocobase/api/cli/proxy/nginx/use.md

@@ -0,0 +1,38 @@
+---
+title: "nb proxy nginx use"
+description: "nb proxy nginx use command reference: switch the current driver for the Nginx provider."
+keywords: "nb proxy nginx use,NocoBase CLI,nginx,driver"
+---
+
+# nb proxy nginx use
+
+Switch the current driver for the Nginx provider.
+
+## Usage
+
+```bash
+nb proxy nginx use <driver>
+```
+
+## Parameters
+
+| Parameter | Type | Description |
+| --- | --- | --- |
+| `<driver>` | string | Supports `local` or `docker` |
+
+## Examples
+
+```bash
+nb proxy nginx use local
+nb proxy nginx use docker
+```
+
+## Notes
+
+- This command saves the result to `proxy.nginx-driver`
+- Later commands such as `start`, `reload`, `stop`, `status`, and `info` all use the current driver
+
+## Related commands
+
+- [`nb proxy nginx current`](./current.md)
+- [`nb proxy nginx start`](./start.md)

package/dist/ai/docs/nocobase/ops-management/version-control/index.md

@@ -0,0 +1,73 @@
+---
+title: "Version control"
+description: "Version control plugin guide: create versions, restore versions, configure retention, set shortcuts, and include user collections in saved versions."
+keywords: "Version control,ops management,create version,restore version,NocoBase"
+---
+
+# Version control
+
+In NocoBase, **Version control** lets you save a restorable version of the current application. You can create versions manually, restore the application to a saved version when needed, and use the plugin settings to control how many versions to keep, which shortcut to use, and which user collections should be saved with the version.
+
+It depends on [Backup manager](../backup-manager/index.mdx). If the Version control plugin is already enabled but the system still shows related errors, first make sure Backup manager is enabled.
+
+## Open the plugin
+
+You can open the plugin from 「System settings」 → 「Version control」. A Version control button also appears in the top bar. Click it to create a version directly or jump to the versions list. The default shortcut for creating a version is `Ctrl + K`, and you can change it in the settings tab.
+
+![](https://static-docs.nocobase.com/20260526220402.png)
+
+## Create a version
+
+Click 「Create version」, enter a description, and save it. The description can be up to 2000 characters. It is useful for recording the background of the change, such as “Adjusted approval fields and permissions”.
+
+![](https://static-docs.nocobase.com/20260526220510.png)
+
+After you click save, the list first shows a temporary “Saving” entry. When the task finishes, the saved version appears in the list.
+
+Key points:
+
+- Version names are generated automatically
+- Creating a version from the top bar, the shortcut, or the list page behaves the same
+- The list shows the version name, description, file size, creation time, creator, and available actions
+
+## Manage and restore versions
+
+The versions list mainly provides these actions:
+
+- 「Refresh」 reloads the current list
+- 「Delete」 removes one version, or multiple selected versions in batch
+- 「Restore」 restores the application to the state saved in that version
+
+:::warning Notice
+
+Restoring a version overwrites the current application configuration and the data included in that version. It is recommended to create a version of the current state before restoring, so you can roll back again if needed.
+
+:::
+
+After you click 「Restore」, the application enters maintenance mode for a short time while the restore is running. Do not submit another restore request during that time. If the restore fails, the UI shows an error notification.
+
+## Configure version rules
+
+Open the 「Settings」 tab to control retention and what each version includes.
+
+![](https://static-docs.nocobase.com/20260526220720.png)
+
+The settings include:
+
+- `Versions to keep`: the maximum number of saved versions. Older versions are deleted automatically after the limit is exceeded
+- `Shortcut: create version`: the shortcut for creating a version. Press `Ctrl + a letter key` to set it, or `Backspace` to clear it
+- `User collections`: choose which user-created collections should have their data included in saved versions
+
+:::tip
+
+By default, saved versions do not include data from user-created collections. You only need to select collections here when you want some business data to be restored together with the application version.
+
+:::
+
+If you include a user collection, NocoBase also includes related collections automatically, so restores are usually more complete.
+
+## Related links
+
+- [Backup manager](../backup-manager/index.mdx) — the underlying capability required by Version control
+- [Migration manager](../migration-manager/index.md) — move application configuration across environments
+- [Release management](../release-management/index.md) — plan release workflows with backups, migrations, and variables

package/dist/ai/docs/nocobase/quickstart/production/index.md

@@ -1,163 +1,169 @@
 ---
 title: "Production Deployment"
-description: "Deploy NocoBase in production with two final steps: enable app autostart and configure a reverse proxy."
-keywords: "NocoBase,production deployment,nb app autostart,nb env proxy,Nginx,Caddy"
+description: "Finish NocoBase production deployment quickly: configure app auto-start first, then configure a reverse proxy."
+keywords: "NocoBase,production deployment,nb app autostart,nb proxy nginx,nb proxy caddy,Nginx,Caddy"
 ---
 
 # Production Deployment
 
-If your NocoBase app is already running correctly on the server, production rollout usually only needs two more steps:
+If your NocoBase app can already run normally on the server, production rollout usually only needs two more things:
 
-1. Make sure the app starts automatically after the machine restarts
-2. Put a reverse proxy in front of the app for stable external access
+1. make sure the app can recover automatically after the machine restarts
+2. add a reverse-proxy entrypoint so the app can be accessed from outside reliably
 
-In the NocoBase CLI, the main commands are:
+In NocoBase CLI, the main command groups are:
 
 - `nb app autostart`
-- `nb env proxy`
+- `nb proxy`
 
-This page gives the overall path first. For Nginx or Caddy details, continue to the corresponding subpages.
+This page explains the overall path first. For Nginx or Caddy details, continue to the provider-specific pages.
 
-## Step 1: Enable App Autostart
+## Step 1: configure app auto-start
 
-In production, the first priority is not the domain name. The first priority is making sure the service can recover reliably after a reboot, container recreation, or routine maintenance.
+In production, the first priority is not the domain name. It is making sure the service itself can recover reliably. Otherwise, after a machine restart, container recreation, or routine operations work, the app may not come back automatically.
 
-In the CLI, `nb app autostart` is a command group. The most commonly used commands are:
+The most common `nb app autostart` subcommands are:
 
 - `nb app autostart enable`
 - `nb app autostart list`
 - `nb app autostart run`
 
-Enable autostart for the current env:
+Enable auto-start for the current env:
 
 ```bash
 nb app autostart enable
 ```
 
-If you want to target a different env explicitly:
+If the target is not the current env, specify it explicitly:
 
 ```bash
 nb app autostart enable --env app1 --yes
 ```
 
-Then check which envs are marked for autostart:
+Check which envs are marked for auto-start:
 
 ```bash
 nb app autostart list
 ```
 
-After the system boots, run the following command to start every env that has autostart enabled:
+After the system boots, start all enabled envs with:
 
 ```bash
 nb app autostart run
 ```
 
-If you want the underlying startup output for troubleshooting:
+If you want detailed startup output while debugging:
 
 ```bash
 nb app autostart run --verbose
 ```
 
-:::tip What this actually does
+:::tip What this step actually does
 
-`nb app autostart enable` marks a CLI-managed env as allowed to start automatically.  
-`nb app autostart run` is the command that actually starts all envs that were marked for autostart.
+`nb app autostart enable` marks a CLI-managed env as allowed to start automatically. `nb app autostart run` actually starts all envs that have auto-start enabled.
 
-In other words, in a real production setup you usually still need to wire `nb app autostart run` into your own system startup flow, such as `systemd`, a container platform startup script, or another host-level boot mechanism you already use.
+In production, you usually still need to connect `nb app autostart run` to your own system startup flow, such as `systemd`, a container platform startup script, or another host-level auto-start mechanism that you already use.
 
 :::
 
-### Scope
+### Applicability
 
-`nb app autostart` only applies to envs with a CLI-managed runtime on the current machine:
+`nb app autostart` only works for envs with a CLI-managed runtime:
 
 - `local`
 - `docker`
 
-If the env is only a remote API connection, or the app is not managed locally by the CLI on this machine, these commands are not the right tool for autostart.
+If an env is only a remote API connection, or the app is not managed locally by the CLI on the current machine, this command group is not the right way to handle auto-start.
 
-## Step 2: Configure a Reverse Proxy
+## Step 2: configure the reverse proxy
 
-Once the app can recover automatically, the next step is to handle the external entry point. In production, the reverse proxy usually takes care of:
+After the app can recover automatically, handle the external entrypoint. In production, the reverse proxy usually takes care of:
 
-- binding the domain name or public port
-- forwarding HTTP and WebSocket traffic to NocoBase
+- binding the domain name or entry port
+- forwarding HTTP and WebSocket requests to NocoBase
 - handling HTTPS, certificates, caching, or access control
 
-In the NocoBase CLI, the recommended entry points are:
+The recommended CLI entrypoints are:
 
-- `nb env proxy nginx`
-- `nb env proxy caddy`
+- `nb proxy nginx`
+- `nb proxy caddy`
 
-### Default Approach
+### Default workflow
 
-If your app is already saved as a CLI env and is a `local` or `docker` env, letting the CLI generate the proxy config is usually enough:
+If the app has already been saved as a CLI env and that env is `local` or `docker`, the usual path is to let the CLI generate the config directly:
 
 ```bash
-nb env proxy nginx --env app1 --host app.example.com
-nb env proxy caddy --env app1 --host app.example.com
+nb proxy nginx use docker
+nb proxy nginx generate --env app1 --host app.example.com
+
+nb proxy caddy use local
+nb proxy caddy generate --env app1 --host app.example.com
 ```
 
-If the current env is already the target env, you can omit `--env`:
+Then start the chosen provider:
 
 ```bash
-nb env proxy nginx --host app.example.com
+nb proxy nginx start
+nb proxy caddy start
 ```
 
-The CLI helps cover details that are easy to miss in handwritten configs, such as:
+The CLI also helps with details that are easy to miss in handwritten configs, such as:
 
 - WebSocket forwarding
-- entry and static asset paths for subpath deployments
+- entry and asset URLs under subpaths
 - SPA fallback pages
-- provider shared config files
-
-### When To Choose Nginx Or Caddy
+- provider-level shared config files
 
-You can usually decide like this:
+### When to choose Nginx or Caddy
 
-| Scenario | Recommended |
+| Scenario | Recommendation |
 | --- | --- |
-| You already use Nginx for sites, caching, certificates, or access control | [Nginx](./reverse-proxy/nginx.md) |
-| You already have a domain and want HTTPS working quickly with less TLS maintenance | [Caddy](./reverse-proxy/caddy.md) |
-| You want the overall explanation of this command group first | [Production Reverse Proxy](./reverse-proxy/index.md) |
+| You already use Nginx to manage sites, caching, certificates, or access control | [Nginx](./reverse-proxy/nginx.md) |
+| You already have a domain and want HTTPS up quickly with fewer TLS details to maintain | [Caddy](./reverse-proxy/caddy.md) |
+| You want the overall introduction first | [Reverse Proxy in Production](./reverse-proxy/index.md) |
 
-If you change env settings that affect the proxy result, such as `app-port` or `app-public-path`, remember to rerun the corresponding proxy subcommand.
+If you later change env settings such as `app-port` or `app-public-path` that affect proxy behavior, rerun the matching proxy subcommand.
 
-## Recommended Rollout Path
+## Default rollout path
 
-If you want the simplest production path, this order usually works well:
+For the simplest production rollout, this sequence is usually enough:
 
-1. Make sure the app can already start correctly on the server itself
-2. Run `nb app autostart enable`
-3. Add `nb app autostart run` to your system startup process
-4. Choose Nginx or Caddy and run the matching `nb env proxy` subcommand
-5. Verify external access through the final domain or public entry address
+1. confirm the app can already start normally on the server itself
+2. run `nb app autostart enable`
+3. connect `nb app autostart run` to your system startup flow
+4. choose Nginx or Caddy and run the matching `nb proxy` subcommand
+5. verify external access through the domain name or entry address
 
-## Quick Links
+## Quick index
 
-| I want to... | Read this |
+| I want to... | Go here |
 | --- | --- |
-| Start with the overall reverse proxy explanation | [Production Reverse Proxy](./reverse-proxy/index.md) |
-| Keep using Nginx for the entry layer | [Nginx](./reverse-proxy/nginx.md) |
-| Use Caddy for a faster HTTPS setup | [Caddy](./reverse-proxy/caddy.md) |
-| Manage start, stop, logs, and upgrades | [Manage Apps](../operations/manage-app.md) |
-| Read the `nb env proxy` CLI reference | [`nb env proxy`](../../api/cli/env/proxy/index.md) |
+| Read the overall reverse-proxy introduction first | [Reverse Proxy in Production](./reverse-proxy/index.md) |
+| Keep using Nginx at the entry layer | [Nginx](./reverse-proxy/nginx.md) |
+| Use Caddy to get HTTPS faster | [Caddy](./reverse-proxy/caddy.md) |
+| View app start, stop, logs, and upgrade operations | [Manage the App](../operations/manage-app.md) |
+| Read the `nb proxy nginx` CLI reference | [`nb proxy nginx`](../../api/cli/proxy/nginx/index.md) |
+| Read the `nb proxy caddy` CLI reference | [`nb proxy caddy`](../../api/cli/proxy/caddy/index.md) |
 
-## Related Commands
+## Related commands
 
 ```bash
-# Enable autostart for one env
+# Enable auto-start for one env
 nb app autostart enable --env app1 --yes
 
-# List autostart status
+# Check auto-start state
 nb app autostart list
 
-# Start all envs with autostart enabled
+# Start all enabled envs
 nb app autostart run
 
-# Generate Nginx reverse proxy config
-nb env proxy nginx --env app1 --host app.example.com
+# Choose the Nginx runtime and generate config
+nb proxy nginx use docker
+nb proxy nginx generate --env app1 --host app.example.com
+nb proxy nginx start
 
-# Generate Caddy reverse proxy config
-nb env proxy caddy --env app1 --host app.example.com
+# Choose the Caddy runtime and generate config
+nb proxy caddy use local
+nb proxy caddy generate --env app1 --host app.example.com
+nb proxy caddy start
 ```