One config.json: 1010 methods, 16 deploy types, 72 plan rungs.
This page is about a file rather than a product. config.json is the platform manifest, and almost every question about what Xuda can do is answered by reading one key on it. The cpi_methods object holds 1010 entries, and a single name lookup into that object is the entire API surface: no route table, no generated client, no second place to register anything. 678 of those entries carry private: true, so an external API key can address 332 of them, and the MCP tool list is compiled from that same set. Five clearance strings cover the whole catalogue, user on 681 entries, admin on 253, public on 51, developer on 15 and user_access on 5. 880 entries declare typed fields, 2009 field definitions in total, 1103 of them mandatory, and 158 of the field keys are dotted paths such as data.create_datacenter.app_region. deploy_type lists 16 strings, and deploy_type_in_beta names four of them, router, android, emitter and mcp, which deploy_app refuses with code -2. PLAN_OBJ holds 72 priced rungs across 16 categories, and every one of the 16 ladders has a $0 rung. PRICE_OBJ.server_slugs holds 58 slugs, built from 5 server types crossed with 3 server groups. The modules map declares 45 names, and a module boots by name rather than by import: msg_broker joins XUDA_HOME/cpi with the module name at common/msg_broker.mjs line 43, inserting /node_modules/@xuda.io when is_debug is false, which in config.json it is. Every count on this page is true of the repo copy of config.json. config_dev.json disagrees with it in four places, and the callout at the end says exactly where.
Six surfaces, one config file behind all of them.
Studio, the workspace, plugins, the API, the marketplace and Slim are not six products with six backends. They are six views of the same 1010 entry object, and the keys on an entry decide which of them can reach it: private decides whether an external key sees it at all, clearance decides which credential is read, min_plan decides which membership rung is required, and microservice decides which module answers.
Where an app is authored and deployed. config.json declares 16 deploy types; deploy_type_in_beta names four of them, router, android, emitter and mcp, and deploy_app refuses each with code -2.
Open StudioOne of the 16 priced ladders in PLAN_OBJ, and one of only three named anywhere in cpi_methods. 8 rungs, from $0 to $230 a month.
See the workspaceHow a plugin is built, published and installed onto an app, and what it can call once it is there.
Read the plugin modelThe 332 entries an external key can address, out of the 1010 in cpi_methods. The private flag is the wall, and no key crosses it in any mode.
See the APIListing an app or a plugin so another account can install it, and what the approval gate checks before it is public.
Visit the marketplaceThe drop-in browser runtime: HTML-first authoring, reactive directives and structural tags, and the sandbox the plugin system is built on.
Read about SlimMethods declared in cpi_methods, one object, one lookup
Deploy types declared, four of them refused as beta
Priced plan rungs across 16 ladders, each with a $0 rung
Server slugs, 5 server types crossed with 3 server groups
Six catalogues sit in one file, and each one has a different reader.
There is no route table, no permissions file and no separate pricing service. config.json holds six objects that never reference each other, and each is read by one or two places in the tree. cpi_methods decides what is callable, deploy_type what can be started, PLAN_OBJ what a rung costs, PRICE_OBJ what a box or an add-on costs, modules which process boots, region_geo where a dot lands on a map. Read across each row for the reader that consumes it, then read the two dashed cards, which are the pairs that do not exist.
Sixteen priced ladders, and two of them can refuse a call.
PLAN_OBJ holds 72 priced rungs across 16 categories, and every one of the 16 opens at $0. What the table compares is not price, it is reach. Exactly two plan keys exist anywhere in cpi_methods: min_plan, on 30 of the 1010 entries, and min_support_plan, on 1. Both are read by the same four lines in http_module, isValidPlan, which returns true the moment min_plan is absent and otherwise compares two rank fields in PLAN_OBJ, once per request. Fourteen of the sixteen ladders, 61 rungs between them, cannot refuse a single call here. Read the third row first: it says which column has teeth.
Membership | AI Workspace | Support | The other 13 ladders | |
|---|---|---|---|---|
| Rungs | 7 | 8, the longest ladder in the file | 4 | 53 across 13 categories |
| Price spread | $0, $49, $149, $399, $1,999, $4,999, and a seventh whose price field is the literal string call rather than a number | $0 to $230 a month | $0, $100, $1,500, $4,500 | $0 up to $299, the top rung being trust_center Scale |
| Entries naming it as a floor | 30 of 1010, through min_plan: 19 pro, 6 agency, 4 team, 1 free | none. No entry names a workspace rung | exactly 1, the only min_support_plan in the file | none. No other plan key appears on any entry |
| What refuses you below it | isValidPlan, four lines of arithmetic in http_module, called once per request | nothing in this catalogue. Whatever gates a workspace tier is not the dispatcher | that single entry, and nothing else in the 1010 | nothing here. commerce, drive, email, tickets and trust_center gate no method in this catalogue |
Six pages: what you run something on, and what it costs.
This page argued the shape: one file decides everything, and most of it is decided by a key being present rather than by a rule being written. The six below are the specifics, and they split down the middle. The first three answer what you can start and where it runs: 16 deployment types, 17 geo keys, 58 server slugs. The last three answer what a rung costs and whether it can refuse anything: membership, which can, on 30 methods; AI Workspace, which cannot; and support, which can, on exactly one.
deploy_type names 16 strings and deploy_type_in_beta names 4 of the same 16, router, android, emitter and mcp, each refused by deploy_app with code -2. Alongside them sit the 21 deploy_ methods in cpi_methods and the 9 priced add-ons, $15 for a pwa or a preview, $75 for an emitter.
See the typesregion_geo holds 17 keys, each a latitude, a longitude and a display name: 9 city codes, 5 continental buckets and the 3 farm regions hel1, fsn1 and us1. Choosing one is a typed argument, not a setting: data.create_datacenter.app_region is one of the 158 dotted paths in the field contract.
Read the regionsPRICE_OBJ.server_slugs is a grid, not a list: 5 server_types, shared, optimized, performance, large and service, crossed with 3 server_group values, deployment, managed and vps. The slug decides what the box costs and nothing about what you may call: no server key appears on a cpi_methods entry.
Compare slugs$0, $49, $149, $399, $1,999, $4,999, and a seventh whose price field is the literal string call rather than a number. This is the one ladder that can refuse a call: 30 of the 1010 cpi_methods entries name a rung as min_plan, 19 pro, 6 agency, 4 team and 1 free.
Compare tiersFrom $0 to $230 a month, and at 8 rungs the longest ladder in PLAN_OBJ. No cpi_methods entry names a workspace rung as a floor, so nothing in the dispatcher refuses you for being on the wrong one. What the tier buys is decided elsewhere.
Read the ladder$0, $100, $1,500 and $4,500. Exactly one entry in cpi_methods names a min_support_plan, which makes this the second and last plan key the dispatcher reads, and the narrowest gate in the file: one method wide.
See support tiersEight things this page and this platform do not do, starting with two about this page.
- This page is an index and it stays one. Nine blocks against a sibling's twenty is not an omission: the page it replaced was two headings and a call to action, so it indexes the section rather than becoming one more essay about it. The explanation lives on the page each card points at.
- Every count on this page was read out of the repository copy of config.json on the day it was written, and that file moves. The shape of the file is the durable claim; the totals are a snapshot of one commit, and a number that has drifted is a bug in this page rather than a promise about the platform.
- Two thirds of the API is closed to you. 678 of the 1010 entries in cpi_methods carry private: true, and no API key crosses that flag in any mode. What an external caller can reach is 332 methods, and the MCP tool list is compiled from that same set. Only 10 entries set private: false explicitly, so what makes a method externally reachable is usually the absence of a key rather than a decision to open it.
- Sixteen priced ladders, and two of them gate anything here. PLAN_OBJ holds 72 priced rungs across 16 categories, while cpi_methods names exactly two plan keys: min_plan on 30 of the 1010 entries, 19 pro, 6 agency, 4 team and 1 free, and min_support_plan on exactly one. The other 14 ladders, commerce, drive, email, tickets and trust_center among them, gate nothing through this catalogue.
- Five deployment add-ons are priced with nothing behind them. PRICE_OBJ charges $45 each for android, ios, windows, linux and macos, and cpi_methods declares no deploy_ method that creates any of the five. Four of the nine priced add-ons have one. A price in the catalogue is not evidence that a method exists to buy against it.
- A quarter of the deployment type list cannot be started on the shipping config. deploy_type holds 16 strings, deploy_type_in_beta holds 4 of them, router, android, emitter and mcp, and deploy_app checks both lists and returns code -2 either way, at cpi/deploy_module/index.mjs lines 139 to 144. Those four are declared and refused by the same file.
- The shipping config and the dev config disagree about the platform. config_dev.json declares 1030 methods against 1010, adding 20 and removing none, and lists 17 deploy types against 16: it carries mpa and full_stack_vps where config.json carries router. It also routes 30 methods to ticket_module that config.json routes to support_module, which is declared in the modules map and has no source directory in cpi/ at all. The two configs disagree about who answers a ticket, and every count on this page is true of config.json rather than of every box.
- There is no rate limiter on /cpi. router_module proxies the cpi case straight to localhost:3007 with no middleware in front of it, at lines 2493 to 2521, while the three express-rate-limit buckets sit on /login, the public forms and the store routes. There is no failed-attempt lockout on the path either. Authenticated calls are bounded by credential scope, not by request rate.
Six questions a config file answers faster than a feature list
Each answer names the file and the count it came from, so you can open the repo and disagree with it.
A platform you can read is a platform you can argue with.
Every number on this page came out of two things you can open yourself: config.json and the cpi/ tree beside it. That is the honest version of a feature list and it is also the slow way in. If you arrived with a shape in mind instead, a form that has to submit somewhere, a file that has to land in storage, a project that has to sit in one region, the sibling page maps an arriving shape onto the method name that handles it, which is the job this hub is really here to do. Start there, then come back when you want to know what that method is allowed to do and who is allowed to call it.