r34 consolidated deployment and upgrade entry guide

This complete r34 release integrates the approved native HF latency/recovery corrections and the shared bounded-work, database, API, AI-admission and UI improvements. Install this release as the starting point. Do not run the older trial, bypass, diagnostic or individual correction installers over it. The product remains r34; hosted database schema is now 10. The current integration starts from archive SHA256 140cd2f3bbf55dc48f4095566c0dc9f367d85772666beb5fa60c87dac80d32de and includes both 2026-10-09 lifecycle packages. Start public-service planning with the current public deployment guide.

The native HF performance outcome is the operator's confirmation from the existing patched deployment. It is not a load test of this consolidated release or of another deployment topology. Read the accompanying release validation record and complete the acceptance steps below on the selected target.

Choose the deployment you intend to operate

External PostgreSQL is optional for HF. Selecting it does not remove or modify another deployment option. Native object-head/WAL ownership barriers remain specific to native HF; they are not installed as Linux/Docker request barriers. Native HF keeps local per-resource filesystem locks under that global durable fence. Linux/Docker and managed PostgreSQL use the applicable shared SQL resource-generation fences. Shared improvements apply where that deployment uses the corresponding hosted API, database, job, assistant or UI component. Standalone does not acquire a hosted identity database, global hosted AI queue or hosted billing service. Native HF's per-account HTTP rate limiter uses bounded single-controller memory to avoid a new SQL/WAL write for every read request; other hosted profiles keep shared SQL rate admission. This deployment-specific adaptation preserves the native performance corrections without weakening authentication, ownership or durable usage accounting. See the shared settings guide for its restart/window scope.

Before installing or upgrading

1. Verify the delivered archive against its companion SHA-256 file. Extract the complete archive into a new source directory; do not copy selected modules from a patch into an older source tree.
2. Select one row above. Record the existing deployment profile, release/image identities, resource identifiers and private configuration location. Preserve session, HF state, database, BYOK and BYOS keys, private code/runtime identities, bucket bindings, current quota ceiling and all accumulated usage.
3. For an upgrade, stop new admission and drain/stop every process that can write the same database or state. Verify any uncertain external invocation before releasing its reservation. Take and verify a coordinated backup of database, objects/private files, configuration and keys using that profile's guide.
4. Review the shared capacity settings. Process counts describe the whole fleet, not just the current machine. They do not provision servers or increase a provider quota.
5. Deploy code and run the explicit schema migration once as documented for the selected profile. Schema 10 retains the prior indexed references, bounded admission state and counters, and adds public-email, account-wide usage and lifecycle accounting/recovery state. Preserve records; do not reset usage.
6. Start the selected services only after migration succeeds. Complete the acceptance sequence below before reopening general admission.

Schema 10 must not be served by schema-9 or older service binaries. Do not roll back only the source/image after migration. Retain the prior release and a matching stopped database/private-state/configuration backup for coordinated recovery. Native-to-managed HF migration has an additional native-state retirement fence; its guide describes the restricted recovery path.

Native HF redeployment using this full release

Use the consolidated native upgrade, followed by the native guide's existing r34 upgrade sequence. Keep the same Space, tokens, Variables, Secrets, private Bucket, state key, PostgreSQL credentials and accumulated quota state. Preserve the actual approved ceiling; for the service already raised to 32 GiB, retain 34359738368 in both PF_HF_MAX_STORAGE_BYTES and the encrypted meter. The historical 16 GiB allowance is not a reset target. Do not recreate quota state by booting a maintenance program. Build and qualify matching private runner code and the controller bundle from this full release, then use its guarded deployment tool. A fresh native installation follows the native guide from the beginning.

Linux/Docker single-host upgrade

The reference guide contains the complete host prerequisites and fresh installation sequence. For an existing reference installation, run the new release's operator tool as the existing non-root service account. It keeps PostgreSQL on that host and preserves its named volume.

/home/pfsim/pf-host/venv/bin/python /srv/pf-releases/r34-consolidated/deploy/saas/reference/host.py --installation /home/pfsim/pf-host upgrade --source /srv/pf-releases/r34-consolidated --backup /home/pfsim/backups/r34-before-consolidation
/home/pfsim/pf-host/venv/bin/python /home/pfsim/pf-host/current/deploy/saas/reference/host.py --installation /home/pfsim/pf-host start
/home/pfsim/pf-host/venv/bin/python /home/pfsim/pf-host/current/deploy/saas/reference/host.py --installation /home/pfsim/pf-host status
curl --fail https://research.example.edu/healthz
curl --fail https://research.example.edu/readyz

Substitute the installed paths and origin. upgrade first stops services and backs up state; it then switches the source, adds only missing shared capacity settings, installs dependencies, builds/probes/pins images and migrates. A failed step leaves services stopped. Review its result before issuing start; then run the acceptance checks. Existing explicit limits and all secret values are preserved. This command does not transform a custom installation into the reference topology.

Distributed Linux/Docker upgrade

Follow distributed upgrade steps. All API replicas, worker slots, assistant processes and maintenance/scaler clients must use the same reviewed source/schema and fleet settings. Plan a maintenance window; do not run mixed old/new writers during schema migration. The database may be self-managed or supplied by a managed vendor. Choosing this profile does not require an HF account or use HF's native WAL publication mechanism.

Standalone fresh install and upgrade

1. Extract the complete release to a writable new directory. For an upgrade, close the old GUI and its background executors first. Back up the complete prior installation and any external state folders while stopped; preserve saved workflow, conversation, BYOK/BYOS configuration and encryption keys.
2. Launch PF_Simulation_GUI.pyw (or Launch_PF_GUI.vbs on Windows). Choose Check environment, then Install dependencies if required, and Open GUI. Use the existing installation guide (source package reference: ../R27_INSTALLATION_GUIDE.md) for optional scientific runtimes and GUI guide for controls. The launcher checks the installed Python; it does not upgrade Python itself.
3. Retain the original configured state paths. If moving local data to the new directory, copy only the existing private state/configuration directories while stopped, keeping the backup intact. Do not overwrite new release source with old program files. Use the supported workflow Export/Import route for portable workflow transfers.
4. Open an existing private workflow and conversation, inspect retained runs, then perform one bounded numerical run and export its results. Test provider and BYOS integrations only when configured and authorized. Hosted schema-10 migration commands are not standalone setup commands.

Post-deployment acceptance for hosted profiles

1. Confirm the exact running controller/application revision, /healthz and /readyz from the actual client network. A running container alone does not prove HTTP readiness or performance.
2. Sign in with an ordinary test account. Archive and restore an idle test project and organization; measure button acknowledgement and saved-state refresh separately. Check a second authorized session sees the result.
3. Verify another tenant cannot read/change that project or download its ZIP. Run one bounded simulation, verify completion and the authenticated Run ZIP, cancel a second test, and verify restart recovery preserves committed results.
4. Check existing private workflows, conversations, assistant evidence, BYOK, BYOS and quota/usage records. An acknowledged change followed by a secondary refresh error must not cause an automatic replay of the mutation.
5. Review controller, database, request and worker metrics for errors, pool/lock waits and provider ambiguity. Test a stopped backup/restore separately.
6. Increase users or worker slots only after measuring the intended workload. Local fixtures and the existing native HF responsiveness report do not certify a particular concurrent-user count, external service, failover or paid capacity.