Update deployment configuration for a project

Where a source deployment's image is built.

The control plane is the default and the historical behaviour. Node moves the build — the most CPU- and memory-hungry step of a deployment — onto a worker node so it stops competing with the proxy, the database and running workloads on the control plane. A node labelled temps.sh/role=builder is preferred; otherwise the node the deployment is placed on builds it.

Node is a preference, not a requirement: when no worker can take the build (none joined, none of the right architecture, or a multi-architecture build) the build runs on the control plane and the build log says why. A static site may build on a worker of any architecture, since its output is read from that node and never runs.

Build one image per architecture the eligible nodes run. Off by default; environments inherit this and may override it. Cross-builds are emulated on the control plane and substantially slower, so they are opted into rather than triggered by cluster topology.

How long, in seconds (30-3600), a new deployment's containers may take to start and pass their readiness check before the deployment fails. Absent leaves the current value unchanged; the platform default is 300 seconds.

Project-level default cap on concurrent in-flight requests to a single environment's upstream (0 = unlimited). Environments may override this. Absent leaves the current value unchanged. See issue #646.

Project-level default timeout for regular (non-streaming) HTTP requests, in seconds (0 = no timeout, or 1-86400). Environments may override this; always clamped to the operator's global hard ceiling regardless of what's set here. Absent leaves the current value unchanged.

Project-level default idle timeout for Server-Sent Events streams, in seconds (0 = no timeout, or 1-86400). Environments may override this; always clamped to the operator's global hard ceiling. Absent leaves the current value unchanged.

Project-level default idle timeout for WebSocket connections, in seconds (0 = no timeout, or 1-86400). Environments may override this; always clamped to the operator's global hard ceiling. Absent leaves the current value unchanged.

Opt-in to AI summarization of metric alert notifications (NULL/false = off).

Opt-in to AI summarization of API traffic analytics (NULL/false = off).

Whether this project also accepts deployments from a source other than source_type — chiefly, whether a Git-backed project will take an uploaded source archive (drop). null or false means only the configured source_type (plus Docker images and static bundles, which every project accepts) may be deployed.

Attack mode - when enabled, requires CAPTCHA verification for all project environments

ADR-027 Phase 3 opt-out: when false, this project's traces are suppressed from cross-project discovery results. Default true (consistent with the OSS global-observability model where any OtelRead holder can query any project's telemetry).

Enable automatic preview environment creation for each branch

Opt-in to native error-tracking source context (false = off). When on, Temps stores uploaded source files and shows source code in stack traces.

Where auto-capture reads source from (relative to the checkout). Null = the deployment's Docker build context.

Git provider behind git_provider_connection_id: github, github_app, gitlab, gitea, bitbucket or generic. null when the project has no connection (public repository, Docker image or uploaded source).

Clients must use this rather than guessing the host from git_url: a self-hosted GitLab/Gitea/Bitbucket instance can live on any domain, and a connected project may have no clone URL stored at all.

Git clone URL for the repository (used for public repos without a provider connection)

GitLab webhook ID installed on the connected repository. null when no GitLab webhook is installed (not connected to GitLab, or webhook was removed / never created).

Hours to retain built Docker images before nightly cleanup. Null = use the system-wide default from settings.

Authoritative repository visibility. A missing connection alone does not imply that an incompletely configured repository is public.

Idle timeout (seconds) for on-demand preview environments.

When true, newly-created preview environments default to on-demand mode (containers stop after the configured idle timeout to save resources).

Wake timeout (seconds) for on-demand preview environments.

Product lifecycle classification. service projects are tied to a persisted, versioned template release; this is independent from the deployment transport in source_type.

When true, deploy clones only directory via git sparse-checkout.

Logo from the immutable service-template release applied to this project. Clients should prefer it over a deployed site's favicon.

Exact service-template version currently applied to the project.

Source type for project deployments

Determines where the deployment artifacts come from:

• External: Telemetry only, without hosting
• Git: Source code from a Git repository (traditional flow)
• DockerImage: Pre-built Docker image from external registry
• StaticFiles: Pre-built static files uploaded as a bundle
• UploadedSource: Source archive uploaded without a Git repository
• Manual: Flexible type that accepts any deployment method

Bundled template slug that created this project. Clients use this to present template-specific runtime configuration instead of generic source-build controls.

Opt-in Trivy vulnerability scanning of this project's deployed Docker images. Off by default — project owners explicitly enable it.