Configuration: Apps and Multi-App
Many "I made the right change but it's still hitting the wrong database" issues boil down to the App Code or current app not pointing where you think it does. This section lays out the app selection rules so you can troubleshoot quickly.
Three Core Concepts
App Code: Every application on the platform has a unique identifier. Nearly all CLI commands that read or write data target the "current app" by default.
Configuration file: The .rabetbase.json file in the project root should use apps + defaultApp for app profiles. The legacy top-level appcode form is still readable for compatibility. A global configuration file can also exist in the user's home directory. For precedence rules, see "Configuration Sources and Precedence" in the Command Reference.
Precedence: What Wins
The short version: CLI flags > currently selected app profile > top-level defaults in the config file.
Common patterns:
- Temporarily specify an App Code:
rabetbase ... --appcode <code> - Switch between apps in a multi-app setup:
rabetbase ... --app <app-name-from-config> - Persist the default app for the current workspace:
rabetbase workspace use --app <name>
This lets you hardcode parameters in scripts while keeping a single set of defaults in your local config file.
Single-App Mode (Most Common)
The simplest compatible form is a top-level appcode:
{
"appcode": "app-xxxx"
}
New writes are canonicalized to apps + defaultApp. When you omit --appcode, the CLI uses the currently selected default app.
Multi-App Mode (Multiple Lovrabet Apps in One Repository)
When a project maintains several apps -- say an "order" app and a "product" app -- use apps + defaultApp:
{
"defaultApp": "order",
"apps": {
"order": {
"appcode": "app-order-xxx",
"apiDir": "./apps/order/src/api"
},
"product": {
"appcode": "app-product-yyy"
}
},
"cookie": "",
"format": "pretty"
}
Top-level fields serve as shared defaults; each apps.<name> entry can override appcode, apiDir, cookie, and more.
Switch the default app (writes back to the config file):
rabetbase workspace use --app product
List all apps and see which one is the default:
rabetbase app list
Discover apps available to the current login on the platform:
rabetbase app list --remote
Running just rabetbase app shows the app service help. To list local apps, run rabetbase app list explicitly.
Add a new app:
rabetbase app add <name> --appcode <required-AppCode>
You can also pass --apiDir, --cookie, and so on.
Remove an app:
rabetbase app remove <name>
Managing Config via Commands (No Manual JSON Editing)
When run inside a project directory, these commands modify the project config. Outside a project, write commands fail and ask you to pass --global or initialize a project first:
rabetbase config set appcode app-xxxx
rabetbase config get appcode
rabetbase config list
Notes:
config set appcode app-xxxxis for single-app setup and writes the canonicalapps + defaultAppform.- If the project already uses multi-app config, use
rabetbase app add/rabetbase workspace use --app <name>instead.
This is convenient for quickly changing one or two values. For complex structures, directly editing the file or relying on version control is still recommended.
Risk Level (riskLevel)
You can set riskLevel in the configuration: read | write | high-risk-write. This controls which commands are allowed to run based on how dangerous they are. For example, setting it to read will reject any write commands. This is commonly used in team standards. For details on the field, see the Command Reference.
Summary
- Always confirm that App Code matches the task at hand.
- In multi-app setups, make it a habit to run
rabetbase app listto check the default, or explicitly specify with--app/--appcode. - If you need to discover apps on the platform, use
rabetbase app list --remote; do not use the removedrabetbase app remoteentry. - To switch the current workspace default app, use
rabetbase workspace use --app <name>; do not use the removedrabetbase app use <name>entry. - For the full precedence rules, see the Command Reference.
Next: Run development scripts in your project -- see Daily Development: Running Scripts and Debugging.