SifrBolt / docs

SifrBolt Documentation

Documentation to understand the SifrBolt platform and use it effectively.

Use this when

You are launching a new campaign, microsite, or feature that requires refreshed cache behavior across regions.

Prerequisites

  • Surge or higher plan with permissions to publish cache policies.
  • Staging environment that mirrors production routes.
  • Rollout rings configured for the target storefronts.

Step 1 · Draft the Policy Update

  1. In the console, open Performance → Cache Policies and duplicate the current production policy.
  2. Adjust route-specific TTLs, compression settings, or asset hydration rules to match the upcoming campaign.
  3. Save the draft and request a signature if your workspace enforces approvals.

Step 2 · Validate in Staging

  1. Switch to your staging storefront and apply the draft policy.
  2. Run smoke tests or Lighthouse audits to confirm the new policy meets performance targets.
  3. Capture metrics you can compare later in production.

Step 3 · Publish to Production

  1. Promote the policy to production with rollout rings (e.g., 25% → 75% → 100%).
  2. Monitor latency and error budgets from the console dashboards during each ring.
  3. If you detect regression, roll back from the console and edit the draft before retrying.

Step 4 · Warm Caches

  1. Trigger the Warm Edge Caches action from the deployment panel to pre-populate regional edges.
  2. If you automate via CLI, run the command from the operations toolkit (for example bunx @sifrbolt/ops warm-object-cache --storefront <code>slug</code>) to hydrate the WordPress object cache.
  3. Confirm hit ratios and latency stabilize within expected thresholds.

Step 5 · Document the Launch

Generate proof package

  1. Download bundle cache-refresh-2025-01 from the Trust Center.
  2. Verify signatures with the rollout command in the verification CLI (e.g., bunx @sifrbolt/verify rollout --bundle cache-refresh-2025-01).
  3. Attach the verified metrics to your campaign debrief or change record.

After the Campaign

  • Schedule a review to retire temporary rules or lower TTLs once traffic normalizes.
  • Archive proof artifacts in your governance repository.
  • Update runbooks so the next campaign can reuse the validated steps.

Add additional launch playbooks under docs/src/pages/implementation/ for other campaign types or verticals.