# Hosting, backup & your data

Fleetlane holds business records in PostgreSQL and attachment bytes in S3-compatible
object storage. The checked-in staging application configuration selects Sydney
and a database per tenant. Confirm your organisation's deployed environment and
service agreement for actual location, retention and recovery arrangements.

## Your records and files

In database topology, each tenant has a registered database target and runtime
role. Fleetlane also supports schema topology for explicitly configured environments;
your operator can confirm which topology serves your organisation. See
[Isolation and access](https://docs.fleetlane.app/security/isolation-access/).

Attachments use keys scoped to the tenant. Fleetlane checks access to the parent claim
or vehicle before issuing an upload or download URL. Those URLs expire: the
source default is five minutes and the configured limit is one hour. Treat a
signed link as sensitive while it remains valid.

The database records file metadata separately from the file bytes. A database
backup alone therefore does not restore every attachment. Storage privacy,
encryption, versioning and region depend on the actual provider configuration.

## Backup and restore arrangements

Backup scheduling and retention are provider/operator settings, outside the Fleetlane
application source. Ask your operator for the current backup schedule,
point-in-time recovery window, attachment recovery method and the date of the
last tested restore. These need to cover both database records and stored files.

A restore should first be prepared in an isolated environment so its records and
attachments can be inspected before a live recovery decision. Lifecycle state
and external-system effects also need reconciliation; restoring a database does
not reverse an ERP payment or a lifecycle engine run.

## Export and leaving the service

Arrange an export with your operator covering database records, original files
and any lifecycle evidence you need to retain. Confirm the supported format,
scope and delivery procedure for your deployment.

Tenant deletion includes cleanup of that tenant's live object-storage prefix
before its database or schema is removed. Retention in provider backups, object
versions, connected systems and the lifecycle engine is a separate matter. Confirm the
agreed retention and deletion procedure rather than treating tenant deletion as
proof that every copy has been erased.

Source review: 1 October 2026, using the staging Fly configuration, tenant
administration hooks, attachment router and object-storage service. No deployed
provider region, backup, restore, encryption or exit procedure was verified.