Deployment strategies

A deployment strategy defines how a release is rolled out to a scope—how traffic shifts, what metrics trigger rollback, and where the strategy applies.

Reusable deployment strategies let you define rollout behavior once and apply it across scopes to ensure safe, predictable deployments. They’re especially useful for standardizing team practices and enforcing reliability in critical environments.

When to use reusable strategies

Some common scenarios:

• Rollback on telemetry: Automatically revert if http.error_rate > 0.3
• Gradual rollout: Shift 10% of traffic every 30 seconds
• Environment guardrails: Apply only in production or specific scope types

Reusable strategies reduce risk, simplify developer workflows, and ensure compliance with platform policies.

Creating a new strategy

To create your own strategy:

1. Go to Settings > Deployment Strategies
2. Click + New deployment strategy
3. Fill in targeting, traffic, and rollback settings
4. Save the strategy for use across compatible scopes

info

You can also check our API reference for request details and examples.

How strategies are applied

During deployment creation, users see a dropdown of applicable strategies. A strategy appears only if it matches the:

• Selected scope type
• Target environment
• Selected country (if applicable)

⚠️ Strategies are versionless. They apply as-is and don’t require updates for every release.

Configuration options

You can manage strategies from Platform Settings > Deployment Strategies. Each strategy includes several configuration areas:

Resource and dimensions

Select the resource and dimensions where this deployment strategy will be applied.

Strategy details

• Name: Displayed in the UI during deployment creation
• Description: Explain how and when to use the strategy

Metric-based rollback (optional)

Trigger rollback automatically when a live telemetry signal crosses a threshold:

• Metric name: e.g., http.error_rate
• Threshold: Numeric value to trigger rollback
• Comparison: greater_than, less_than, or equal

How often nullplatform checks for metrics

Nullplatform checks telemetry signals throughout the deployment to decide if a rollback is needed. The frequency changes over time:

• First 5 minutes: Metrics are checked every 30 seconds for quick response during early rollout.
• After 5 minutes: Metrics are checked every 1 minute.
• After 2 hours or when the deployment is finalized: Metric checks stop automatically.

This approach helps detect problems early without overloading the system during longer deployments.

Available metrics by deployment type

Kubernetes, NKS, and instance-based deployments

Metric name	Description
system.memory_usage_percentage	Percentage of memory usage on the instance.
http.response_time	Average HTTP response time in milliseconds.
system.cpu_usage_percentage	Percentage of CPU usage on the instance.
http.healthcheck_fail	Number of failed health checks within the evaluation window.
http.rpm	HTTP requests per minute.
http.error_rate	Rate of HTTP 4xx and 5xx errors over total requests.
http.healthcheck_count	Total number of health checks performed.

Note: NKS stands for Nullplatform Kubernetes Service.

Serverless deployments

Metric name	Description
serverless.throttles	Number of throttled executions due to concurrency or rate limits.
serverless.concurrent_executions	Count of concurrent executions in progress.
serverless.invocations	Total number of function invocations.
serverless.duration	Average duration of function executions in milliseconds.
serverless.errors	Total number of failed invocations due to errors.

Traffic pacing (optional)

Configure gradual traffic shifting:

• Interval: Time between increments (e.g., 30s)
• Step size: Traffic percentage per step (e.g., 10%)