Web Service regions, plan upgrades, autoscaling, and billing

Choose the primary region once

A Darwa Web Service starts in one primary region. During creation, the active choices are Virginia, São Paulo, Frankfurt, Cape Town, Mumbai, and Sydney. Choose the location nearest to users and data. After creation the primary region is locked because it anchors the service identity, private networking, and data-placement assumptions. Changing a dropdown in place could create an unsafe move, so Settings shows the value as read-only.

Add a regional shard instead of moving

When another location is needed, add a regional shard from Settings → Regional traffic. A shard is a complete paid runtime using the same plan and connected source. Each shard has a separate endpoint for controlled traffic routing or failover; Darwa does not silently move the primary URL. Stateless services can attach shards. A service with a persistent disk must first adopt external durable storage because one block disk cannot be shared safely across regions.

Git pushes deploy the same release everywhere

Auto-deploy is enabled by default for a connected repository and can be disabled in Deploy settings. A push to the tracked branch queues the same revision for the primary runtime and every purchased shard. Health checks are evaluated independently before an endpoint is considered live. If manual approval is required, disable auto-deploy and release from the deployment screen or a private deploy hook.

Upgrade plans with remaining-period proration

Settings offers only plans above the current plan and applies one upgrade to every attached region. Before confirmation, Darwa shows the old monthly total, new monthly total, elapsed hours, remaining hours, and an estimated charge due now. The elapsed portion is credited: only the price increase for the remaining current period is invoiced immediately. Stripe calculates the final amount, and the new recurring monthly total applies at renewal. A downgrade is not performed through this safety-sensitive flow.

Understand autoscaling and Capacity Autopilot

Horizontal autoscaling changes the number of replicas between a minimum and maximum; every running replica uses the selected plan and is billed separately. Capacity Autopilot is different: after explicit consent it can temporarily increase plan capacity when sustained pressure—not one spike—crosses the policy threshold. Temporary capacity is billed only while active, stops when pressure falls, and is capped at 72 hours and the customer-defined ceiling. Enabling the policy itself creates no charge.

What happens when payment fails

A confirmed capacity purchase is invoiced immediately. If payment fails, Darwa keeps the service available during a seven-day grace period so the owner can update payment. Unresolved balances then suspend service traffic. Stored configuration is retained for another 14 days; paying during retention restores service. If the balance remains unpaid through retention, runtime resources and retained service data are deleted according to the billing lifecycle. The dashboard should always show the current deadline and required action.