Docs
Open the console →
Guides

Edit serverless function code in the browser

Open a serverless function from Inventory, edit its files in a real VS Code (Monaco) editor, and Save & deploy pushes the code back to the cloud — live for all four clouds.

Every serverless function row on the Inventory screen carries a ‹/› Code action. It opens the function's deployment package in a browser VS Code experience: a file tree on the left, the real Monaco editor in the middle, and a single Save & deploy that pushes your edits back to the cloud.

What you can edit

The editor works on the package's text files (JavaScript, TypeScript, Python, JSON, YAML, …). Binary entries — images, native modules, compiled artifacts — are listed greyed-out and are preserved byte-identical on deploy; they are never silently dropped. You can add new text files and remove existing ones; the deploy replaces the text surface of the package and keeps everything else.

How the deploy works — all four clouds live

Every provider follows the same shape: the platform fetches the function's current package, overlays your edited text files on it (binaries and untouched entries stay byte-identical), and pushes the rebuilt package back — always over the connection's existing keyless credentials, never a stored cloud key.

  • AWS Lambda: lambda:GetFunction → presigned ZIP → overlay → lambda:UpdateFunctionCode — grant both actions to the connector (or apply) role. Container-image functions are refused honestly (ZIP packages only).
  • GCP Cloud Functions (2nd gen): the v2 API's generateDownloadUrl fetches the source, generateUploadUrl + a buildConfig.source update push it back. Grant the connector service account cloudfunctions.functions.get, .sourceCodeGet, .sourceCodeSet and .update (plus the existing iam.serviceAccounts.getAccessToken impersonation). The redeploy is an asynchronous Cloud Build rebuild — Save & deploy returns immediately with the operation name as the code reference; the new revision goes live when the build finishes (minutes). 1st-gen functions and Cloud Run services are refused honestly.
  • Azure Functions / App Service: the site's Kudu (SCM) API — GET /api/zip/site/wwwroot/ out, POST /api/zipdeploy?isAsync=true back — authenticated with the same Entra federated token as discovery. The SCM site must allow Microsoft Entra (AAD) authentication and the connector's principal needs publish rights on the site; an app running WEBSITE_RUN_FROM_PACKAGE=url refuses zipdeploy, and Kudu's own error is surfaced.
  • Alibaba Function Compute 3.0: fc:GetFunction + fc:GetFunctionCode fetch the package, fc:UpdateFunction (with the rebuilt ZIP inline) deploys it — signed with the documented ACS3-HMAC-SHA256 request signature on the short-lived STS session. FC 3.0 functions only (FC 2.0 service/function pairs are refused honestly).
Permissions & audit

Opening the editor needs only membership (Viewers get a read-only editor). Save & deploy needs the mutate_infra capability (Deployer or above). Every deploy is audited as cloud.function_code_updated with the function id and file count — file contents are never written to the audit trail.