Skip to main content
Deployment approvals let you require review before changes are applied to an environment. Instead of deploying immediately, Ryvn creates a preview showing exactly what will change. Someone with access to the environment reviews the preview and approves it, then the deployment executes. This is essential for customer cloud deployments where customers should have visibility and control over changes to their infrastructure. It’s also useful for production environments where you want a human checkpoint before any changes go live.

Enabling Approvals

Enable approval requirements on any environment by setting requireApproval: true.
# yaml-language-server: $schema=https://api.ryvn.app/v1/schemas/resources.json
kind: Environment
metadata:
  name: customer-prod
spec:
  requireApproval: true
  provider:
    type: aws
    accountId: "123456789012"

Terraform Service Behavior

Terraform services have their own autoApprove setting at the service level. When both settings are in play, environment-level requireApproval always wins. If the environment requires approval, it doesn’t matter what the service is configured to do—approval will be required.
Environment requireApproval: true overrides service autoApprove: true. This ensures customers always have approval authority over their environments.

Reviewing and Approving

When a deployment is triggered on an environment with approvals enabled, you’ll find the pending approval in the installation’s Activity tab.
1

Open the Activity tab

Go to Environments → select your environment → select the installation → Activity
2

Find the pending approval

Look for the task showing “Preview Complete” with an Approve button.
3

Review the preview

Click the task to see what will change. For Terraform services, this shows the full terraform plan output. For Helm and Kubernetes services, you’ll see a diff of the rendered manifests.
4

Approve

Click Approve to proceed. You can add a reason that will appear in the audit trail.
After approval, the deployment executes automatically.

Vendor and Customer Access

The most common use case for approvals is vendor-to-customer deployments: you (the vendor) push changes, and your customer approves them before they’re applied to their cloud account. When you invite a customer to an environment, they get scoped access that lets them view the environment, review previews, and approve deployments. They can’t see other environments, modify services, or trigger new deployments—only review and approve what you’ve proposed.
ActionVendorCustomer
Push code changes
Modify services
View all environments
View their environment
Review deployment previews
Approve deployments
Force deploy
Rollback
Inviting customers: Set customerEmail on the environment configuration. The customer receives an email with an invite code. Once they create their account, they can see any environments they’ve been invited to.
# yaml-language-server: $schema=https://api.ryvn.app/v1/schemas/resources.json
kind: Environment
metadata:
  name: acme-prod
spec:
  setup: customer-controlled
  customerEmail: admin@acme.com
  requireApproval: true
  provider:
    type: aws
    accountId: "111122223333"
  installations:
    - service: api
    - service: worker

Common Questions

No. Force deploy still creates a preview that requires approval when the environment has requireApproval enabled.
Rollbacks also require approval. The rollback creates a preview showing what changes will be applied.
No. They remain pending until approved or superseded by a new deployment.
The Activity tab shows all approvals with the user who approved, timestamp, and any reason provided.