/functions-development

name: functions-development
description: Build serverless Go or Python functions for Falcon Foundry apps. TRIGGER when user asks to "create a function", "write a serverless function", "build backend logic", runs `foundry functions create`, or needs help with FDK handler patterns, function testing, or collection integration from functions. Also TRIGGER when user asks to "execute a function", "run my function", "debug this function", "get function logs", "check execution status", "write function tests", "test my function handler", or "add test cases for my function". DO NOT TRIGGER for generic "write integration tests" or "write tests" without function context — ask which capability they want to test first. DO NOT TRIGGER for calling Falcon platform APIs from functions — use functions-falcon-api instead. DO NOT TRIGGER for workflow YAML or UI components. DO NOT TRIGGER for Playwright/e2e/browser tests — use e2e-testing instead.
version: 1.7.1
updated: 2026-11-10
tags: [foundry, functions, serverless, python, go, execution, debugging, logs, testing]
author: CrowdStrike
license: MIT
compatibility: Claude Code >=1.0
metadata:
  category: backend

Foundry Functions Development

> **Loading this skill is NOT a command to do anything.** It only equips you with function-development knowledge. Do NOT run any `foundry functions` command (especially `exec`, `test`, or a deploy) just because the skill loaded — wait for the user's actual request, and if their intent isn't clear yet, ask what they'd like to do. Never execute, test, or deploy a function unprompted. > > When you implement or modify functions: > 1. Use CrowdStrike SDKs (gofalcon/falconpy) for ALL API interactions > 2. Implement structured JSON responses with proper status codes > 3. Apply input validation before processing any request

Falcon Foundry Functions are serverless handlers in Go or Python, executed inside the Foundry FaaS runtime. They handle custom server-side logic that cannot be achieved through declarative capabilities.

Functions as a Last Resort

Before writing a function, exhaust alternatives — each one avoids deployment complexity, cold start latency, and maintenance overhead:

• **Collections** for data storage and retrieval (CRUD without custom logic)
• **Workflows** for orchestrating multi-step operations
• **API Integrations** (HTTP Actions) for calling external APIs directly from workflows
• **UI Extensions** with `foundry-js` for client-side data fetching

Credential Management — No Secrets System Exists

**There is no secrets management in Falcon Foundry.** When calling third-party REST APIs:

| Scenario | Approach | Credentials | |----------|----------|-------------| | Third-party REST API (VirusTotal, Slack, Jira, etc.) | API integration in manifest + `APIIntegrations().execute_command_proxy()` | Platform-managed at install time | | CrowdStrike Falcon API | FalconPy zero-arg constructor (`Alerts()`, `Hosts()`) | Platform-managed automatically | | Third-party GraphQL API (no OpenAPI spec) | Function with `requests` + env var | Visible in app exports (⚠️ security risk) |

**CRITICAL:** If the API has a REST endpoint and an OpenAPI spec exists, you MUST use an API integration. NEVER use `os.environ` with API keys, `requests.get()` with hardcoded URLs, or localStorage for credentials when an API integration can handle it. Raw HTTP with env vars technically works, but credentials are unencrypted and visible in app exports.

Reference Files

This skill is split across multiple files. Consult these for full examples:

| Task | Reference | |------|-----------| | Python handler, collection CRUD, error class, lookup file uploads, LogScale ingestion | [references/python-patterns.md](references/python-patterns.md) | | Go FDK handler, Falcon client auth, collection CRUD, alerts handler | [references/go-patterns.md](references/go-patterns.md) | | Too many functions: build failures, consolidation | [references/function-count-and-build-time.md](references/function-count-and-build-time.md) | | Falcon console testing (Python editor), function logs (viewing logs in UI and Advanced Event Search), Go/Python tests, local testing, Docker vs direct, config file patterns | [references/testing-patterns.md](references/testing-patterns.md) |

Resource Limits

| Resource | Default | Maximum | |----------|---------|---------| | JSON payload (input + output combined) | — | 1018 KB | | Execution timeout | 15s | 900s | | Memory | 256 MB | 1 GB | | Package size (zipped, with dependencies) | — | 50 MB | | Concurrent executions | — | 100 |

Runtime Environment

**Python: develop on 3.14.** The docs state only a minimum (3.9+) and the platform moves faster than them, so use the latest release. The runtime is manylinux_2_28 (glibc 2.28): pick `requirements.txt` versions with `manylinux_2_17` or `manylinux_2_28` wheels; wheels needing newer glibc (e.g., `manylinux_2_39`) may fail at import time. Run tests in a venv built like CI's, not the global interpreter — see [testing-patterns](references/testing-patterns.md).

CLI Scaffolding

foundry functions create \
  --name "my-function" \
  --language python \
  --description "Process incoming data" \
  --handler-name process \
  --handler-method POST \
  --handler-path /api/process \
  --max-exec-duration-seconds 60 \
  --max-exec-memory-mb 256 \
  --no-prompt

The two `--max-exec-*` flags write the manifest's `max_exec_duration_seconds` / `max_exec_memory_mb`; set them at create time instead of hand-editing later.

Function Execution & Debugging

> **Requires Foundry CLI 2.1.0+.** The commands below (`foundry functions exec`, `test`, `logs`) do not exist in CLI 2.0.x. If the user's CLI is below 2.1.0, inform them and offer to upgrade: `brew upgrade crowdstrike/foundry-cli/foundry`.

> **⚠️ DEPLOY FIRST — `exec` and `test` run against the deployed Lambda, not local code.** Never deploy automatically; ask the user first.

For the full command reference, request-