cloud-functions
Installation
Summary
Complete guide for developing, deploying, and managing CloudBase cloud functions with Event and HTTP types.
- Supports two function types: Event Functions (Node.js, event-driven) and HTTP Functions (Node.js/Python/Go/Java, web services on port 9000)
- Runtime is immutable after creation; must select correct Node.js version during initial deployment or delete and recreate to change
- HTTP Functions require
scf_bootstrapstartup script with execute permissions and LF line endings; Event Functions do not - Includes logging via
getFunctionLogsandgetFunctionLogDetailtools, with 1-day query window limits and pagination constraints - Covers SSE and WebSocket support, HTTP access configuration, environment variable management (must merge with existing values on update), and timer triggers via cron expressions
SKILL.md
Cloud Functions Development
Activation Contract
Use this first when
- The task is to create, update, deploy, inspect, or debug a CloudBase Event Function or HTTP Function that serves application runtime logic.
- The request mentions function runtime, function logs,
scf_bootstrap, function triggers, or function gateway exposure.
Read before writing code if
- You still need to decide between Event Function and HTTP Function.
- The task mentions
manageFunctions,queryFunctions,manageGateway, or legacy function-tool names. - The task might require
callCloudApias a fallback for logs or gateway setup.
Then also read
- Detailed reference routing ->
./references.md - Auth setup or provider-related backend work ->
../auth-tool/SKILL.md - AI in functions ->
../ai-model-nodejs/SKILL.md - Long-lived container services or Agent runtimes ->
../cloudrun-development/SKILL.md - Calling CloudBase official platform APIs from a client or script ->
../http-api/SKILL.md
Do NOT use for
- CloudRun container services.
- Web authentication UI implementation.
- Database-schema design or general data-model work.
- CloudBase official platform API clients or raw HTTP integrations that only consume platform endpoints.
Common mistakes / gotchas
- Picking the wrong function type and trying to compensate later.
- Confusing official CloudBase API client work with building your own HTTP function.
- Mixing Event Function code shape (
exports.main(event, context)) with HTTP Function code shape (req/reson port9000). - Treating HTTP Access as the implementation model for HTTP Functions. HTTP Access is a gateway configuration for Event Functions, not the HTTP Function runtime model.
- Forgetting that runtime cannot be changed after creation.
- Using cloud functions as the first answer for Web login.
- Forgetting that HTTP Functions must ship
scf_bootstrap, listen on port9000, and include dependencies.
Minimal checklist
- Read Cloud Functions Execution Checklist before deployment or runtime changes.
- Decide whether the task is Event Function, HTTP Function, or actually CloudRun.
- Pick the detailed reference file in references.md before writing implementation code.
Overview
Use this skill when developing, deploying, and operating CloudBase cloud functions. CloudBase has two different programming models:
- Event Functions: serverless handlers driven by SDK calls, timers, and other events.
- HTTP Functions: standard web services for HTTP endpoints, SSE, or WebSocket workloads.
Writing mode at a glance
- If the request is for SDK calls, timers, or event-driven workflows, write an Event Function with
exports.main = async (event, context) => {}. - If the request is for REST APIs, browser-facing endpoints, SSE, or WebSocket, write an HTTP Function with
req/reson port9000. - If the user mentions HTTP access for an existing Event Function, keep the Event Function code shape and add gateway access separately.
Quick decision table
| Question | Choose |
|---|---|
| Triggered by SDK calls or timers? | Event Function |
| Needs browser-facing HTTP endpoint? | HTTP Function |
| Needs SSE or WebSocket service? | HTTP Function |
| Needs long-lived container runtime or custom system environment? | CloudRun |
| Only needs HTTP access for an existing Event Function? | Event Function + gateway access |
How to use this skill (for a coding agent)
-
Choose the correct runtime model first
- Event Function ->
exports.main(event, context) - HTTP Function -> web server on port
9000 - If the requirement is really a container service, reroute to CloudRun early
- Event Function ->
-
Use the converged MCP entrances
- Reads ->
queryFunctions,queryGateway - Writes ->
manageFunctions,manageGateway - Translate legacy names before acting rather than copying them literally
- Reads ->
-
Write code and deploy, do not stop at local files
- Use
manageFunctions(action="createFunction")for creation - Use
manageFunctions(action="updateFunctionCode")for code updates - Keep
functionRootPathas the parent directory of the function folder - Use CLI only as a fallback when MCP tools are unavailable
- Use
-
Prefer doc-first fallbacks
- If a task falls back to
callCloudApi, first check the official docs or knowledge-base entry for that action - Confirm the exact action name and parameter contract before calling it
- Do not guess raw cloud API payloads from memory
- If a task falls back to
-
Read the right detailed reference
- Event Function details ->
./references/event-functions.md - HTTP Function details ->
./references/http-functions.md - Logs, gateway, env vars, and legacy mappings ->
./references/operations-and-config.md
- Event Function details ->
Function types comparison
| Feature | Event Function | HTTP Function |
|---|---|---|
| Primary trigger | SDK call, timer, event | HTTP request |
| Entry shape | exports.main(event, context) |
web server with req / res |
| Port | No port | Must listen on 9000 |
scf_bootstrap |
Not required | Required |
| Dependencies | Auto-installed from package.json |
Must be packaged with function code |
| Best for | serverless handlers, scheduled jobs | APIs, SSE, WebSocket, browser-facing services |
Minimal code skeletons
Event Function hello world
cloudfunctions/hello-event/index.js
exports.main = async (event, context) => {
return {
ok: true,
message: "hello from event function",
event,
};
};
cloudfunctions/hello-event/package.json
{
"name": "hello-event",
"version": "1.0.0"
}
HTTP Function hello world
cloudfunctions/hello-http/index.js
const http = require("http");
const server = http.createServer((req, res) => {
res.writeHead(200, { "Content-Type": "application/json" });
res.end(JSON.stringify({ ok: true, message: "hello from http function" }));
});
server.listen(9000);
cloudfunctions/hello-http/scf_bootstrap
#!/bin/bash
/var/lang/node18/bin/node index.js
cloudfunctions/hello-http/package.json
{
"name": "hello-http",
"version": "1.0.0"
}
Preferred tool map
Function management
queryFunctions(action="listFunctions"|"getFunctionDetail")manageFunctions(action="createFunction")manageFunctions(action="updateFunctionCode")manageFunctions(action="updateFunctionConfig")
Logs
queryFunctions(action="listFunctionLogs")queryFunctions(action="getFunctionLogDetail")- If these are unavailable, read
./references/operations-and-config.mdbefore anycallCloudApifallback
Gateway exposure
queryGateway(action="getAccess")manageGateway(action="createAccess")- If gateway operations need raw cloud API fallback, read
./references/operations-and-config.mdfirst
Related skills
cloudrun-development-> container services, long-lived runtimes, Agent hostinghttp-api-> raw CloudBase HTTP API invocation patternscloudbase-platform-> general CloudBase platform decisions
Weekly Installs
688
Repository
tencentcloudbase/skillsGitHub Stars
42
First Seen
Jan 22, 2026
Security Audits
Installed on
codex614
opencode610
gemini-cli601
github-copilot587
kimi-cli577
amp574