1.0.0-beta.9 · exact release
Fastly deployment candidates
Source fda16de1b352 · Published v1.0.0-beta.9
Pulse produces separate Fastly Native and Fastly JavaScript Compute candidates. Local conformance, target building, external provider reality, remote deployment, and service activation are different proof levels.
This guide does not claim that a local simulation or offline build is a production deployment.
Configure bindings and target
Section titled “Configure bindings and target”The config/secret example is source-bound to a Fastly Native profile:
import { defineConfig } from '@pulse-compute/pulse'
export default defineConfig((scope) => ({ pulse: { entry: 'src/index.ts', tests: 'tests/pulse.harness.ts', defaultProfile: 'local', strict: true, }, local: { host: 'fastly', target: 'native', outDir: 'dist', apiBase: scope.config('API_BASE'), apiToken: scope.secret('API_TOKEN'), dev: { config: { API_BASE: 'https://api.example.com' }, secrets: { API_TOKEN: 'local-example-secret', GRIP_TOKEN: 'local-grip-secret', }, kv: { sessions: { 'session:123': { userId: 123 } }, }, fetches: { 'https://api.example.com/users/7': { value: { id: 7, name: 'Ada' }, }, 'POST https://publisher.example.com/publish': { status: 202, value: { accepted: true, messageId: 'message-1' }, }, }, }, fastly: { bindings: { configStore: 'app_config', secretStore: 'app_secrets', kv: { sessions: 'app_sessions' }, backends: { 'https://api.example.com': 'api_backend', 'https://publisher.example.com': 'publisher_backend', }, dynamicBackends: false, grip: { publishEndpoint: 'https://publisher.example.com/publish', publishBackend: 'publisher_backend', authentication: { scheme: 'bearer', secretRef: 'GRIP_TOKEN', }, }, }, build: { name: 'pulse-fastly-capabilities-example' }, }, },}))Select the JavaScript candidate explicitly with target: 'javascript'.
The dev values and fixtures are local conformance inputs. They do not create
or populate Fastly Config Stores, Secret Stores, KV Stores, backends, Fanout
resources, or services. Deployment resource names belong under
fastly.bindings.
Validate locally
Section titled “Validate locally”pulse doctorpulse testpulse devFor both Fastly targets, test and dev use provider-owned local execution.
Fastly JavaScript identifies this as provider emulation. Fastly Native uses the
canonical local runtime. Neither path contacts or proves a deployed service.
Build Fastly Native
Section titled “Build Fastly Native”pulse buildWith target: 'native', Pulse compiles the provider-neutral plan and emits
generated src/main.as.ts plus compact direct-host-ABI:
bin/main.wasmThe Wasm imports the required fastly_* hostcalls directly. It does not contain
the Fastly JavaScript runtime, pulse_host, or a WASI dependency. The build
manifest records exact provider bindings, required capabilities, target
identity, compiler identity, and artifact hashes.
Build Fastly JavaScript
Section titled “Build Fastly JavaScript”With target: 'javascript', pulse build emits a deterministic source and
deployment closure:
src/index.jssrc/application.jsfastly.tomlpackage.jsonpulse-esbuild.config.jspulse-fastly-javascript-candidate.jsonpulse-fastly-javascript-deployment.jsonpulse-fastly-javascript-source-package.jsonThe closure pins esbuild and @fastly/js-compute, bundles the reachable Pulse
application and supported package implementations, and contains no Pulse
Native artifact. Its downstream build produces bin/main.wasm; the candidate
and deployment manifests bind that runtime artifact by SHA-256 and retain
automaticFallback: false.
Pulse claims deterministic bytes for its source closure and deployment metadata. It does not claim byte-identical Wizer-owned runtime snapshots.
Provider reality is a separate gate
Section titled “Provider reality is a separate gate”The external Native reality lane discovers the Fastly CLI and invokes:
fastly compute serve --file <candidate>/bin/main.wasmand sends real HTTP requests through the generated module. It covers schemas, config, secrets, KV persistence, named-backend fetch, opaque bytes, repeated headers, and GRIP hold/publish.
The Fastly JavaScript offline candidate lane runs the exact pinned downstream
compiler and validates the resulting runtime Wasm. It does not currently claim
the same fastly compute serve reality execution.
The Sprint 7 final candidate must pass its mandatory external reality gate in the later packed/provider-reality checkpoint. Checkpoint 5 documents the boundary; it does not mark that external gate complete.
Remote deployment and activation
Section titled “Remote deployment and activation”pulse build never runs fastly compute deploy. After candidate review, a
human deployment owner must:
- create or select the Fastly service and required resources;
- ensure every configured binding names the intended resource;
- supply account, service, and token authority outside the handler;
- run the provider deployment command against the reviewed candidate;
- verify the deployed service and external origins;
- decide activation, traffic migration, and rollback.
Remote deployment and activation require explicit human authorization. A successful local conformance run, offline build, downstream JavaScript compile, or Native reality serve does not authorize those actions.
Proof-level checklist
Section titled “Proof-level checklist”| Proof level | What it establishes | What it does not establish |
|---|---|---|
pulse test / pulse dev | Canonical behavior and configured local mapping | Remote resources or deployed service health |
pulse build | Deterministic provider candidate and metadata | External provider execution or deployment |
| Native reality gate | Real Fastly CLI-managed host-ABI execution | Remote service deployment or activation |
| JavaScript offline candidate gate | Exact downstream runtime compilation | Fastly serve, remote deployment, or activation |
| Human remote verification | Deployed service/resource behavior | Permission to publish or promote other release surfaces |
See Project lifecycle, Fastly config, secrets, and
KV, @pulse-compute/provider-fastly,
Managed handler TypeScript and JavaScript,
Provider and target compatibility,
and Release acceptance.