A volume is only ever mounted into one running container. You cannot deploy a service with a volume attached as multiple replicas, and your service is never attached to more than one copy of its volume. Since no two hosts share the same mount, flock only coordinates processes inside your container. It is not a lock between hosts.

When a volume is moved, your running deployment is stopped before the service starts using the volume in its new location. We do not publish a separate host-fencing guarantee for unplanned host failures, or specific guarantees beyond normal filesystem behavior for flock, rename and fsync. Volume backups capture the whole volume at one point in time. They do not pause your application or flush its buffers, so whether the data recovers cleanly depends on SQLite's own crash-recovery and durability settings.

Thank you. The planned-relocation explanation is helpful, but the unplanned-failure question remains unresolved. Could a Railway engineer confirm whether, after a host failure or disconnection and volume reattachment elsewhere, the previous host is prevented from resuming writes before the new host can write?

We are not asking for a cross-host flock guarantee or infrastructure changes. We need to understand whether the single-container volume guarantee also holds during unplanned failures, and whether storage fencing or another mechanism enforces it. If this is not guaranteed, please state that explicitly.

Please also identify the filesystem used for persistent volumes and any documentation covering rename/fsync durability. A human technical clarification would help us decide whether administrative SQLite restore is appropriate on this platform.

To answer your question directly: we do not publish a storage-fencing guarantee for unplanned host failures or disconnections. You should not assume there is a guaranteed mechanism that stops a previous host from resuming writes before the volume becomes writable somewhere else.

The guarantees we do stand behind are the ones covered earlier. A volume is attached to one running deployment of your service at a time, services with a volume can't run as multiple replicas, and a planned relocation stops your running deployment before the service uses the volume in its new location.

We also don't publish filesystem-specific guarantees for flock, rename or fsync beyond normal behavior inside your container. For an administrative SQLite restore, the safest design relies on SQLite's own journaling and synchronous settings for crash durability, not on platform-level fencing. Volume backups are point-in-time, crash-consistent snapshots of the whole volume. They don't pause your application or flush its buffers.