Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion docs/configuration/agent-tasks/overview.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -24,8 +24,10 @@ Agent Tasks are one-time or scheduled jobs delegated to AI agents, running on yo
<Step title="Add Context (Optional)">
Connect a Qovery service, a Git repository, or both, for the agent to load as context. A Qovery service's linked Git repository is included automatically, no need to add it separately, connect a repository on its own only when it isn't tied to a Qovery service.
</Step>
<Step title="Choose a Provider">
<Step title="Choose a Provider and Model">

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P3: Renaming this step leaves four other docs pointing at the old name. Update them so the labels match the new step title.

Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At docs/configuration/agent-tasks/overview.mdx, line 27:

<comment>Renaming this step leaves four other docs pointing at the old name. Update them so the labels match the new step title.</comment>

<file context>
@@ -24,8 +24,10 @@ Agent Tasks are one-time or scheduled jobs delegated to AI agents, running on yo
     Connect a Qovery service, a Git repository, or both, for the agent to load as context. A Qovery service's linked Git repository is included automatically, no need to add it separately, connect a repository on its own only when it isn't tied to a Qovery service.
   </Step>
-  <Step title="Choose a Provider">
+  <Step title="Choose a Provider and Model">
     Pick **Claude** (Anthropic) or **AWS Bedrock**, then select an existing token or create a new one on the fly. A token created here is saved and can be reused by any other agent task in the organization, no need to re-enter credentials each time. Tokens can also be managed centrally from **Organization Settings > Agent > Token**.
+
</file context>

Pick **Claude** (Anthropic) or **AWS Bedrock**, then select an existing token or create a new one on the fly. A token created here is saved and can be reused by any other agent task in the organization, no need to re-enter credentials each time. Tokens can also be managed centrally from **Organization Settings > Agent > Token**.

Once a token is selected, pick the **Model** the agent runs on from the list of models available to that token. The first available model is selected by default. For AWS Bedrock, the models offered depend on the token's AWS region. You can change the model later from the agent task's **Settings > AI configuration**.
</Step>
<Step title="Add MCP Servers (Optional)">
If you added a Qovery service as Context in the previous step, Qovery's own MCP server is created and selected automatically: organization-scoped, read-only, backed by a Viewer API token. No URL, header, or token to configure. This is also preconfigured for the Incident Analyzer (incident.io and Honeybadger) and Build & deployment optimizer templates.
Expand Down
10 changes: 10 additions & 0 deletions docs/configuration/blueprints.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -196,6 +196,16 @@ The engine block defines how the resource is provisioned. Which settings you can
For Helm blueprints, engine version, credentials, and state backend do not apply — the chart and its version are defined by the blueprint, and the resources block is ignored because the chart declares its own.
</Info>

## Editing a Blueprint Service

After a blueprint service is created, you can change the inputs it was provisioned with from its **Blueprint configuration** settings page. Open the blueprint service, go to its **Settings**, and select **Blueprint configuration** to review and edit the variables and any overridable engine settings the blueprint exposes (see [Variables & Engine Reference](#variables--engine-reference)). Secret values are handled without exposing the stored secret, and the **Overrides** section is collapsed by default.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P3: This new paragraph says users can "review and edit the variables" on the Blueprint configuration page, but the same page states earlier that context variables (like region and cluster_name) are read-only and cannot be edited. Clarify that only the blueprint's editable variables and overridable engine settings can be changed, so the section doesn't contradict the reference table.

Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At docs/configuration/blueprints.mdx, line 201:

<comment>This new paragraph says users can "review and edit the variables" on the Blueprint configuration page, but the same page states earlier that context variables (like `region` and `cluster_name`) are read-only and cannot be edited. Clarify that only the blueprint's editable variables and overridable engine settings can be changed, so the section doesn't contradict the reference table.</comment>

<file context>
@@ -196,6 +196,16 @@ The engine block defines how the resource is provisioned. Which settings you can
 
+## Editing a Blueprint Service
+
+After a blueprint service is created, you can change the inputs it was provisioned with from its **Blueprint configuration** settings page. Open the blueprint service, go to its **Settings**, and select **Blueprint configuration** to review and edit the variables and any overridable engine settings the blueprint exposes (see [Variables & Engine Reference](#variables--engine-reference)). Secret values are handled without exposing the stored secret, and the **Overrides** section is collapsed by default.
+
+Save your changes, then redeploy the service to apply them.
</file context>
Suggested change
After a blueprint service is created, you can change the inputs it was provisioned with from its **Blueprint configuration** settings page. Open the blueprint service, go to its **Settings**, and select **Blueprint configuration** to review and edit the variables and any overridable engine settings the blueprint exposes (see [Variables & Engine Reference](#variables--engine-reference)). Secret values are handled without exposing the stored secret, and the **Overrides** section is collapsed by default.
After a blueprint service is created, you can change the inputs it was provisioned with from its **Blueprint configuration** settings page. Open the blueprint service, go to its **Settings**, and select **Blueprint configuration** to review and edit the blueprint's editable variables (read-only context variables stay locked) and any overridable engine settings the blueprint exposes (see [Variables & Engine Reference](#variables--engine-reference)). Secret values are handled without exposing the stored secret, and the **Overrides** section is collapsed by default.


Save your changes, then redeploy the service to apply them.

<Info>
The **Blueprint configuration** page is only available for blueprint-backed services. For a blueprint service, source, build, and deployment-restriction settings are not shown, since they are managed by the blueprint.
</Info>

## Updating a Blueprint

When Qovery maintains a newer version of a blueprint's template, the linked service surfaces an available update. Qovery compares your current tag to the latest catalog tag and reports exactly what changed:
Expand Down
23 changes: 22 additions & 1 deletion docs/configuration/clusters.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -144,7 +144,7 @@ Qovery tracks cluster health using two status categories:
| Status | Description |
| -------------------------------------------------------------------------------- | ----------------------------------------- |
| <Icon icon="circle-check" iconType="solid" color="green" /> **Running** | Cluster is healthy and operational |
| <Icon icon="triangle-exclamation" iconType="solid" color="yellow" /> **Warning** | Minor issues detected, requires attention |
| <Icon icon="triangle-exclamation" iconType="solid" color="yellow" /> **Warning** | Minor issues detected, requires attention — for example an [AWS quota warning](#aws-quota-warnings) |
| <Icon icon="circle-xmark" iconType="solid" color="red" /> **Error** | Critical issues, intervention required |
| <Icon icon="circle" iconType="regular" color="gray" /> **Status unavailable** | Cluster unreachable or offline |

Expand All @@ -157,6 +157,17 @@ Qovery tracks cluster health using two status categories:
| **Last Deployment Failed** | The most recent deployment encountered errors |
| **Last Deployment Succeeded** | The most recent deployment completed successfully |

#### AWS Quota Warnings

On AWS clusters, when Karpenter cannot create new nodes because an AWS service quota has been reached, the cluster status becomes **Warning** and a yellow callout is shown on the cluster overview. The callout reports:

- the **quota name** (or code) that was hit,
- the **impacted resource**,
- a **message** describing the issue,
- a **suggested action** — typically requesting an AWS quota increase, then retrying or waiting for the cluster to scale again.

While the warning is active, the cluster-status indicator shown next to your services (on the service overview) reads **Quota issue** instead of the generic warning label. The warning clears automatically once new nodes can be scheduled again; it may remain visible for a short time after the last occurrence.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2: This describes a changed status label, but the feature is a Quota issue tooltip on services. Describe the tooltip rather than implying the visible indicator label changes.

Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At docs/configuration/clusters.mdx, line 169:

<comment>This describes a changed status label, but the feature is a **Quota issue** tooltip on services. Describe the tooltip rather than implying the visible indicator label changes.</comment>

<file context>
@@ -157,6 +157,17 @@ Qovery tracks cluster health using two status categories:
+- a **message** describing the issue,
+- a **suggested action** — typically requesting an AWS quota increase, then retrying or waiting for the cluster to scale again.
+
+While the warning is active, the cluster-status indicator shown next to your services (on the service overview) reads **Quota issue** instead of the generic warning label. The warning clears automatically once new nodes can be scheduled again; it may remain visible for a short time after the last occurrence.
+
 ### Performing Actions on Clusters
</file context>
Suggested change
While the warning is active, the cluster-status indicator shown next to your services (on the service overview) reads **Quota issue** instead of the generic warning label. The warning clears automatically once new nodes can be scheduled again; it may remain visible for a short time after the last occurrence.
While the warning is active, affected services show a **Quota issue** tooltip next to the cluster-status indicator. The warning clears automatically once new nodes can be scheduled again; it may remain visible for a short time after the last occurrence.


### Performing Actions on Clusters

Available cluster operations and their cloud provider compatibility:
Expand Down Expand Up @@ -240,6 +251,16 @@ Permanently removes your cluster. You have three deletion options:
securely and never commit to version control.
</Warning>

## Deployments

Each cluster has its own **Deployments** tab that lists its past deployments, most recent first — each with its status, timestamp, duration, and who or what triggered it. Select a deployment to open its logs. This is the same [deployment history](/configuration/deployment/history) available on environments and services, applied to the cluster itself.

A cluster deployment run with the **Dry-run** option enabled — a checkbox in the cluster update dialog that previews the changes without applying them — is tagged with a **Dry run** badge in the list.

<Info>
Bookmarked links to the previous cluster logs URL are automatically redirected to the **Deployments** tab.
</Info>

## Logs

Access cluster logs for troubleshooting and monitoring:
Expand Down
4 changes: 4 additions & 0 deletions docs/configuration/organization.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -84,6 +84,10 @@ Manage your organization's billing and subscription:
- **Subscription**: Upgrade or downgrade your plan
- **Usage**: Monitor resource usage and costs

<Info>
When you create an organization or add a payment card, you must provide your billing details, including a billing address. A **VAT number** is required for billing addresses in EU countries and optional elsewhere. Postal codes are validated against the expected format for the selected country.
</Info>

For pricing details, visit the [pricing page](https://www.qovery.com/pricing).

## Organization Admin Settings
Expand Down
Loading