If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/openfaas/faas shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Single-maintainer risk — review before adopting

• Last commit 5w ago
• 10 active contributors
• Other licensed
• CI configured
• Tests present
• ⚠ Single-maintainer risk — top contributor 84% of recent commits
• ⚠ Non-standard license (Other) — review terms

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live openfaas/faas repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/openfaas/faas.

What it runs against: a local clone of openfaas/faas — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in openfaas/faas | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 68 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of openfaas/faas. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/openfaas/faas.git
#   cd faas
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of openfaas/faas and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "openfaas/faas(\\.git)?\\b" \\
  && ok "origin remote is openfaas/faas" \\
  || miss "origin remote is not openfaas/faas (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 68 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~38d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/openfaas/faas"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

OpenFaaS is a serverless computing framework that packages functions and microservices into OCI-compatible Docker images and deploys them to Kubernetes with built-in auto-scaling, metrics, and event-driven execution. The gateway component (in the /gateway directory) serves as the API orchestrator and HTTP router, handling function invocation, queuing, and integration with the Prometheus metrics stack and NATS message queue. Monorepo with /gateway as the core HTTP API server (Go with Gorilla mux router), /contrib for Grafana dashboards, and /api-docs with OpenAPI specs. The gateway integrates faas-provider (abstraction over Kubernetes) and nats-queue-worker for async task handling. HTML UI assets live in /gateway/assets.

Platform engineers and DevOps teams who want to offer serverless function execution on Kubernetes; developers writing event-driven microservices who prefer working in Docker/OCI images rather than vendor lock-in frameworks like AWS Lambda.

Production-ready and actively maintained. The repository shows professional CI/CD via GitHub Actions (build.yml, publish.yml), a structured changelog and contributor guidelines, and recent dependency updates (Go 1.24, client_golang v1.23.0). The project has commercial backing (OpenFaaS Pro) and a clear EULA/licensing model, indicating mature governance.

Moderate risk: the gateway depends on 14+ transitive dependencies including NATS, Prometheus, and raft consensus libraries, expanding the supply-chain surface. Licensing is split between Community Edition (restricted use) and Pro, which can create friction for commercial users; ensure your use case is covered by the EULA. Single-maintainer risk is mitigated by the commercial entity behind the project, but the monorepo structure means breaking changes in github.com/openfaas/faas-provider or queue-worker updates could cascade.

Active maintenance evidenced by recent Go dependency updates and nats-queue-worker pinned to a January 2025 commit. Workflows are configured for both build and publish pipelines. No specific milestone or PR data visible, but the module setup suggests ongoing refinement of the queue and provider integration.

Clone and navigate to the gateway subdirectory:

git clone https://github.com/openfaas/faas.git
cd faas/gateway
go mod download
make build

Refer to /gateway/Makefile for available targets (build, test, docker image creation).

Daily commands: From /gateway:

make build          # Compile the gateway binary
make test           # Run tests
make docker-build   # Build Docker image

The gateway typically runs as a Kubernetes deployment and requires environment variables pointing to the provider (Kubernetes API) and NATS broker. See /gateway/README.md for full config.

• gateway/Makefile: Build targets, test commands, and Docker image creation; essential to understand the dev workflow
• gateway/Dockerfile: Defines the production container image for the gateway, shows runtime dependencies and entry point
• api-docs/spec.openapi.yml: OpenAPI contract for all gateway REST endpoints; critical for understanding function invocation and lifecycle APIs
• go.mod (gateway/go.mod): Declares faas-provider, nats-queue-worker, and Prometheus client dependencies; reveals architectural dependencies
• gateway/README.md: Gateway-specific setup, configuration, and usage instructions
• .github/workflows/build.yml: CI/CD pipeline definition; shows test matrix, linting, and build stages

Adding a new function API endpoint: edit /gateway/handlers.go (inferred from typical gateway structure; not visible but referenced by Gorilla mux setup). Changing metrics: update the Prometheus instrumentation in files that import github.com/prometheus/client_golang. Queue integration changes: modify /gateway's NATS client initialization (check /gateway/Makefile for entry point). Testing: add tests alongside handler logic and use make test to run. Documentation: update /api-docs/spec.openapi.yml for API contract changes.

NATS broker requirement: the gateway expects a running NATS server for async queuing; startup will fail silently if NATS_URL is unconfigured or unreachable. Provider abstraction: gateway code depends on the faas-provider interface (imported from github.com/openfaas/faas-provider); breaking changes there require coordination. Licensing: Community Edition has usage restrictions (see EULA.md); commercial features require OpenFaaS Pro. Go version: module requires Go 1.24, so older installations may fail. Prometheus metrics: the gateway emits metrics on a fixed port (typically 8082 or via environment variable); Prometheus scrape config must match or metrics are silently lost.

• Function as a Service (FaaS) with auto-scaling — Core to OpenFaaS design; understanding scaling policies (metrics-driven, including scale-to-zero) is critical for deploying production workloads efficiently.
• OCI Image Format & Container Registry Integration — OpenFaaS packages functions as standard OCI Docker images; you must understand image pulls, layer caching, and registry authentication to deploy successfully.
• Provider Abstraction Pattern — The gateway decouples from Kubernetes via the faas-provider interface; understanding this pattern helps you add support for alternative orchestrators (Docker Swarm, OpenShift, etc.).
• Async Task Queuing with NATS — The gateway uses NATS for background job offloading; understanding message queuing semantics (at-least-once delivery, topic subscriptions) is essential for reliable async function execution.
• Prometheus Metrics Instrumentation — The gateway emits metrics (request latency, function invocations, queue depth) via Prometheus; you need to understand metric types (counters, histograms, gauges) to monitor deployments and troubleshoot performance.
• REST API Gateway Pattern — The gateway routes HTTP requests to functions via a Gorilla Mux-based dispatcher; understanding path routing, middleware chains, and request/response lifecycle is needed to extend or customize the API.
• Graceful Shutdown & Signal Handling — The gateway uses golang.org/x/sync for coordinated shutdown; critical for zero-downtime deployments and avoiding dropped requests during rolling updates.

• openfaas/faas-netes — The official Kubernetes provider implementation; needed to actually deploy functions on K8s clusters when using the gateway.
• openfaas/faas-cli — Command-line tool for packaging, building, and deploying functions; primary user interface for OpenFaaS developers.
• openfaas/faas-provider — Provider abstraction library that the gateway depends on; defines the interface for executing functions on a platform (Kubernetes, Docker Swarm, etc.).
• openfaas/nats-queue-worker — NATS-based async task consumer that the gateway queues work to; essential for background function execution.
• knative/serving — Alternative serverless framework on Kubernetes; useful for understanding competing design approaches to function auto-scaling and HTTP routing.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add integration tests for gateway API endpoints in gateway/Makefile workflow

The gateway directory has a Makefile and multiple asset files but lacks visible integration test coverage. Given that this is the core API gateway component handling function invocations, adding structured integration tests would validate critical paths like function deployment, invocation, and scaling without relying solely on unit tests.

• [ ] Review gateway/Makefile to understand current build/test targets
• [ ] Create gateway/tests/integration directory with test files for core endpoints (e.g., /system/functions, /function/{name}, /system/scale-function)
• [ ] Add integration test targets to gateway/Makefile that spin up a minimal gateway instance and validate HTTP responses
• [ ] Update gateway/README.md with instructions for running integration tests
• [ ] Add integration test step to .github/workflows/build.yml to run tests on every PR

Create OpenAPI spec validation in CI and generate client SDKs from api-docs/spec.openapi.yml

The repo has api-docs/spec.openapi.yml but no visible CI workflow to validate it against actual gateway code or generate client libraries. This is valuable because it ensures the documented API stays in sync with implementation and enables auto-generation of SDKs for multiple languages.

• [ ] Add openapi-generator or similar tool to Makefile (e.g., validate spec syntax)
• [ ] Create .github/workflows/api-validation.yml to lint the OpenAPI spec on every PR using tools like Spectacle or Swagger Validator
• [ ] Add optional client SDK generation (Go, Python, JavaScript) and publish as artifacts to demonstrate value
• [ ] Update api-docs/README.md with instructions on how the spec is maintained and how to regenerate clients

Add missing unit tests for gateway request routing and middleware in gateway/ (following Go testing conventions)

The gateway package imports gorilla/mux for HTTP routing and has prometheus metrics integration, but test files are not visible in the partial file structure. Adding table-driven unit tests for routing, middleware chains, and metric collection would improve code quality and catch regressions early.

• [ ] Identify main handler/routing files in gateway directory (likely gateway.go or similar)
• [ ] Create gateway/*_test.go files using Go's standard testing package with table-driven tests for: router initialization, request dispatch, error handling, and prometheus counter/histogram increments
• [ ] Test middleware order and metrics collection (prometheus/client_golang integration)
• [ ] Update gateway/Makefile to include test coverage reporting (e.g., go test -cover)
• [ ] Add coverage threshold check to .github/workflows/build.yml (fail if coverage drops below baseline)

• Add integration tests for the NATS queue worker failure scenarios in /gateway (test what happens when NATS broker is offline or message delivery fails); helps improve reliability without modifying core logic.
• Expand /api-docs/spec.openapi.yml with examples and response schemas for all 404/500 error paths; improves API documentation quality for users of the gateway.
• Create a Makefile target for local development that spins up a mock NATS server via Docker Compose and starts the gateway; reduces onboarding friction for contributors.

• High · Outdated Go Cryptography Library — gateway/go.mod (indirect dependency). The dependency golang.org/x/crypto is pinned to version v0.41.0, which is significantly outdated. This version was released in December 2023 and likely contains known security vulnerabilities. The current stable version is v0.43.0+. Cryptographic libraries should be kept up-to-date to patch security flaws. Fix: Update golang.org/x/crypto to the latest stable version. Run 'go get -u golang.org/x/crypto' to upgrade.
• High · Outdated System-level Dependencies — gateway/go.mod (indirect dependency). The golang.org/x/sys dependency is pinned to v0.35.0, which is outdated. System-level libraries often contain critical security patches for OS interactions and should be kept current. Fix: Update golang.org/x/sys to the latest stable version. Run 'go get -u golang.org/x/sys' to upgrade.
• Medium · Potential HTTP Security Header Gaps — gateway/handlers/*.go (specifically cors.go and forwarding_proxy.go). The codebase includes HTTP handlers (cors.go, forwarding_proxy.go) in the gateway component. Without reviewing the actual implementation, there is potential risk of missing critical security headers (Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security) which could expose the application to XSS, clickjacking, and MIME-type attacks. Fix: Review handler implementations to ensure all critical security headers are properly set. Implement middleware that adds: X-Content-Type-Options: nosniff, X-Frame-Options: DENY, X-XSS-Protection: 1; mode=block, and Strict-Transport-Security headers.
• Medium · CORS Configuration Risk — gateway/handlers/cors.go. The presence of a cors.go handler suggests CORS is implemented. Misconfigured CORS can allow unauthorized cross-origin requests, potentially exposing sensitive API endpoints to attacks from malicious websites. Fix: Review CORS configuration to ensure: (1) Origin whitelist is restrictive, not using wildcards for sensitive endpoints; (2) Credentials are not allowed with wildcard origins; (3) Allowed methods and headers are minimal and necessary.
• Medium · Forwarding Proxy Implementation Risk — gateway/handlers/forwarding_proxy.go. The forwarding_proxy.go handler suggests the gateway proxies requests to backend services. This creates potential for Server-Side Request Forgery (SSRF) attacks if URLs are not properly validated, allowing attackers to access internal services or resources. Fix: Implement strict URL validation: (1) Whitelist allowed backend hosts; (2) Prevent access to internal IP ranges (127.0.0.1, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16); (3) Validate and sanitize all URL parameters.
• Medium · Alert Handler Input Validation — gateway/handlers/alerthandler.go. The alerthandler.go component processes alerts/webhooks. Without code review, there's risk of injection attacks if alert payloads are not properly validated and sanitized. Fix: Implement strict input validation: (1) Validate all alert payload fields; (2) Use allowlisting for expected fields; (3) Implement rate limiting on alert endpoints; (4) Add logging for suspicious inputs.
• Low · Old AngularJS Version — gateway/assets/script/angularjs/1.8.0/. The gateway uses AngularJS 1.8.0 (released 2021) which is in legacy maintenance mode and no longer receives security updates. AngularJS itself has known XSS vulnerabilities when misused. Fix: Consider migrating to a modern frontend framework (Angular, React, Vue) that receives active security updates. If AngularJS must be used, implement strict Content Security Policy and input sanitization.
• Low · Missing Security Policy Files — undefined. No evidence of security.md or SECURITY.txt files in the repository. This makes it difficult for security researchers to report vulnerabilities responsibly. Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.