Rabetbase CLI Region Configuration

**Recommended:** First-time setup: run `rabetbase config init` and select the official region via the prompt. Only modify Domain fields in `.rabetbase.json` when deploying enterprise self-hosted instances or overriding individual services.

This document covers Rabetbase CLI connection configuration: how to use interactive config init to select the Mainland China or Indonesia endpoint, and how to manually edit .rabetbase.json to support enterprise self-hosted deployments.

Initial Setup: Follow the Prompt

Run in any directory:

rabetbase config init

CLI will show Select Lovrabet region. Use arrow keys to choose:

• Mainland China (cn): Mainland China endpoint, also the default.
• Indonesia (id): Indonesia endpoint.

After confirmation, CLI writes the connection config to the global file ~/.rabetbase.json. It only updates region and Domain routing — it doesn't clear Cookie, output format, or app binding.

Selection	Config File Result	Notes
Mainland China cn	Usually no region saved	cn is the default. Omitting the field maintains backward compatibility and reduces unnecessary config.
Indonesia id	"region": "id"	CLI resolves the full set of *.lovrabet.id official addresses based on id.

Automated or Script Usage

Pass arguments directly when no prompt is needed:

rabetbase config init --region cn
rabetbase config init --region id

Currently only cn and id are allowed for new initialization. Legacy value global is kept for backward compatibility and won't appear in the prompt.

Where is the Config File?

Scope	File	Purpose
Global config	~/.rabetbase.json	Machine-wide default region, Domain, auth, and output preferences. Written by config init.
Project config	Project root/.rabetbase.json	Only affects the current project; same-named fields override global config.

Rabetbase CLI only reads .rabetbase.json, not Lovrabet Runtime CLI's .lovrabet.json. When editing manually, use valid JSON: field names and strings must use double quotes, no comments or trailing commas.

Direct JSON Edit for Official Endpoints

Mainland China is the default. The minimal config can omit region entirely:

{
  "accessKey": "<redacted>"
}

Indonesia endpoint:

{
  "region": "id",
  "accessKey": "<redacted>"
}

region resolves six official addresses at once: userDomain, apiDomain, runtimeDomain, skillDomain, kbDomain, and appDomain. Users only need to select the country/region; no need to understand internal address mappings.

Enterprise Self-Hosted: Configure Domain

Enterprise deployments can either override only the services actually self-hosted, or configure all six Domain fields. Official fields:

Field	Handles
userDomain	Browser login and user session services
apiDomain	Main development API: apps, datasets, pages, SQL, BFF, and management capabilities
runtimeDomain	Development workflow calls to runtime data, SQL execution, and BFF-related capabilities
skillDomain	SkillHub standalone routing; main Rabetbase CLI development commands don't depend on it currently
kbDomain	Development knowledge base interfaces; when not separately configured, follows explicit apiDomain
appDomain	Workbench, editor, and page links; this is the frontend site address, not a backend API

Full Self-Hosted Example

{
  "userDomain": "https://user.example.com",
  "apiDomain": "https://api.example.com",
  "runtimeDomain": "https://runtime.example.com",
  "skillDomain": "https://skills.example.com",
  "kbDomain": "https://kb.example.com",
  "appDomain": "https://app.example.com"
}

Override Partial Services

For example, if an enterprise only self-hosts the development API and Runtime:

{
  "apiDomain": "https://api.example.com",
  "runtimeDomain": "https://runtime.example.com"
}

kbDomain follows explicit apiDomain in this case. Unconfigured userDomain, skillDomain, and appDomain continue using the current region's official addresses.

Keep Official Endpoints, Override One Service

When editing JSON manually, you can keep region and override a single Domain:

{
  "region": "id",
  "kbDomain": "https://kb.customer.example.com"
}

This means all services except knowledge base use the Indonesia endpoint. This hybrid approach suits gradual self-hosted deployments.

Import via Domain JSON

Deployment programs can also generate a standalone file and import it at once:

rabetbase config init --domain-config ./rabetbase-domains.json

When using --domain-config, CLI switches to self-hosted mode: clears the original region and old Domain fields, then writes the official Domains from the file. Don't pass --region at the same time; the two modes are mutually exclusive.

WARNING

Custom Domain must be a trusted HTTPS origin, e.g., https://api.example.com. It cannot contain paths, query parameters, credentials, or business routes. CLI sends credentials to the corresponding service.

Verification After Changes

1. Save .rabetbase.json.
2. Run rabetbase doctor.
3. Verify the displayed region and six final Domains.
4. Execute a read-only command to verify the target service; don't test connections with write commands.

FAQ

Why can't I see region after running config init --region cn? Because cn is the default; CLI removes redundant fields as a forward-compatibility design.

Why doesn't the global config change when I modify Domain in the project? Project-level .rabetbase.json only affects the current project. To modify the machine-wide default, edit ~/.rabetbase.json, or use config write commands with --global.

Can I use different enterprise environments for different projects? Yes. Write each environment's Domains into the corresponding project's .rabetbase.json. Project-level fields override the global defaults.

Can I still write old fields like agentDomain or platformDomain? They are only kept for backward compatibility. New config should only use the six official fields listed in this document; don't mix old and new fields.

---

Applicable version: Verified against Rabetbase CLI main branch as of 2026-08-22.