Skip to content

PATTERN Cited by 1 source

Bake-heavy provision-light

Pattern

Front-load all heavy operations (package installation, compilation, environment-agnostic configuration) into the image bake phase, leaving only minimal, environment-specific setup (secret retrieval, regional config, service start) for the provision phase at instance boot. This inverts the traditional model where instances do significant work at first boot.

Mechanism

  1. Bake phase (offline, per-image-version):
  2. Install all packages and dependencies.
  3. Apply configuration that is consistent across environments.

  4. Run validation; produce a known-good image.

  5. Provision phase (online, per-instance-launch):

  6. Retrieve secrets from vault/secrets-manager.
  7. Apply regional or environment-specific metadata.
  8. Start services.
  9. Total time: seconds, not minutes.

Why it matters

  • Scaling speed: New instances in auto-scaling events or rolling deploys are immediately useful — no waiting for package installs.
  • Consistency: All instances of the same image version behave identically; only per-environment parameters differ.
  • Reduced failure surface: Fewer operations at boot means fewer ways for an instance to fail during provisioning.
  • Predictable deployment latency: Rollout speed is bounded by instance- refresh rate, not per-instance configuration time.

Slack's implementation

Slack's Shipyard explicitly separates these phases: "By moving heavy operations like package installation into the bake phase, instances can become operational in seconds rather than minutes. This fast startup time is critical for scaling events, rolling deployments, and automated instance replacement" (Source: sources/2026-07-14-slack-shipyard-next-generation-ec2-platform).

Seen in

Last updated · 585 distilled / 1,765 read