Saved-state deployment choice for low-traffic SWI-Prolog service

Direct answer

For a low-traffic SWI-Prolog HTTP service, prefer a separate saved-state file paired with a pinned system swipl binary when you control the target host. It keeps the deployed artifact small and lets the OS package manager handle runtime updates. Choose a standalone executable only when you cannot guarantee a compatible swipl on the target machine.

Established behavior vs. environment-dependent factors

It is well established that qsave_program/2 produces a memory image tied to the emulator version and CPU architecture. A standalone executable bundles that image together with the emulator, producing a larger single binary. A separate state file is small but requires the host swipl to match the version used at build time.

What varies by environment is how strictly the version must match across patch releases, and whether OS-level swipl updates preserve saved-state compatibility. Treat exact patch-level compatibility as unverified until you test it in staging.

Artifact size and update effort

Approach	Artifact size	Logic update	Runtime patch
Standalone executable	Large (emulator + state)	Rebuild entire binary	Rebuild entire binary
Separate state file	Small (state only)	Regenerate state only	OS package update, then verify state loads

Patching the Prolog runtime

The separate-state approach better supports runtime patching because the emulator lives outside your application artifact. You can apply a distribution security update to swipl without rebuilding your Prolog code. However, if the patch changes the emulator version, the saved state will likely fail to load, forcing a regeneration. Standalone executables avoid host-version mismatch entirely, but every runtime patch requires a full rebuild of the bundled image.

Steps for this case

1. Pin the exact swipl package version in your deployment manifest.
2. Build the saved state on a host matching the target architecture and OS.
3. Deploy the state file and the pinned swipl package together.
4. Before promoting a runtime patch, load the existing state with the new swipl build in a staging environment.

One missing diagnostic

Do you control the target host's swipl installation, or must the artifact be fully self-contained? If you control the host, the separate state file is usually the better fit for a low-traffic service. If you do not, a standalone executable is safer despite the larger artifact and heavier rebuild cycle.