Trust model

Trust

This page defines the current operating promise for Resistro Cloud. Every public claim here maps directly to the approved promise matrix and should be read together with its explicit boundaries.

Live status

Current operational status

API uptime (24h)

Health uptime (24h)

Live data from status.resistro.org — updated in real time, not cached by this page.

Hourly backups

Resistro Cloud backs up Postgres databases on an hourly rhythm for small self-managed Postgres setups in the defined ICP.

Scope: Hourly backup cadence for supported self-managed Postgres setups.

Preconditions: The customer system must be reachable, correctly attached, and technically compatible.

Evidence: Running backup jobs, heartbeat monitoring, Prometheus metrics.

Customer expectation: In normal operation, a new backup run is created each hour.

Not covered: No point-in-time recovery and no guarantee across network, host, or customer-side failure.

AES-GCM encryption with customer-held key

Backup data is encrypted before storage with AES-GCM and the key stays on the customer side.

Scope: Encrypted backup storage without server-side plaintext access.

Preconditions: The customer must provide and manage the key correctly.

Evidence: Implemented encryption path; no server-side access to plaintext backup data.

Customer expectation: Backup data in the Resistro storage path is not stored unencrypted.

Not covered: No key recovery and no broader security guarantee beyond this storage-path claim.

Daily restore test

Resistro runs a daily restore-path test as an operating check so the defined restore path does not silently break.

Scope: A daily operating check of the defined restore path.

Preconditions: Restore-test jobs must run as scheduled and the operating environment must be available.

Evidence: Scheduled restore-test job, monitoring, Telegram alerting on failure.

Customer expectation: Resistro regularly checks that the restore mechanism still works as designed.

Not covered: No daily full emergency validation of every customer database and no application-level consistency check.

Alerting after >25h without valid backup state

Resistro alerts if there has been no valid backup state for more than 25 hours.

Scope: Backup-failure alerting based on heartbeat and monitoring data.

Preconditions: Heartbeat, monitoring, and alerting infrastructure must all be functioning.

Evidence: Alert rules, heartbeat checks, Telegram-based alerting.

Customer expectation: Silent backup failure should not remain unnoticed for more than roughly one day.

Not covered: No 24/7 support, no reaction-time guarantee, and no guarantee against outages outside the Resistro monitoring path.

Daily /healthz smoke test

Public product paths are checked daily for basic reachability.

Scope: A daily smoke test against the public health endpoint.

Preconditions: The infrastructure and health endpoint must be reachable.

Evidence: Daily smoke test against `/healthz`.

Customer expectation: Basic reachability of central public product paths is checked every day.

Not covered: No uptime SLA and no comprehensive end-to-end guarantee for all customer functions.

RPO around one hour

The target RPO is around one hour in normal operation.

Scope: A target derived from the hourly backup rhythm and monitoring.

Preconditions: Hourly backups need to run successfully without a longer disruption chain.

Evidence: Backup cadence plus monitoring, without hard SLA language.

Customer expectation: Potential data loss in normal operation is bounded to roughly one hour.

Not covered: No hard SLA and no guarantee for failures between backup windows or during extended disruption.

Manual operator-assisted restore

Restore is a controlled manual operation with operator support, not a self-service workflow.

Scope: Manual restore handling when a valid backup exists and operational restore is possible.

Preconditions: A valid backup must exist and the restore can be carried out operationally.

Evidence: Restore process and daily restore-path test.

Customer expectation: Restore is a supervised operational process rather than a push-button action.

Not covered: No support SLA, no fixed RTO, and no self-service restore portal.

Boundaries

Explicitly not covered

No point-in-time recovery
No uptime SLA
No support SLA
No database-version migration in the restore path
No statement for MySQL
No statement for managed database platforms such as RDS or Supabase
No enterprise requirements outside the defined ICP

Operator context

Who runs this

Alexander Renz is a Linux administrator, the founder of Resistro Cloud, and a small business owner since April 28, 2026. He operates the infrastructure himself and keeps the public promise intentionally bounded to what is real in production today.

Promise boundaries

If a statement is not represented on this page, it should not be read as part of the current promise.