Deployment Strategy

Storefront Hosting uses rolling deployments to release new versions of your Storefront Application. Instead of stopping the running version and starting a new one, the platform gradually replaces running instances with instances of the new version. Traffic only reaches instances that have proven to be healthy. Releases are invisible to your users, and a failed deployment never takes your storefront offline.

This page explains how a rollout works, which safety mechanisms are built in, and what your users experience while a deployment is in progress.

How a rollout works

You trigger deployments on demand from the SCAYLE Panel or the Storefront CLI (see Deployment Actions). Once the Deployment stage of the pipeline begins (see Deployment in Progress), the rollout proceeds in overlapping steps:

1. New instances start alongside the current ones. Instances running the new version are launched in addition to the instances currently serving your storefront. Running instances are never stopped up front, so serving capacity never drops during a deployment.
2. Health checks gate every new instance. A new instance receives no traffic until it reports healthy. An instance that never becomes healthy never serves a single request.
3. Traffic shifts gradually. As new instances pass their health checks, they start serving requests alongside the previous version until the new version has fully taken over.
4. Old instances are retired. Instances of the previous version are removed step by step once their replacements are serving traffic, allowing in-flight requests to complete first.

Rollouts also respect the current scaling state of your environment: if your storefront has scaled up to handle high traffic, the deployment maintains that capacity rather than resetting it.

Built-in safety mechanisms

Health-check gating

A health check is a small HTTP request that the platform sends to each instance of your application every few seconds, using the Storefront Application's built-in health endpoint (/api/up). An instance counts as healthy while it answers within a short time. If it fails several checks in a row, the platform marks it unhealthy and takes it out of traffic.

During a rollout, these checks decide whether the deployment makes progress: a new instance receives its first request only after passing its health checks, and traffic only ever reaches instances that respond as healthy. The checks keep running after the rollout, so the platform catches and restarts an instance that stops responding later.

Automatic rollback

A single instance that fails its health check does not fail the deployment. The platform keeps that instance out of traffic, restarts it, and the rollout waits for it to become healthy. It does not start extra instances to compensate, and it does not retire any more of the previous version's instances until their replacements are healthy.

What decides the outcome is the rollout as a whole, not a count of individual failed checks. If the new version has not reached the point where all of its instances are healthy within the rollout window, for example because the application crashes on startup or never passes its health checks, the platform stops the rollout, returns the release to the previous version, and marks the deployment as Failed.

Because the previous version keeps serving traffic throughout the rollout, an automatic rollback has no user-facing impact: your storefront continues running the last successful release. You can inspect the failed deployment's Startup Logs on the Deployment Details page to understand why the new version never became healthy, and fix the issue without time pressure.

One deployment at a time

Only one deployment can run per environment at any given time. You can trigger the next deployment once the current one has finished, so concurrent releases can't interfere with each other.

What your users experience

• No downtime. Your storefront remains fully available throughout the entire deployment. There is no maintenance window and no restart gap.
• No dropped requests. An instance finishes the requests it has accepted before it shuts down.
• A short transition window. While the rollout progresses, both the previous and the new version answer requests. Static assets remain available for both versions during this window, so pages rendered by either version load correctly.
• Fresh content immediately after release. Once a deployment succeeds, the platform invalidates cached pages on the CDN, so users receive the new version right away.

Recovering from a bad release

Automatic rollback covers releases that fail to become healthy during the rollout. For problems that only surface after a release has gone live, such as a visual regression or a broken user flow, you can manually roll back to any previously successful deployment. Rollbacks reuse the already-built artifact, so they complete quickly without a rebuild. See Rollback for details.