// Projects

Update a project

Update project name and description.

PUT/api/project

Description

Updates a project's general settings. Pass only the fields you want to change.

The same call also sets the project's two deployment timeout overrides, which carry partial-update semantics of their own - see below.

Parameters

NameInTypeRequiredDescription
projectId body string yes ID of the project.
name body string no New name.
description body string no New description.
maxDeploymentDurationSeconds body integer no Wall-clock cap on a whole deployment of this project, in seconds. 0 removes the override and restores the system default. See below.
stepIdleMaxSeconds body integer no How long one step may go without the agent reporting progress before it is interrupted, in seconds. 0 removes the override and restores the system default. See below.

Deployment limits

Two optional per-project overrides of timeouts that otherwise come from server configuration. Both are in seconds.

  • maxDeploymentDurationSeconds - a wall-clock cap on the whole deployment, whether or not it is making progress. This is what stops a hung deployment holding one of the organization's parallel deployment slots indefinitely.
  • stepIdleMaxSeconds - how long a single step may go without the agent reporting progress before it is interrupted. The interruption is written to the deployment log, naming the timeout that was applied.

Each takes three kinds of value, so one limit can be set without restating the other:

  • omitted, or null - leave whatever is stored alone.
  • 0 - remove this project's override, so the configured default applies again.
  • a positive number - use this value for this project.

There is deliberately no value meaning never apply this limit. For the duration cap that would reinstate exactly the hang it exists to prevent, so a project that genuinely needs longer sets a longer number instead.

The ceiling is 2000000 seconds, a little under 24 days. Past that the runner cannot arm its own timer, and only the scheduler's backstop would stop the deployment - which marks the row failed and frees the slot without being able to stop the work already running. A larger value is refused up front rather than accepted and quietly not honoured.

Both limits are validated before anything is written, and the general settings and the limits are saved in one transaction. A request that renames the project and carries an invalid limit therefore changes nothing at all - it does not land the rename and then fail.

Errors

StatusMeaning
400 Invalid projectId or validation failure.
401 Missing or invalid Basic auth credentials, or the service account lacks the required role.
400 A deployment limit is negative - the response reads deployment limits cannot be negative - use 0 to reset a limit to the system default. Nothing is changed.
400 A deployment limit is above 2000000 seconds - the message names the ceiling and why it exists. Nothing is changed.