21 deployment methods, and 10 of them carry your code.
A usage scenario on this platform is not a marketing category, it is a method name. config.json declares exactly 21 methods whose name begins with deploy_, config_dev.json declares the same 21, and every deployment shape Xuda offers is one of those entries. Ten of them ship a build of your project, and one field tells you which ten: they are the entries that take data.release_doc_id. The other eleven provision infrastructure or write a record. Those same ten all set req.data.deploy_type and hand off to a single shared function, deploy_app, which is itself not declared in cpi_methods, so there is no generic deploy call to make. You pick a front door by name, and the shared code behind it reads the type off the request. The plan floor is written on each entry rather than on a pricing page: deploy_mini_app is the only method in the whole 1010 entry catalogue carrying min_plan free, twelve deploy_ methods carry min_plan pro, two carry agency, and six carry no min_plan at all, which means everyone passes that gate. Counting the plan gate alone, 7 of the 21 are reachable on Free, 19 on Pro, 19 on Team and 21 on Agency, against membership prices of $0, $49, $149 and $399 a month. This page walks the eight patterns people actually arrive with, names the method each one resolves to, and names the ones that resolve to nothing.
The scenario you arrived with, and the method it resolves to.
People do not arrive asking for deploy_spa. They arrive with a shape in mind: an app for customers, a site with no code behind it, a job that runs at three in the morning, a copy to test against. Each of those resolves to one or two named entries in cpi_methods, and the resolution is fixed at call time rather than chosen at runtime. Read each row as one alternative and the chips beside it as the calls it actually costs you.
Methods whose name starts with deploy_
Of those reachable on a Free account
Pro gated methods in the catalogue that are deployments
Deployment methods gated on Team
What a deploy call asks you for, and what it does with the answer.
The 21 entries do not share a signature, but four fields on the declaration tell you almost everything about a given one before you open its handler: whether it takes a release id, whether it takes a region, whether it runs as a tracked job, and which script that job runs. Two more decide who may call it at all. 14 of the 21 require clearance admin and 7 require clearance user, and 20 of the 21 carry private: true, the flag that no external API key crosses in any mode. Deployment is an operator action taken from a logged in session, not something an integration fires.
- A release id, or nothing. 10 of the 21 take data.release_doc_id, and those are exactly the ten that ship a build of your project. Six of them bind to one Studio program through a mandatory data.prog_id: embed, mini_app, preview, pwa, spa and user_group. deploy_mpa takes data.route_id instead. The other eleven methods provision infrastructure or write a record and never touch a build.
- A region, usually. 16 of the 21 accept a region. The five that do not are instance, marketplace, mini_app, site and static_website. Two of those write a document in xuda_master and provision no server, two publish files to storage, and the fifth is the free deployment, which accepts no region and no create_datacenter fields at all.
- A job, usually. 14 of the 21 run as a tracked job with a job_timeout of 1800000 ms, which is 30 minutes, and report progress through their declared job_steps. The other seven return without a job: another, datacenter, instance, marketplace, site, static_website and xucode. A call that comes straight back is doing paperwork, not provisioning.
- One script, nine times. api, cron, embed, emitter, mpa, preview, pwa, spa and user_group run an identical 12 step script with the type name substituted: initiating process, then create, firewall, backup plan, connect and install for the datacenter server, then those same five for the deployment server, then activating the server. One call therefore creates two servers, not one, unless you pass data.app_datacenter to reuse a datacenter you already have. That field is optional, and so are the create_datacenter fields beside it.
Four prices, and only two of them change what you can deploy.
The plan gate is four lines of arithmetic. isValidPlan at cpi/http_module/index.mjs lines 542 to 547 reads min_plan off the config entry, returns true when the key is absent, and otherwise compares two ranks in PLAN_OBJ: free 0, pro 1, team 2, agency 3. Applied to the 21 deploy_* methods, that is the whole table. The catalogue has 19 pro-gated methods and 12 of them are deploy_*, so a Pro membership spends most of itself right here. And exactly one method in all 1010 entries carries min_plan free, deploy_mini_app, the single deployment a free account can start. Prices are per month.
Free, $0 | Pro, $49 | Team, $149 | Agency, $399 | |
|---|---|---|---|---|
| deploy_* methods past the plan gate | 7 of 21 | 19 of 21 | 19 of 21 | 21 of 21 |
| What this tier adds over the one below it | the 6 methods that declare no min_plan at all, plus deploy_mini_app | 12: another, api, cron, datacenter, embed, emitter, load_balancer, mpa, preview, pwa, spa, user_group | nothing. Not one deploy_* method carries min_plan team | two: deploy_instance and deploy_marketplace, and both write a document in xuda_master without provisioning a server |
| Deployments carrying a build of your project, the ones taking data.release_doc_id | 1 of 10, deploy_mini_app | 10 of 10 | 10 of 10 | 10 of 10 |
| A link you hand out: spa, pwa, embed, preview | no, all four are pro | yes, a 12 step job each | same 4 as Pro | same 4 as Pro |
| A VPS, a webserver, or a full stack VPS with the xuda CLI on it | yes, all three declare no min_plan | yes | yes | yes |
| haproxy in front of your same-type deployments | no | deploy_load_balancer, 6 steps | yes | yes |
| A second environment of an app you already run | no | deploy_another, new name, region and server type | yes | yes |
One deploy call, three destinations, and the first one builds two servers.
Ten of the 21 methods deploy a build of your project. They are the ones taking data.release_doc_id, they each set req.data.deploy_type, and they all hand off to one shared function, deploy_app, at cpi/deploy_module/index.mjs line 116. deploy_app is not itself declared in cpi_methods, so there is no generic deploy call: you pick a front door and the front door names the type. The other 11 provision a machine or write a record. Read the first branch twice, because a single deploy_spa call provisions a datacenter server before it provisions yours.
Three moves, and the middle one is a progress bar you watch.
Not a wizard. What the config entry makes you supply, what the job reports back, and what you hold when the last line reads activating the server.
- 01
Choose the front door, the release and the program
There is no generic deploy call. deploy_app is shared by all 10 release methods but is not declared in cpi_methods, so you call deploy_spa, deploy_pwa, deploy_embed, deploy_preview and so on, and that choice sets deploy_type for you. Each of the 10 takes data.release_doc_id, the build being shipped. Six of them, embed, mini_app, preview, pwa, spa and user_group, also take a mandatory data.prog_id naming the one Studio program the deployment binds to, and deploy_mpa takes data.route_id in its place. Region is a field on 16 of the 21.
- 02
Watch the declared script run
job_steps is not an internal state machine, it is the literal progress text. 14 of the 21 register a tracked job with job_timeout 1800000 ms, a 30 minute ceiling. A link deployment reports 12 lines, deploy_mini_app 11, deploy_full_stack_vps 8, deploy_vps and deploy_webserver 7 each, deploy_load_balancer 6. The other 7 declare no steps and answer without a job: another, datacenter, instance, marketplace, site, static_website and xucode.
- 03
Take the activated server
The last step on every provisioning script is activating the server, and what you hold after it is a machine with the region, firewall and backup plan the same script set. From there deploy_load_balancer puts haproxy in front of several same-type deployments with health checks and failover, and deploy_another re-deploys the whole app under a new name, region and server type, cascading to its child deployments. Both are min_plan pro.
Twelve lines, and six of them are a machine you never named.
The job_steps array of deploy_spa in order, exactly as config.json declares it and as the progress bar reads it back. The same 12 lines, with the type name substituted, are declared on deploy_api, deploy_cron, deploy_embed, deploy_emitter, deploy_mpa, deploy_preview, deploy_pwa and deploy_user_group. Read lines 02 to 06 first: they are a datacenter server.
Eight limits, three of them methods that are declared and still refuse to run.
- Router does not deploy. deploy_mpa is declared, plan gated at pro, and sets req.data.deploy_type to mpa, a value absent from the deploy_type array in config.json, so deploy_app refuses it with code -2 at cpi/deploy_module/index.mjs lines 139 to 141. config_dev.json does list mpa, and lists it as beta as well, so it is refused four lines later instead. A multi page router deployment is not something you can start today.
- Emitter is beta in the shipping config. The string emitter sits in deploy_type_in_beta in config.json, so deploy_app returns code -2 at cpi/deploy_module/index.mjs lines 143 to 144. config_dev.json has dropped it from that list, which means the change feed pattern runs on dev and refuses on the repo copy. The method is declared and the provisioning pipeline behind it is the same one cron uses. The gate is one array entry.
- No method builds an iOS, Android or macOS binary. deploy_ios, deploy_android and deploy_macos exist in cpi/deploy_module/index.mjs at lines 1388 to 1405, and not one of the three is declared in cpi_methods, so nothing arriving over /cpi can reach them. The old mobile app pattern is dropped rather than deferred.
- There is no real time collaboration deployment type. None of the 21 provisions a websocket, a presence channel or a CRDT surface. The closest thing in the set, deploy_emitter, is server side batch work triggered by a database change feed, and it is refused as beta anyway.
- MCP Server is listed as a deploy type in both configs, sits in deploy_type_in_beta in both, and has no deploy_mcp entry in cpi_methods at all, so there is nothing to call even before the beta gate. A per project MCP deployment does not exist.
- Team costs $149 against Pro at $49 and buys nothing on this page. Zero deploy_ methods carry min_plan team, so Pro and Team both reach 19 of the 21. Agency at $399 adds exactly two more, deploy_instance and deploy_marketplace, and both create a document in xuda_master and provision no server.
- deploy_xucode is the one deploy_ entry with no microservice key, and http_module returns early on a missing microservice at cpi/http_module/index.mjs lines 942 to 944, so the call never reaches its handler at cpi/deploy_module/index.mjs line 1777. It is also the only one of the 21 that omits private.
- A static website deployment runs no code. deploy_static_website reads a drive folder and hands it to deploy_site, which uploads the files to R2 and flips a KV pointer atomically. No server, no cron, no API, no database. A form handler or a scheduled job is a second deployment on a second server.
What is actually deployable today
Six answers read off config.json and cpi/deploy_module/index.mjs rather than off the wizard that sits on top of them.
Watch a deployment go out.
Twelve steps, two servers and one job id with a 30 minute timeout on it. The same script nine of the 21 methods run, with the type name substituted.
Read the method declaration before you pick the tier.
Each of the 21 deploy_ entries carries its own contract in config.json: the typed fields it accepts, whether it takes a release_doc_id, the job steps it will walk and the timeout on them, the clearance it wants, and the min_plan floor under it. That entry is the agreement, not the wizard drawn over it. Work out which shape you are actually deploying, read that one entry, then buy the tier its min_plan names. Six of the 21 name no plan at all, one names free, twelve name pro, two name agency, and not a single deployment anywhere names team.