cloud-functions

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.

Cross-cutting protocols (required before code changes or deployments):

• Change Safety Protocol: ../cloudbase-platform/references/protocols/change-safety-protocol.md
• Deployment Gate: ../cloudbase-platform/references/protocols/deployment-gate.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 callCloudApi as a fallback for logs or gateway setup.
• An HTTP Function will call CloudBase resources through @cloudbase/node-sdk or @cloudbase/manager-node -> read ./references/http-function-credentials.md. HTTP Functions must use explicit credentials; do not rely on the Event Function passwordless runtime path.

Exception only (do not read by default)

• Migrating an existing app that already uses classic TCP DB clients (DATABASE_URL / Prisma / mysql2 / pg / Redis) → read ./references/vpc-and-tcp-database.md via ./references.md. New business CRUD must prefer CloudBase native SDK (app.database() / app.rdb()) or MCP SQL tools instead of TCP.

Then also read

• Detailed reference routing -> ./references.md
• Auth setup or provider-related backend work -> ../auth-tool-cloudbase/SKILL.md
• CloudBase Integration Center generated WeChat Pay or Official Account functions -> ../cloudbase-wechat-integration/SKILL.md (official docs: https://docs.cloudbase.net/integration/introduce/index.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-cloudbase/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.
• Creating Integration Center instances through guessed APIs. For WeChat Pay or Official Account generated functions, use cloudbase-wechat-integration for the business contract and this skill only for function operations.
• Tasks that the CloudBase JS SDK can handle directly — simple data reads/writes, leaderboards, file uploads, real-time queries. Reach for the matching SDK surface before writing a function: db.collection(...).get/add/update only for confirmed NoSQL collections, and app.rdb().from(...) for CloudBase PG tables. Functions add deployment complexity, CORS configuration, and HTTP gateway binding that the SDK eliminates entirely.

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 / res on port 9000).
• 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.
• Assuming db.collection("name").add(...) will create a missing document-database collection automatically. Collection creation is a separate management step.
• 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 port 9000, and include dependencies.
• Assuming an HTTP Function can use CloudBase SDKs without explicit credentials. The default temporary credential path is not reliable for HTTP Functions and credential rotation can break a running service. Use a CloudBase server API Key or Tencent Cloud key pair for @cloudbase/node-sdk; use a Tencent Cloud key pair for @cloudbase/manager-node. See references/http-function-credentials.md.
• Forgetting to configure function security rules after creating an HTTP Function. Default rules reject anonymous callers with EXCEED_AUTHORITY. Note: anonymous login is disabled by default for new environments — if the function needs public access without authentication, configure the security rule to allow all callers rather than relying on anonymous login.
• Mismatching the scf_bootstrap Node.js binary path with the function runtime (e.g. using /var/lang/node18/bin/node but setting runtime: "Nodejs16.13").
• For Custom Image HTTP Functions: forgetting that TCR, the CloudApp build, and SCF must be in the same region; using :latest instead of a unique tag; or confusing the request-driven port-9000 image model with a long-lived CloudRun container that listens on the injected PORT.
• Assuming MCP covers the whole image pipeline. manageFunctions covers SCF image deploy (Stage B) via runtime: "CustomImage" + imageConfig, but the CloudApp custom build → TCR push (Stage A) is a raw Tencent Cloud API path — confirm action names and parameters from official docs before any callCloudApi fallback.
• Making code or configuration changes without first following the Change Safety Protocol (cloudbase-platform/references/protocols/change-safety-protocol.md).
• Exposing functions publicly or deploying without first completing the checks in cloudbase-platform/references/protocols/deployment-gate.md.
• Defaulting new CRUD to TCP DB clients (DATABASE_URL / mysql2 / pg / Redis) instead of native app.rdb() / app.database() or MCP SQL. TCP is exception-only for existing ORM migrations — see references/vpc-and-tcp-database.md only then.

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. By default they run on a managed runtime (scf_bootstrap + zip); when they need custom system libraries or an arbitrary runtime they can instead run from a container image (Runtime: CustomImage, deployed from TCR — see ./references/http-functions-custom-image.md).

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 / res on port 9000.
• For Node.js HTTP Functions, default to the native http module unless the user explicitly asks for Express, Koa, NestJS, or another framework.
• If the HTTP Function needs custom system libraries or an arbitrary runtime but should still be SCF request-driven and scale to zero, deploy it as a Custom Image HTTP Function (Runtime: CustomImage) from a TCR image. The container still listens on the fixed port 9000. See ./references/http-functions-custom-image.md. This is distinct from a CloudRun container, which listens on the injected PORT and runs long-lived.
• If the user mentions HTTP access for an existing Event Function, keep the Event Function code shape and add gateway access separately.

HTTP Function authoring contract

Use these rules whenever you are writing the function code itself:

• Do not write an HTTP Function as exports.main(event, context). That is the Event Function contract.
• Treat the function as a standard web server process that must listen on port 9000.
• With Node.js, prefer http.createServer((req, res) => { ... }) by default so the runtime contract stays explicit.
• With the Node.js native http module, do not assume Express-style helpers exist. req.body, req.query, and req.params are not provided for you.
• For Node.js HTTP Functions, choose one module system up front and keep it consistent. Default to CommonJS for simple functions (require(...), no "type": "module" in package.json) unless you explicitly want ES Modules.
• If you do choose ES Modules ("type": "module" + import ...), do not mix in CommonJS-only globals or APIs such as require(...), module.exports, or bare __dirname. In ESM, derive file paths from import.meta.url with fileURLToPath(...) only when needed.
• With the native http module, parse req.url yourself with new URL(...), collect the request body from the stream, and only then call JSON.parse. Empty bodies should be handled explicitly instead of assuming JSON is always present.
• Return responses explicitly with res.writeHead(...) and res.end(...), including Content-Type such as application/json; charset=utf-8 for JSON APIs.
• Handle CORS headers. Browsers block cross-origin requests without proper CORS headers. Default to allowing all origins for simple APIs:
  • Respond to OPTIONS preflight with 200 and CORS headers
  • Include `Access-Control-Allow-Origin:

Content truncated.