Sibling skills (local only)
Sibling CloudBase skills ship beside this skill. Use local relative paths such as ../auth-tool-cloudbase/SKILL.md.
If a referenced sibling skill file is missing from this environment, ask the user to install the full CloudBase plugin (or the missing skill). Do not HTTP-fetch remote skill or protocol markdown into the agent context.
CloudBase Run Development
Activation Contract
Use this first when
- The task is to initialize, run, deploy, inspect, or debug a CloudBase Run service.
- The request needs a long-lived HTTP service, SSE, WebSocket, custom system dependencies, or container-style deployment.
- The task is to create or run an Agent service on CloudBase Run.
- The task migrates an existing / GitHub / third-party backend that uses classic
DATABASE_URL / TCP database clients.
Read before writing code if
- You still need to choose between Function mode and Container mode.
- The prompt mentions
queryCloudRun, manageCloudRun, Dockerfile, service domains, or public/private access.
- The app depends on MySQL, PostgreSQL, Redis, or other VPC-private resources over TCP → also read
references/vpc-and-database.md.
Then also read
- Cloud functions instead of CloudRun ->
../cloud-functions/SKILL.md
- Agent SDK and AG-UI specifics ->
../cloudbase-agent/SKILL.md
- Web authentication for browser callers ->
../auth-web-cloudbase/SKILL.md
- Existing app + TCP database networking ->
references/vpc-and-database.md
Do NOT use for
- Simple Event Function or HTTP Function workflows that fit the function model better.
- Frontend-only projects with no backend service.
- Database-schema design tasks.
Common mistakes / gotchas
- Choosing CloudRun when the request only needs a normal cloud function.
- Forgetting to listen on the platform-provided
PORT.
- Treating CloudRun as stateful app hosting and storing important state on local disk.
- Assuming local run is available for Container mode.
- Opening public access by default when the scenario only needs private or mini-program internal access.
- Deploying an existing app with
DATABASE_URL / MySQL / PostgreSQL / Redis but omitting serverConfig.VpcConf — deploy appears to succeed, then runtime DB connections fail.
- Confusing
OpenAccessTypes (how users reach the service) with VpcConf (how the service reaches VPC databases).
Minimal checklist
- Choose Function mode or Container mode explicitly.
- Confirm whether the service should be public, VPC-only, or mini-program internal (ingress).
- If the app uses TCP databases/caches, resolve and set
VpcConf (egress / private network) before deploy — see references/vpc-and-database.md.
- Keep the service stateless and externalize durable data.
- Use absolute paths for every local project path.
Overview
Use CloudBase Run when the task needs a deployed backend service rather than a short-lived serverless function.
When CloudRun is a better fit
- Long connections: WebSocket, SSE, server push
- Long-running request handling or persistent service processes
- Custom runtime environments or system libraries
- Arbitrary languages or frameworks
- Stable external service endpoints with elastic scaling
- AI Agent deployment on Function mode CloudRun
- Migrating existing containerized or multi-language apps that need VPC access to databases
Mode selection
| Dimension |
Function mode |
Container mode |
| Best for |
Fast start, Node.js service patterns, built-in framework, Agent flows |
Existing containers, arbitrary runtimes, custom system dependencies |
| Port model |
Framework-managed local mode, deployed service still follows platform rules |
App must listen on injected PORT |
| Dockerfile |
Not required |
Required |
| Local run through tools |
Supported |
Not supported |
| Typical use |
Streaming APIs, low-latency backend, Agent service |
Custom language stack, migrated container app |
How to use this skill (for a coding agent)
Choose mode first
- Function mode -> quickest path for HTTP/SSE/WebSocket or Agent scenarios
- Container mode -> use when Docker/custom runtime is a real requirement
Follow mandatory runtime rules
- Listen on
PORT
- Keep the service stateless
- Put durable data in DB/storage/cache
- Keep dependencies and image size small
- Respect resource ratio guidance:
Mem = 2 × CPU
Use the correct tools
- Read operations ->
queryCloudRun
- Write operations ->
manageCloudRun
- Delete requires explicit confirmation and
force: true
- Always use absolute
targetPath
Follow the deployment sequence
- Initialize or download code
- For Container mode, verify Dockerfile
- Scan for DB/cache dependency signals (
DATABASE_URL, docker-compose DB services, ORM configs)
- If TCP DB access is required, complete the VPC checklist in
references/vpc-and-database.md before deploy
- Local run when available
- Configure ingress access model and egress
VpcConf when needed
- Deploy and verify detail output + DB connectivity
Tool routing
Read operations
queryCloudRun(action="list") -> list services
queryCloudRun(action="detail") -> inspect one service and its latest deploy status when available
queryCloudRun(action="templates") -> see available starters
queryCloudRun(action="getDeployLog") -> retrieve the latest deploy log or a specified buildId
Write operations
manageCloudRun(action="init") -> create local project
manageCloudRun(action="download") -> pull remote code
manageCloudRun(action="run") -> local run for Function mode
manageCloudRun(action="deploy") -> deploy local project (existing services: RMW preserves remote VpcConf / EnvParams keys / OpenAccessTypes)
manageCloudRun(action="updateConfig") -> config-only update (no code upload; VPC / EnvParams / scaling / access types)
manageCloudRun(action="delete") -> delete service
manageCloudRun(action="createAgent") -> create Agent service
Access guidance
- Web/public scenarios -> enable PUBLIC ingress intentionally and pair it with the right auth flow.
- Mini Program -> prefer internal direct connection and avoid unnecessary public exposure.
- Private ingress scenarios -> keep public access off unless the product requirement clearly needs it.
- Database / Redis in a VPC -> this is not solved by
OpenAccessTypes. You must set serverConfig.VpcConf and use the database private address. Read references/vpc-and-database.md.
Quick examples
Initialize
{ "action": "init", "serverName": "my-svc", "targetPath": "/abs/ws/my-svc" }
Local run (Function mode)
{ "action": "run", "serverName": "my-svc", "targetPath": "/abs/ws/my-svc", "runOptions": { "port": 3000 } }
Deploy (no VPC-private dependencies)
{
"action": "deploy",
"serverName": "my-svc",
"targetPath": "/abs/ws/my-svc",
"serverConfig": {
"OpenAccessTypes": ["PUBLIC"],
"Cpu": 0.5,
"Mem": 1,
"MinNum": 1,
"MaxNum": 5
}
}
Deploy (existing app that connects to MySQL / PostgreSQL / Redis over TCP)
{
"action": "deploy",
"serverName": "my-existing-app",
"targetPath": "/abs/ws/my-existing-app",
"serverConfig": {
"OpenAccessTypes": ["PUBLIC"],
"Cpu": 0.5,
"Mem": 1,
"MinNum": 1,
"MaxNum": 5,
"EnvParams": "{\"DATABASE_URL\":\"postgres://user:pass@10.x.x.x:5432/app\"}",
"VpcConf": {
"VpcId": "vpc-xxxxxxxx",
"SubnetId": "subnet-xxxxxxxx"
}
}
}
Valid OpenAccessTypes values: OA (办公网访问), PUBLIC (公网访问), MINIAPP (小程序访问), VPC (VPC访问). Use PUBLIC for web applications that need public HTTPS access.
MinNum: 1 is the recommended default when you want to reduce cold-start latency. If the user explicitly prefers lower cost and accepts more cold starts, explain the tradeoff and let them reduce MinNum to 0.
Best practices
- Prefer PRIVATE/VPC or mini-program internal ingress when possible.
- For TCP database access, always pair private DB URLs with
VpcConf in the same VPC/region as the database.
- Use environment variables for secrets and per-environment configuration.
- Verify configuration before and after deployment with
queryCloudRun(action="detail").
- Keep startup work small to reduce cold-start impact.
- For Agent scenarios, use the Agent SDK skill for protocol and adapter details instead of duplicating them here.
Troubleshooting hints
- Access failure -> check ingress access type, domain setup, and whether the instance scaled to zero.
- Deployment failure -> inspect Dockerfile, build logs, and CPU/memory ratio.
- Local run failure -> remember only Function mode is supported by local-run tools.
- Performance issues -> reduce dependencies, optimize initialization, and tune minimum instances.
- DB / Redis connection failure after a successful deploy -> almost always missing or wrong
VpcConf, wrong private host, or security group. Follow references/vpc-and-database.md before rewriting application code.
Reference index
All packaged reference files (required for skill lint reachability):
1---2name: cloudrun-development3description: CloudBase Run backend development rules (Function mode/Container mode). Use this skill when deploying backend services that require long connections, multi-language support, custom environments, AI agent development, or migrating existing/GitHub apps that need VPC access to MySQL/PostgreSQL/Redis.4---5
6## Sibling skills (local only)
7
8Sibling CloudBase skills ship beside this skill. Use local relative paths such as `../auth-tool-cloudbase/SKILL.md`.
9
10If a referenced sibling skill file is missing from this environment, ask the user to install the full CloudBase plugin (or the missing skill). Do **not** HTTP-fetch remote skill or protocol markdown into the agent context.
11
12# CloudBase Run Development
13
14## Activation Contract
15
16### Use this first when
17
18- The task is to initialize, run, deploy, inspect, or debug a CloudBase Run service.
19- The request needs a long-lived HTTP service, SSE, WebSocket, custom system dependencies, or container-style deployment.
20- The task is to create or run an Agent service on CloudBase Run.
21- The task migrates an **existing / GitHub / third-party** backend that uses classic `DATABASE_URL` / TCP database clients.
22
23### Read before writing code if
24
25- You still need to choose between Function mode and Container mode.
26- The prompt mentions `queryCloudRun`, `manageCloudRun`, Dockerfile, service domains, or public/private access.
27- The app depends on MySQL, PostgreSQL, Redis, or other VPC-private resources over TCP → also read `references/vpc-and-database.md`.
28
29### Then also read
30
31- Cloud functions instead of CloudRun -> `../cloud-functions/SKILL.md`
32- Agent SDK and AG-UI specifics -> `../cloudbase-agent/SKILL.md`
33- Web authentication for browser callers -> `../auth-web-cloudbase/SKILL.md`
34- Existing app + TCP database networking -> `references/vpc-and-database.md`
35
36### Do NOT use for
37
38- Simple Event Function or HTTP Function workflows that fit the function model better.
39- Frontend-only projects with no backend service.
40- Database-schema design tasks.
41
42### Common mistakes / gotchas
43
44- Choosing CloudRun when the request only needs a normal cloud function.
45- Forgetting to listen on the platform-provided `PORT`.
46- Treating CloudRun as stateful app hosting and storing important state on local disk.
47- Assuming local run is available for Container mode.
48- Opening public access by default when the scenario only needs private or mini-program internal access.
49- **Deploying an existing app with `DATABASE_URL` / MySQL / PostgreSQL / Redis but omitting `serverConfig.VpcConf`** — deploy appears to succeed, then runtime DB connections fail.
50- Confusing `OpenAccessTypes` (how users reach the service) with `VpcConf` (how the service reaches VPC databases).
51
52### Minimal checklist
53
54- Choose Function mode or Container mode explicitly.
55- Confirm whether the service should be public, VPC-only, or mini-program internal (**ingress**).
56- If the app uses TCP databases/caches, resolve and set `VpcConf` (**egress / private network**) before deploy — see `references/vpc-and-database.md`.
57- Keep the service stateless and externalize durable data.
58- Use absolute paths for every local project path.
59
60## Overview
61
62Use CloudBase Run when the task needs a deployed backend service rather than a short-lived serverless function.
63
64### When CloudRun is a better fit
65
66- Long connections: WebSocket, SSE, server push
67- Long-running request handling or persistent service processes
68- Custom runtime environments or system libraries
69- Arbitrary languages or frameworks
70- Stable external service endpoints with elastic scaling
71- AI Agent deployment on Function mode CloudRun
72- Migrating existing containerized or multi-language apps that need VPC access to databases
73
74## Mode selection
75
76| Dimension | Function mode | Container mode |
77| --- | --- | --- |
78| Best for | Fast start, Node.js service patterns, built-in framework, Agent flows | Existing containers, arbitrary runtimes, custom system dependencies |
79| Port model | Framework-managed local mode, deployed service still follows platform rules | App must listen on injected `PORT` |
80| Dockerfile | Not required | Required |
81| Local run through tools | Supported | Not supported |
82| Typical use | Streaming APIs, low-latency backend, Agent service | Custom language stack, migrated container app |
83
84## How to use this skill (for a coding agent)
85
861. **Choose mode first**
87 - Function mode -> quickest path for HTTP/SSE/WebSocket or Agent scenarios
88 - Container mode -> use when Docker/custom runtime is a real requirement
89
902. **Follow mandatory runtime rules**
91 - Listen on `PORT`
92 - Keep the service stateless
93 - Put durable data in DB/storage/cache
94 - Keep dependencies and image size small
95 - Respect resource ratio guidance: `Mem = 2 × CPU`
96
973. **Use the correct tools**
98 - Read operations -> `queryCloudRun`
99 - Write operations -> `manageCloudRun`
100 - Delete requires explicit confirmation and `force: true`
101 - Always use absolute `targetPath`
102
1034. **Follow the deployment sequence**
104 - Initialize or download code
105 - For Container mode, verify Dockerfile
106 - **Scan for DB/cache dependency signals** (`DATABASE_URL`, docker-compose DB services, ORM configs)
107 - If TCP DB access is required, complete the VPC checklist in `references/vpc-and-database.md` **before** deploy
108 - Local run when available
109 - Configure ingress access model **and** egress `VpcConf` when needed
110 - Deploy and verify detail output + DB connectivity
111
112## Tool routing
113
114### Read operations
115
116- `queryCloudRun(action="list")` -> list services
117- `queryCloudRun(action="detail")` -> inspect one service and its latest deploy status when available
118- `queryCloudRun(action="templates")` -> see available starters
119- `queryCloudRun(action="getDeployLog")` -> retrieve the latest deploy log or a specified `buildId`
120
121### Write operations
122
123- `manageCloudRun(action="init")` -> create local project
124- `manageCloudRun(action="download")` -> pull remote code
125- `manageCloudRun(action="run")` -> local run for Function mode
126- `manageCloudRun(action="deploy")` -> deploy local project (existing services: RMW preserves remote VpcConf / EnvParams keys / OpenAccessTypes)
127- `manageCloudRun(action="updateConfig")` -> config-only update (no code upload; VPC / EnvParams / scaling / access types)
128- `manageCloudRun(action="delete")` -> delete service
129- `manageCloudRun(action="createAgent")` -> create Agent service
130
131## Access guidance
132
133- **Web/public scenarios** -> enable PUBLIC ingress intentionally and pair it with the right auth flow.
134- **Mini Program** -> prefer internal direct connection and avoid unnecessary public exposure.
135- **Private ingress scenarios** -> keep public access off unless the product requirement clearly needs it.
136- **Database / Redis in a VPC** -> this is **not** solved by `OpenAccessTypes`. You must set `serverConfig.VpcConf` and use the database private address. Read `references/vpc-and-database.md`.
137
138## Quick examples
139
140### Initialize
141
142```json
143{ "action": "init", "serverName": "my-svc", "targetPath": "/abs/ws/my-svc" }
144```
145
146### Local run (Function mode)
147
148```json
149{ "action": "run", "serverName": "my-svc", "targetPath": "/abs/ws/my-svc", "runOptions": { "port": 3000 } }
150```
151
152### Deploy (no VPC-private dependencies)
153
154```json
155{
156 "action": "deploy",
157 "serverName": "my-svc",
158 "targetPath": "/abs/ws/my-svc",
159 "serverConfig": {
160 "OpenAccessTypes": ["PUBLIC"],
161 "Cpu": 0.5,
162 "Mem": 1,
163 "MinNum": 1,
164 "MaxNum": 5
165 }
166}
167```
168
169### Deploy (existing app that connects to MySQL / PostgreSQL / Redis over TCP)
170
171```json
172{
173 "action": "deploy",
174 "serverName": "my-existing-app",
175 "targetPath": "/abs/ws/my-existing-app",
176 "serverConfig": {
177 "OpenAccessTypes": ["PUBLIC"],
178 "Cpu": 0.5,
179 "Mem": 1,
180 "MinNum": 1,
181 "MaxNum": 5,
182 "EnvParams": "{\"DATABASE_URL\":\"postgres://user:pass@10.x.x.x:5432/app\"}",
183 "VpcConf": {
184 "VpcId": "vpc-xxxxxxxx",
185 "SubnetId": "subnet-xxxxxxxx"
186 }
187 }
188}
189```
190
191**Valid `OpenAccessTypes` values**: `OA` (办公网访问), `PUBLIC` (公网访问), `MINIAPP` (小程序访问), `VPC` (VPC访问). Use `PUBLIC` for web applications that need public HTTPS access.
192
193`MinNum: 1` is the recommended default when you want to reduce cold-start latency. If the user explicitly prefers lower cost and accepts more cold starts, explain the tradeoff and let them reduce `MinNum` to `0`.
194
195## Best practices
196
1971. Prefer PRIVATE/VPC or mini-program internal **ingress** when possible.
1982. For TCP database access, always pair private DB URLs with `VpcConf` in the same VPC/region as the database.
1993. Use environment variables for secrets and per-environment configuration.
2004. Verify configuration before and after deployment with `queryCloudRun(action="detail")`.
2015. Keep startup work small to reduce cold-start impact.
2026. For Agent scenarios, use the Agent SDK skill for protocol and adapter details instead of duplicating them here.
203
204## Troubleshooting hints
205
206- **Access failure** -> check ingress access type, domain setup, and whether the instance scaled to zero.
207- **Deployment failure** -> inspect Dockerfile, build logs, and CPU/memory ratio.
208- **Local run failure** -> remember only Function mode is supported by local-run tools.
209- **Performance issues** -> reduce dependencies, optimize initialization, and tune minimum instances.
210- **DB / Redis connection failure after a successful deploy** -> almost always missing or wrong `VpcConf`, wrong private host, or security group. Follow `references/vpc-and-database.md` before rewriting application code.
211
212## Reference index
213
214All packaged reference files (required for skill lint reachability):
215
216- [vpc-and-database.md](references/vpc-and-database.md)