Cloud Functions

Standalone Install Note

If this environment only installed the current skill, start from the CloudBase main entry and use the published cloudbase/references/... paths for sibling skills.

• CloudBase main entry: https://cnb.cool/tencent/cloud/cloudbase/cloudbase-skills/-/git/raw/main/skills/cloudbase/SKILL.md
• Current skill raw source: https://cnb.cool/tencent/cloud/cloudbase/cloudbase-skills/-/git/raw/main/skills/cloudbase/references/cloud-functions/SKILL.md

Keep local references/... paths for files that ship with the current skill directory. When this file points to a sibling skill such as auth-tool or web-development, use the standalone fallback URL shown next to that reference.

Cross-cutting protocols (required for public exposure and code changes):

• Change Safety Protocol: https://cnb.cool/tencent/cloud/cloudbase/cloudbase-skills/-/git/raw/main/skills/cloudbase/references/cloudbase-platform/references/protocols/change-safety-protocol.md
• Deployment Gate: https://cnb.cool/tencent/cloud/cloudbase/cloudbase-skills/-/git/raw/main/skills/cloudbase/references/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.

Then also read

• Detailed reference routing -> ./references.md
• Auth setup or provider-related backend work -> ../auth-tool/SKILL.md (standalone fallback: https://cnb.cool/tencent/cloud/cloudbase/cloudbase-skills/-/git/raw/main/skills/cloudbase/references/auth-tool/SKILL.md)
• CloudBase Integration Center generated WeChat Pay or Official Account functions -> ../cloudbase-wechat-integration/SKILL.md (standalone fallback: https://cnb.cool/tencent/cloud/cloudbase/cloudbase-skills/-/git/raw/main/skills/cloudbase/references/cloudbase-wechat-integration/SKILL.md; official docs: https://docs.cloudbase.net/integration/introduce/index.md)
• AI in functions -> ../ai-model-nodejs/SKILL.md (standalone fallback: https://cnb.cool/tencent/cloud/cloudbase/cloudbase-skills/-/git/raw/main/skills/cloudbase/references/ai-model-nodejs/SKILL.md)
• Long-lived container services or Agent runtimes -> ../cloudrun-development/SKILL.md (standalone fallback: https://cnb.cool/tencent/cloud/cloudbase/cloudbase-skills/-/git/raw/main/skills/cloudbase/references/cloudrun-development/SKILL.md)
• Calling CloudBase official platform APIs from a client or script -> ../http-api/SKILL.md (standalone fallback: https://cnb.cool/tencent/cloud/cloudbase/cloudbase-skills/-/git/raw/main/skills/cloudbase/references/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.
• 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.
• 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.

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: * (or specific origin) on all responses
• Include Access-Control-Allow-Methods: GET, POST, OPTIONS as needed
• Include Access-Control-Allow-Headers: Content-Type for JSON requests
• Keep routing and method handling explicit. Unknown paths should return 404, and known paths with unsupported methods should normally return 405.
• Keep gateway setup and security-rule changes separate from the runtime code. They affect access, not the HTTP Function programming model.
• Do not add HTTP access service configuration when the task is only to create an HTTP Function itself. Gateway paths or custom domains are separate access-layer work; public invocation requirements should be handled through the function security rule workflow (note: anonymous login is disabled by default).

Quick decision table

How to use this skill (for a coding agent)

1. 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

2. Use the converged MCP entrances

• Reads -> queryFunctions, queryGateway
• Writes -> manageFunctions, manageGateway
• Translate legacy names before acting rather than copying them literally

3. Write code and deploy, do not stop at local files

• Use manageFunctions(action="createFunction") for creation
• Use manageFunctions(action="updateFunctionCode") for code updates
• Use manageFunctions(action="updateFunctionConfig") for config updates (timeout, memorySize, envVariables)
• For a Custom Image HTTP Function, call manageFunctions(action="createFunction") with func.runtime="CustomImage" and imageConfig (imageUri with tag; registryId for enterprise TCR); iterate later with manageFunctions(action="updateFunctionCode") + imageConfig. No functionRootPath is needed because the code lives in the image. See ./references/http-functions-custom-image.md.
• Keep functionRootPath as the directory that directly contains function folders (e.g., cloudfunctions/ or functions/), NOT the project root and NOT the function subdirectory itself
• Prefer MCP tools over CLI — when MCP tools are available, use manageFunctions and queryFunctions instead of CLI commands
• Do NOT assume CLI is available from task wording alone — if the available capabilities only include MCP tools, use MCP tools exclusively
• For batch updates (multiple functions), call manageFunctions(action="updateFunctionConfig") individually for each function — MCP does not have a --all batch parameter like CLI

4. 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

5. Read the right detailed reference

• Event Function details -> ./references/event-functions.md
• HTTP Function details -> ./references/http-functions.md
• HTTP Function from a container image (Runtime: CustomImage, TCR image pipeline) -> ./references/http-functions-custom-image.md
• Logs, gateway, env vars, and legacy mappings -> ./references/operations-and-config.md

Database write reminder

• If a function will write to CloudBase document database, create the target collection first through console or management tooling.
• db.collection("feedback").add(...) only inserts into an existing collection; it does not auto-create feedback when absent.
• If the product requirement says "create when missing", implement that as an explicit collection-management step before the first write instead of assuming the runtime write call will provision it.

Function types comparison

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 { URL } = require("url");

// CORS headers — default to * for simple cross-origin APIs
const CORS_HEADERS = {
  "Access-Control-Allow-Origin": "*",
  "Access-Control-Allow-Methods": "GET, POST, OPTIONS",
  "Access-Control-Allow-Headers": "Content-Type",
};

function sendJson(res, statusCode, data) {
  res.writeHead(statusCode, {
    "Content-Type": "application/json; charset=utf-8",
    ...CORS_HEADERS,
  });
  res.end(JSON.stringify(data));
}

function sendOptions(res) {
  res.writeHead(204, CORS_HEADERS);
  res.end();
}

function readJsonBody(req) {
  return new Promise((resolve, reject) => {
    let raw = "";
    req.on("data", (chunk) => { raw += chunk; });
    req.on("end", () => {
      if (!raw) { resolve({}); return; }
      try { resolve(JSON.parse(raw)); } catch (e) { resolve({}); }
    });
    req.on("error", reject);
  });
}

const server = http.createServer(async (req, res) => {
  // Handle CORS preflight
  if (req.method === "OPTIONS") {
    return sendOptions(res);
  }

  const url = new URL(req.url || "/", "http://127.0.0.1");

  if (req.method === "GET" && url.pathname === "/") {
    sendJson(res, 200, { ok: true, message: "hello from http function" });
  } else if (req.method === "POST" && url.pathname === "/") {
    const body = await readJsonBody(req);
    sendJson(res, 200, { received: body });
  } else {
    sendJson(res, 404, { error: "Not Found" });
  }
});

server.listen(9000);

For a more complete example with routing, method checks, and error handling, see ./references/http-functions.md.

cloudfunctions/hello-http/scf_bootstrap

#!/bin/bash
/var/lang/node18/bin/node index.js

The scf_bootstrap binary path must match the runtime — see the full mapping table in ./references/http-functions.md.

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

Query function logs — use the queryFunctions tool:

• queryFunctions(action="listFunctionLogs", functionName="xxx") — list execution logs of a specific function
• queryFunctions(action="getFunctionLogDetail", requestId="xxx") — fetch the detail of one log entry

`queryFunctions` vs `queryLogs`:

• queryFunctions queries execution logs of a single cloud function and requires functionName
• queryLogs searches CLS (cross-service log aggregation) using CLS query syntax

Examples:

// List recent logs for cloud function "my-function"
queryFunctions(action="listFunctionLogs", functionName="my-function", limit=10)

// Inspect the log detail for a specific request id
queryFunctions(action="getFunctionLogDetail", requestId="abc-123")

// Cross-service error search via CLS
queryLogs(action="searchLogs", queryString='(src:app OR src:system) AND log:"ERROR"', service="tcb")

queryLogs queryString follows CLS syntax (see https://cloud.tencent.com/document/api/876/128127). The examples below are starting points; adapt them to the concrete log content of your query:

• Function logs: (src:app OR src:system) AND log:"START RequestId"
• Aggregated function request status: | select request_id, max(status_code) as status where ((request_id='xxxx' AND retry_num=0) AND retry_num=0) AND status_code!=202 group by request_id, retry_num
• Document database (NoSQL): module:database
• Document database slow-query events: module:database AND eventType:(MongoSlowQuery) — MongoSlowQuery is the document-database slow-query event
• Relational database (MySQL): module:rdb
• Relational database (MySQL) events: module:rdb AND eventType:(MysqlFreeze OR MysqlRecover OR MysqlSlowQuery) — MysqlFreeze = freeze, MysqlRecover = recover, MysqlSlowQuery = slow query
• Workflow (approval flow): module:workflow
• Data model: module:model
• User permissions: module:auth
• LLM trace logs: module:llm AND logType:llm-tracelog
• Gateway access logs: logType:accesslog
• App publish / delete events: module:app AND eventType:(AppProdPub OR AppProdDel) — AppProdPub = app publish, AppProdDel = app delete

If these are unavailable, read ./references/operations-and-config.md before any callCloudApi fallback

Gateway exposure

• queryGateway(action="getAccess")
• manageGateway(action="createAccess")
• If gateway operations need raw cloud API fallback, read ./references/operations-and-config.md first

Related skills

• cloudrun-development -> container services, long-lived runtimes, Agent hosting
• http-api -> raw CloudBase HTTP API invocation patterns
• cloudbase-platform -> general CloudBase platform decisions
• ops-inspector -> AIOps-style inspection and log search across services

Cloud Functions Execution Checklist

Use this checklist before creating or updating a CloudBase function.

Required checks

1. Decide whether this is an Event Function or an HTTP Function.

• Event Function: exports.main(event, context), SDK/timer driven
• HTTP Function: req / res, listens on port 9000

2. Pick the runtime before creation and state it explicitly.

• For a managed runtime, choose a language runtime (e.g. Nodejs18.15).
• For a container-image HTTP Function, set runtime: "CustomImage" and provide imageConfig (imageUri with tag; registryId for enterprise TCR). The image still listens on port 9000. See references/http-functions-custom-image.md.

3. For HTTP Functions on a managed runtime, confirm scf_bootstrap exists and the Node.js binary path matches the runtime (e.g. Nodejs18.15 → /var/lang/node18/bin/node). Custom Image functions do not use scf_bootstrap. 4. Confirm the function root path points to the parent directory, not the function directory itself. (Not needed for Custom Image deploys — the code lives in the image.) 5. For Custom Image deploys, confirm TCR, the CloudApp build, and SCF are in the same region, and the image tag is unique (not :latest). Remember Stage A (CloudApp custom build → TCR push) is a raw Tencent Cloud API path, not covered by MCP tools. 6. For HTTP Functions that need public access, configure the function security rule with managePermissions(action="updateResourcePermission", resourceType="function") after creation. Default rules reject unauthenticated callers with EXCEED_AUTHORITY. Note: anonymous login is disabled by default — use rule: "true" for public endpoints. 7. If the request is really for a long-running container service, reroute to cloudrun-development.

Common failure patterns

• Choosing the wrong function type and compensating later.
• Mixing Event Function and HTTP Function handler shapes in the same implementation.
• Forgetting that runtime cannot be changed after creation.
• Mismatching the scf_bootstrap Node.js binary path with the function runtime.
• For Custom Image functions: using :latest, mismatched regions across TCR/CloudApp/SCF, or assuming MCP covers the CloudApp build → TCR push stage (it does not).
• Forgetting to configure function security rules for HTTP Functions that need public access.
• Treating Cloud Functions as the default answer for Web authentication.

Done criteria

• Function type and runtime are explicit.
• Packaging constraints are checked.
• The task is confirmed to be a function workflow rather than CloudRun.

Cloud Functions Reference Map

Use this file to decide which detailed reference to read after the main skill.

Read this next when

• You already know the task belongs to Cloud Functions, but the main SKILL.md is intentionally keeping only the routing and guardrails.

Reference routing

./references/event-functions.md

Read this when the task is about:

• exports.main(event, context)
• SDK-invoked serverless functions
• timer-triggered jobs
• Event Function deployment or invocation patterns

./references/http-functions.md

Read this when the task is about:

• HTTP endpoints
• REST APIs
• SSE or WebSocket services
• scf_bootstrap
• browser/public access paths for HTTP Functions

./references/http-functions-custom-image.md

Read this when the task is about:

• deploying an HTTP Function from a container image (Runtime: CustomImage)
• imageConfig / ImageUri / TCR image addresses
• the zip → COS → CloudApp custom build → TCR → SCF image pipeline
• choosing between a managed-runtime HTTP Function, a Custom Image HTTP Function, and a CloudRun container

./references/operations-and-config.md

Read this when the task is about:

• function logs
• environment-variable updates
• trigger or VPC configuration
• gateway exposure for Event Functions
• legacy tool-name translation
• callCloudApi fallback for Cloud Functions

Keep these distinctions straight

• Event Function code shape: exports.main(event, context)
• HTTP Function code shape: req / res web server on port 9000
• HTTP Access for Event Functions is a gateway configuration, not the HTTP Function runtime model
• CloudRun is the right route when the task is actually a long-lived service or broader container workload
• Custom Image HTTP Function (Runtime: CustomImage) still listens on the fixed port 9000 and is request-driven — distinct from a CloudRun container, which listens on the injected PORT and runs long-lived

Event Functions Reference

Use this reference when the task is clearly about an Event Function (exports.main(event, context)) rather than an HTTP Function.

Runtime and packaging facts

• Runtime is fixed at creation time and cannot be changed later.
• For new functions, prefer Nodejs18.15 unless dependency compatibility forces an older runtime.
• Event Functions auto-install dependencies from package.json during deployment, so you normally do not ship node_modules.
• The function root path must point to the parent directory that contains the function folder.

Minimal structure

cloudfunctions/
└── myFunction/
    ├── index.js
    └── package.json

exports.main = async (event, context) => {
  return {
    code: 0,
    message: "ok",
    data: { event }
  };
};

Create or update flow

Create

Use manageFunctions(action="createFunction") and make the function type explicit.

manageFunctions({
  action: "createFunction",
  func: {
    name: "myFunction",
    type: "Event",
    runtime: "Nodejs18.15",
    timeout: 30
  },
  functionRootPath: "/absolute/path/to/cloudfunctions"
});

Update code

Use manageFunctions(action="updateFunctionCode") when only code changes.

manageFunctions({
  action: "updateFunctionCode",
  functionName: "myFunction",
  functionRootPath: "/absolute/path/to/cloudfunctions"
});

Key reminders

• updateFunctionCode does not change runtime.
• If runtime must change, recreate the function.
• Prefer MCP management tools over CLI in agent flows.

Invocation patterns

Web

import cloudbase from "@cloudbase/js-sdk";

const app = cloudbase.init({ env: "your-env-id" });
const result = await app.callFunction({
  name: "myFunction",
  data: { userId: "123" }
});

Mini Program

const result = await wx.cloud.callFunction({
  name: "myFunction",
  data: { userId: "123" }
});

Node.js backend

const tcb = require("@cloudbase/node-sdk");
const app = tcb.init({ env: "your-env-id" });

const result = await app.callFunction({
  name: "myFunction",
  data: { userId: "123" }
});

Raw HTTP API

Use the CloudBase HTTP API only when the task is explicitly about raw API invocation.

https://{envId}.api.tcloudbasegateway.com/v1/functions/{functionName}

This path requires authentication and belongs with the http-api skill, not browser-facing anonymous access.

Common patterns

Error handling

exports.main = async (event, context) => {
  try {
    const result = await doWork(event);
    return {
      code: 0,
      message: "Success",
      data: result
    };
  } catch (error) {
    return {
      code: -1,
      message: error.message,
      data: null
    };
  }
};

Environment variables

exports.main = async () => {
  const apiKey = process.env.API_KEY;
  const envId = process.env.ENV_ID;
  return { apiKeyExists: Boolean(apiKey), envId };
};

When to stop and reroute

• If the user wants a long-lived HTTP service, SSE, or WebSocket server, reroute to HTTP Functions or CloudRun.
• If the user wants browser SDK auth or UI login, reroute to the relevant auth skill.
• If the user wants MySQL or document database schema design, reroute to the data skills instead of forcing it into a function tutorial.

HTTP Functions — Custom Image Deployment Reference

Use this reference when an HTTP Function must run from a container image instead of the managed Node.js/Python runtime. This is the Runtime: CustomImage path: the code is packaged as a Docker image, pushed to TCR (Tencent Container Registry), and SCF runs that image.

When to choose Custom Image (vs the other two HTTP options)

Keep Custom Image HTTP Functions distinct from CloudRun containers — both use a Dockerfile, but:

• Custom Image HTTP Function: container listens on a fixed port `9000`, request-driven, scales to zero. SCF gateway sends each HTTP request into the container.
• CloudRun container: container listens on the injected `PORT` env var, long-lived process.

Do not blend the two contracts.

End-to-end pipeline (6 steps)

The link between the two stages is the TCR image address:

ImageUri = {TCR_REGISTRY}/{TCR_NAMESPACE}/{ServiceName}:{VersionName}
example:   ccr.ccs.tencentyun.com/your-ns/demo-app:demo-app-001

Stage A — build the image (CloudApp custom build pipeline)
  ① DescribeCloudAppCosInfo   -> get COS upload credentials + UnixTimestamp
  ② PUT zip to COS            -> upload source
  ③ CreateCloudApp            -> trigger docker build + docker push to TCR
  ④ DescribeCloudAppVersion   -> poll until Status=SUCCESS, read VersionName

Stage B — deploy to SCF (based on the TCR image)
  ⑤ createFunction / updateFunctionCode  -> SCF image function
  ⑥ getFunctionDetail (optional)         -> confirm Status=Active

Tooling boundary (read this before acting)

• Stage B (SCF image deploy) is covered by `manageFunctions`. Use manageFunctions(action="createFunction") with func.runtime="CustomImage" + imageConfig, and manageFunctions(action="updateFunctionCode") + imageConfig for later iterations. The Manager SDK auto-fills ImageType=enterprise and ImagePort=9000, and strips Handler / dependency install for image functions.
• Stage A (CloudApp custom build → TCR) is NOT covered by MCP tools. The manageApps / queryApps tools only support static-hosting. The custom-build pipeline (DeployType=custom, CustomSteps, DescribeCloudAppCosInfo with DeployType=custom) is a raw Tencent Cloud API path. Treat it as a callCloudApi fallback:
• Confirm the exact action name, parameters, and X-TC-Version from official docs before calling — do not guess payloads from memory.
• CloudApp build APIs are on tcb.tencentcloudapi.com (X-TC-Version: 2018-06-08).
• SCF APIs are on scf.tencentcloudapi.com (X-TC-Version: 2018-04-16).
• Region must match. TCR, the CloudApp build, and SCF must be in the same region (e.g. all ap-shanghai). Cross-region image pulls time out.

Stage B with manageFunctions (the supported path)

Create (first deploy)

manageFunctions({
  action: "createFunction",
  func: {
    name: "my-scf-func",
    type: "HTTP",
    runtime: "CustomImage"
  },
  imageConfig: {
    imageType: "enterprise",
    imageUri: "ccr.ccs.tencentyun.com/your-ns/demo-app:demo-app-001",
    registryId: "tcr-xxxxxxxx",
    command: "python",
    args: "-u app.py",
    imagePort: 9000,
    containerImageAccelerate: true
  }
});

Update image (later iterations)

Only the tag changes; no local code packaging.

manageFunctions({
  action: "updateFunctionCode",
  functionName: "my-scf-func",
  imageConfig: {
    imageType: "enterprise",
    imageUri: "ccr.ccs.tencentyun.com/your-ns/demo-app:demo-app-002",
    registryId: "tcr-xxxxxxxx"
  }
});

imageConfig fields

After deploy, confirm readiness with queryFunctions(action="getFunctionDetail", functionName="my-scf-func") and look for Status=Active. For public/browser access, create gateway access explicitly with manageGateway(action="createAccess", type="HTTP") and set the function security rule (anonymous login is disabled by default — see http-functions.md).

Source packaging (Stage A input)

Package the contents of the project root, with a Dockerfile at the root — do not nest an extra top-level folder.

# correct: zip the contents from inside the project root
cd ./my-app
zip -r ../my-app.zip .

# wrong: this nests an extra my-app/ layer after extraction
zip -r my-app.zip my-app/

After extraction the build container sees:

/  (workspace root)
├── Dockerfile          <- must be at the root
├── package.json / requirements.txt / pom.xml ...
├── src/
└── ...

Dockerfile contract for SCF image functions

FROM python:3.11-slim
WORKDIR /app
COPY . .
RUN pip install --no-cache-dir -r requirements.txt
EXPOSE 9000              # SCF Web Server functions must listen on 9000
CMD ["python", "-u", "app.py"]

SCF image constraints:

TCR credentials (Stage A push, raw API)

Use STS temporary credentials + TCR CreateInstanceToken to obtain a short-lived registry login, instead of storing any long-term TCR password:

• The build container injects STS credentials as $API_SECRET_ID / $API_SECRET_KEY / $API_TOKEN.
• In the build step, sign a TCR CreateInstanceToken call (tcr.tencentcloudapi.com, X-TC-Version: 2019-09-24) with those credentials to get a temporary token.
• docker login with that token (always via --password-stdin), then docker push.

Security red lines:

• Never print $API_SECRET_* / $API_TOKEN or pass them outside the container.
• Always use docker login --password-stdin so credentials never appear in ps or logs.

Build-container variables (Stage A, custom build)

Use these inside CustomSteps commands:

• Reserved prefixes that must NOT be declared in Env: API_*, CLOUDBASE_*, CODE_*, BUILD_TYPE, ZIP_FILE_URL.
• Do NOT reference non-existent variables such as $BUILD_ID, $CLOUDBASE_BUILD_ID, $CLOUDBASE_VERSION — use $CLOUDBASE_VERSION_NAME for the tag.

Common errors

Stage A (build)

Stage B (deploy)

Best practices

• Image tag = $CLOUDBASE_VERSION_NAME — available at build time, unique, traceable.
• TCR push via STS + CreateInstanceToken — no long-term secrets to manage.
• Runtime must be "CustomImage", not a language runtime.
• imageUri must include a tag — never :latest.
• Keep TCR, CloudApp build, and SCF in the same region.
• SCF image ≤ 500MB + enable acceleration to control cold-start time.

HTTP Functions Reference

Use this reference when the task is clearly about an HTTP Function: REST API, browser-facing endpoint, SSE stream, or WebSocket service.

Core model

HTTP Functions are standard web services, not exports.main(event, context) handlers.

• Handle requests through req and res.
• Listen on port 9000.
• Ship an executable scf_bootstrap file.
• Include runtime dependencies in the package; HTTP Functions do not auto-install node_modules for you.
• For simple HTTP APIs, prefer the Node.js native http module so the function shape stays explicit and dependency-light. Only introduce Express, Koa, NestJS, or similar frameworks when the user explicitly asks for one or the service complexity justifies it.

Minimal structure

my-http-function/
├── scf_bootstrap
├── package.json
├── node_modules/
└── index.js

scf_bootstrap

#!/bin/bash
/var/lang/node18/bin/node index.js

Requirements:

• File name must be exactly scf_bootstrap.
• Use LF line endings.
• Make it executable with chmod +x scf_bootstrap.

The scf_bootstrap Node.js binary path must match the function runtime. Use this mapping:

If the user specifies "Node.js 18", use runtime Nodejs18.15 and the path /var/lang/node18/bin/node.

Minimal Node.js example

const http = require("http");
const { URL } = require("url");

// CORS headers — default to * for simple cross-origin APIs
const CORS_HEADERS = {
  "Access-Control-Allow-Origin": "*",
  "Access-Control-Allow-Methods": "GET, POST, OPTIONS",
  "Access-Control-Allow-Headers": "Content-Type",
};

function sendJson(res, statusCode, data) {
  res.writeHead(statusCode, {
    "Content-Type": "application/json; charset=utf-8",
    ...CORS_HEADERS,
  });
  res.end(JSON.stringify(data));
}

function sendOptions(res) {
  res.writeHead(204, CORS_HEADERS);
  res.end();
}

function readJsonBody(req) {
  return new Promise((resolve, reject) => {
    let raw = "";

    req.on("data", (chunk) => {
      raw += chunk;
    });

    req.on("end", () => {
      if (!raw) {
        resolve({});
        return;
      }

      try {
        resolve(JSON.parse(raw));
      } catch (error) {
        reject(new Error("Invalid JSON body"));
      }
    });

    req.on("error", reject);
  });
}

const server = http.createServer(async (req, res) => {
  // Handle CORS preflight
  if (req.method === "OPTIONS") {
    return sendOptions(res);
  }

  const url = new URL(req.url || "/", "http://127.0.0.1");

  if (req.method === "GET" && url.pathname === "/health") {
    sendJson(res, 200, { ok: true });
    return;
  }

  if (req.method === "POST" && url.pathname === "/echo") {
    try {
      const body = await readJsonBody(req);
      sendJson(res, 200, { received: body });
    } catch (error) {
      sendJson(res, 400, { error: error.message });
    }
    return;
  }

  sendJson(res, 404, { error: "Not Found" });
});

server.listen(9000);

Code-writing rules

• Do not write HTTP Functions as exports.main = async (event, context) => {}. That is the Event Function contract.
• Start an HTTP server explicitly with http.createServer(...) or a framework app, and always bind to port 9000.
• Choose one Node.js module system and keep it consistent. For simple HTTP Functions, CommonJS is the safest default: use require(...) and leave "type": "module" out of package.json.
• If you intentionally use ES Modules, use import ... consistently and do not rely on CommonJS-only globals such as bare __dirname, require(...), or module.exports. When you need the current file path in ESM, derive it from import.meta.url.
• Treat routing, method checks, and body parsing as part of the function code. With the native http module, parse req.url yourself and read the request body from the stream before calling JSON.parse.
• Return JSON responses explicitly and set Content-Type yourself, for example application/json; charset=utf-8.
• Handle CORS headers. Browsers block cross-origin requests without proper CORS headers. Default to Access-Control-Allow-Origin: * for simple APIs, and always respond to OPTIONS preflight requests with 200 and CORS headers.
• Keep unsupported routes and methods explicit. Return 404 for unknown paths, and return 405 when the path exists but the HTTP method is not allowed.
• Keep scf_bootstrap, index.js, package.json, and any bundled dependencies in the function directory that will be uploaded.

Module system note

The minimal examples in this document use CommonJS:

• const http = require("http")
• no "type": "module" in package.json

That combination avoids the common ESM pitfall where __dirname is not defined. If you switch to ES Modules, switch the whole function to import syntax and update any file-path logic accordingly.

Request handling rules

• With Node native http, use new URL(req.url, "http://127.0.0.1") and read url.searchParams for query values.
• With Node native http, req.body does not exist. Read the body stream manually, then parse JSON yourself.
• req.headers -> incoming HTTP headers.
• Path parameters are framework-level conveniences. With the native http module, match url.pathname yourself.
• Always send a response explicitly. With Node native http, use res.writeHead(...) and res.end(...).
• Return meaningful status codes such as 400, 401, 404, 405, 500.

Example with method checks

const http = require("http");
const { URL } = require("url");

// CORS headers — default to * for simple cross-origin APIs
const CORS_HEADERS = {
  "Access-Control-Allow-Origin": "*",
  "Access-Control-Allow-Methods": "GET, POST, OPTIONS",
  "Access-Control-Allow-Headers": "Content-Type",
};

function sendJson(res, statusCode, data) {
  res.writeHead(statusCode, {
    "Content-Type": "application/json; charset=utf-8",
    ...CORS_HEADERS,
  });
  res.end(JSON.stringify(data));
}

function sendOptions(res) {
  res.writeHead(204, CORS_HEADERS);
  res.end();
}

function readJsonBody(req) {
  return new Promise((resolve, reject) => {
    let raw = "";

    req.on("data", (chunk) => {
      raw += chunk;
    });

    req.on("end", () => {
      if (!raw) {
        resolve({});
        return;
      }

      try {
        resolve(JSON.parse(raw));
      } catch (error) {
        reject(new Error("Invalid JSON body"));
      }
    });

    req.on("error", reject);
  });
}

const server = http.createServer(async (req, res) => {
  // Handle CORS preflight
  if (req.method === "OPTIONS") {
    return sendOptions(res);
  }

  const url = new URL(req.url || "/", "http://127.0.0.1");

  if (url.pathname === "/users" && req.method === "POST") {
    try {
      const { name, email } = await readJsonBody(req);

      if (!name || !email) {
        sendJson(res, 400, { error: "name and email are required" });
        return;
      }

      sendJson(res, 201, { name, email });
    } catch (error) {
      sendJson(res, 400, { error: error.message });
    }

    return;
  }

  if (url.pathname === "/users") {
    sendJson(res, 405, { error: "Method Not Allowed" });
    return;
  }

  sendJson(res, 404, { error: "Not Found" });
});

server.listen(9000);

Express 5 catch-all note

If the user explicitly asks for Express, keep in mind that Express 5 uses path-to-regexp semantics for wildcards. Do not use bare * or /* as the catch-all route.

app.all("/{*splat}", (req, res) => {
  res.status(405).json({ error: "Method Not Allowed" });
});

Express 5 note: app.all("/{*splat}", (req, res) => { is the safe catch-all form when you also need to match the root path /, because the router is based on path-to-regexp rather than the older Express 4 wildcard behavior.

End-to-end deployment lifecycle

This document covers the managed-runtime HTTP Function (ships scf_bootstrap, runs on a language runtime, packaged as zip). If the function instead needs custom system libraries or an arbitrary runtime, deploy it from a container image (Runtime: CustomImage) and read ./http-functions-custom-image.md — the runtime contract (web server on port 9000, CORS, security rules) is identical, only the packaging and deployment differ.

Follow these steps in order when creating a managed-runtime HTTP Function:

1. Write the function code — create the directory with index.js, scf_bootstrap, and package.json. 2. Deploy with `manageFunctions` — set type: "HTTP", protocolType: "HTTP", and runtime explicitly. 3. Configure security rules — HTTP Functions default to a restrictive security rule. If the function should be publicly accessible, call managePermissions(action="updateResourcePermission") with resourceType="function". Note: anonymous login is disabled by default for new environments; use permission: "CUSTOM" with securityRule: '{"invoke":"true"}' for truly public endpoints rather than relying on anonymous auth. 4. Verify — call the function URL and confirm it returns the expected response. If you get EXCEED_AUTHORITY, the security rule needs to be updated (step 3).

Deployment flow

Prefer manageFunctions over CLI in agent flows.

manageFunctions({
  action: "createFunction",
  func: {
    name: "myHttpFunction",
    type: "HTTP",
    protocolType: "HTTP",
    runtime: "Nodejs18.15",
    timeout: 60
  },
  functionRootPath: "/absolute/path/to/cloudfunctions"
});

Important parameters:

• type: "HTTP" — marks the function as an HTTP Function (not an Event Function).
• protocolType: "HTTP" — the wire protocol. Use "WS" for WebSocket.
• runtime — the execution runtime. Must match the scf_bootstrap binary path. Default is "Nodejs18.15" if omitted, but always set it explicitly to avoid ambiguity.
• functionRootPath — the parent directory of the function folder (e.g. /path/to/cloudfunctions if the code lives in /path/to/cloudfunctions/myHttpFunction/).

Security rule configuration

After creating an HTTP Function, it will reject unauthenticated callers with EXCEED_AUTHORITY by default. If the function should be publicly accessible:

⚠️ Note: Anonymous login is disabled by default for new environments. For public endpoints, use rule: "true" to allow all callers regardless of auth state, rather than relying on anonymous login being enabled.

managePermissions({
  action: "updateResourcePermission",
  resourceType: "function",
  resourceId: "myHttpFunction",
  permission: {
    aclTag: "CUSTOM",
    rule: "true"
  }
});

• aclTag: "CUSTOM" with rule: "true" allows all callers (public access without requiring any login).
• Do NOT use readSecurityRule / writeSecurityRule — those are removed. Use queryPermissions / managePermissions instead.
• Security rule semantics for resourceType="function" differ from NoSQL database rules. Do not reuse doc._openid or auth.openid expressions from NoSQL security rules.
• Official reference: https://docs.cloudbase.net/cloud-function/security-rules

If an external caller reports EXCEED_AUTHORITY, inspect the function permission first with queryPermissions(action="getResourcePermission", resourceType="function", resourceId="myHttpFunction") before widening access.

WebSocket

For WebSocket workloads, keep the function type as HTTP and switch protocolType:

manageFunctions({
  action: "createFunction",
  func: {
    name: "mySocketFunction",
    type: "HTTP",
    protocolType: "WS"
  },
  functionRootPath: "/absolute/path/to/cloudfunctions"
});

Invocation options

HTTP API with token

curl -L "https://{envId}.api.tcloudbasegateway.com/v1/functions/{name}?webfn=true" \
  -H "Authorization: Bearer <TOKEN>"

This is suitable for authenticated server-to-server access.

HTTP access path for browser/public access

Creating the function does not automatically create a browser-facing path. Add gateway access separately when the user actually needs it.

manageGateway({
  action: "createAccess",
  targetType: "function",
  targetName: "myHttpFunction",
  type: "HTTP",
  path: "/api/hello"
});

Before enabling public access, confirm both of these:

1. The access path exists. 2. The function security rule allows the intended caller identity (see Security rule configuration above). Note: anonymous login is disabled by default — for public endpoints, use rule: "true" instead of requiring anonymous auth.

SSE and WebSocket notes

SSE

res.setHeader("Content-Type", "text/event-stream");
res.write(`data: ${JSON.stringify({ content: "Hello" })}\n\n`);

WebSocket example

const WebSocket = require("ws");
const wss = new WebSocket.Server({ port: 9000 });

wss.on("connection", (ws) => {
  ws.on("message", (message) => ws.send(`Echo: ${message}`));
});

When to stop and reroute

• If the task is actually a timer-triggered or SDK-invoked serverless function, reroute to Event Functions.
• If the HTTP Function needs custom system packages or an arbitrary runtime but should stay SCF request-driven and scale to zero, deploy from a container image — read ./http-functions-custom-image.md.
• If the task needs long-lived containers, custom system packages, or broader service architecture, reroute to cloudrun-development.
• If the task is only about HTTP API calling patterns rather than implementation, reroute to http-api.

Cloud Functions Operations and Config Reference

Use this reference for logs, gateway exposure, environment-variable updates, triggers, and legacy tool-name translation.

Logs

Preferred path

• queryFunctions(action="listFunctionLogs") for the log list.
• queryFunctions(action="getFunctionLogDetail") for a specific request log.

Plan B: callCloudApi

Only use raw cloud API calls after reading the official docs or knowledge-base entry for the action and parameter contract. Do not guess the action name or payload shape from memory.

Log list

callCloudApi({
  service: "tcb",
  action: "GetFunctionLogs",
  params: {
    EnvId: "{envId}",
    FunctionName: "functionName",
    Offset: 0,
    Limit: 10,
    StartTime: "2024-01-01 00:00:00",
    EndTime: "2024-01-01 23:59:59"
  }
});

Log detail

callCloudApi({
  service: "tcb",
  action: "GetFunctionLogDetail",
  params: {
    StartTime: "2024-01-01 00:00:00",
    EndTime: "2024-01-01 23:59:59",
    LogRequestId: "request-id-from-log-list"
  }
});

Log query limits

• Offset + Limit cannot exceed 10000.
• StartTime to EndTime cannot span more than one day.
• For large ranges, page through day-sized windows.

Event Function HTTP access

Preferred path

Use manageGateway(action="createAccess").

Plan B: callCloudApi

Use raw cloud API only after checking the documentation for CreateCloudBaseGWAPI and confirming the gateway parameter contract.

callCloudApi({
  service: "tcb",
  action: "CreateCloudBaseGWAPI",
  params: {
    EnableUnion: true,
    Path: "/api/users",
    ServiceId: "{envId}",
    Type: 6,
    Name: "functionName",
    AuthSwitch: 2,
    PathTransmission: 2,
    EnableRegion: true,
    Domain: "*"
  }
});

Key parameters:

• Type: 6 -> function gateway type.
• AuthSwitch: 2 -> no auth. Use an authenticated mode only when the requirement says so.
• Domain: "*" -> default domain.

Environment variable updates

Do not overwrite function environment variables blindly.

Safe pattern

1. Read current config with queryFunctions(action="getFunctionDetail"). 2. Merge existing variables with the new variables. 3. Update with manageFunctions(action="updateFunctionConfig").

const current = await queryFunctions({
  action: "getFunctionDetail",
  functionName: "functionName"
});

const mergedEnvVariables = {
  ...current.EnvVariables,
  ...newEnvVariables
};

await manageFunctions({
  action: "updateFunctionConfig",
  functionName: "functionName",
  envVariables: mergedEnvVariables
});

Trigger and VPC notes

Timer triggers

Configure timer triggers through func.triggers.

• Type: timer
• Cron format: 7 fields -> second minute hour day month week year

Examples:

• 0 0 2 1 * * * -> 2:00 AM on the first day of every month
• 0 30 9 * * * * -> 9:30 AM every day

VPC access

{
  vpc: {
    vpcId: "vpc-xxxxx",
    subnetId: "subnet-xxxxx"
  }
}

Legacy tool-name translation

Prefer the converged entrances below, but translate historical names when they appear in old prompts or old docs.

CLI fallback

Use CLI only when MCP tools are unavailable AND CLI is explicitly enabled in the runtime environment.

• tcb fn deploy <name> -> Event Function
• tcb fn deploy <name> --httpFn -> HTTP Function
• tcb fn deploy <name> --httpFn --ws -> HTTP Function with WebSocket
• tcb fn deploy --all -> Deploy all functions
• tcb fn config update <name> -> Update function config (timeout, memorySize, envVariables)

Important: When the available capabilities include MCP tools but not CLI access, use MCP tools exclusively. Do not attempt CLI commands in such environments.

Batch updates via MCP: MCP does not have a --all batch parameter. To update multiple functions, call manageFunctions(action="updateFunctionConfig") individually for each function.

In non-interactive agent runs, do not default to CLI login or interactive setup flows.