Current operational status
API uptime (24h)
Health uptime (24h)
Live data from status.resistro.org — updated in real time, not cached by this page.
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.
1h default Postgres backup baseline
Resistro Cloud backs up Postgres databases on a 1h default agent interval for small self-managed Postgres setups in the defined ICP.
Scope: Configured backup cadence for supported self-managed Postgres setups; the default agent interval is 1h.
Preconditions: The customer system must be reachable, correctly attached, technically compatible, and the configured backup interval must be allowed by the active plan.
Evidence: Running backup jobs, heartbeat monitoring, Prometheus metrics.
Customer expectation: In normal operation with the default agent setup, a new backup run is created roughly each hour.
Not covered: No point-in-time recovery and no guarantee across network, host, or customer-side failure.
MySQL/MariaDB backup and restore path
Resistro Cloud supports backup upload, download, decrypt, and restore-drill verification for small self-managed MySQL and MariaDB setups in the defined ICP.
Scope: Logical dump and restore path via the Resistro agent for supported self-managed MySQL and MariaDB databases.
Preconditions: The customer system must be reachable, correctly attached, technically compatible, and the configured backup interval must be allowed by the active plan.
Evidence: Production E2E on June 27, 2026 covered MySQL and MariaDB backup, encrypted upload, download, decrypt, restore, and checksum match.
Customer expectation: For supported self-managed MySQL and MariaDB setups, the backup and restore-drill path works through Resistro Cloud.
Not covered: No point-in-time recovery, no physical/native backup guarantee, no database-version migration, and no statement for managed database platforms.
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.
EU-only storage without the US-provider CLOUD Act path
Resistro stores backup data with Hetzner in the EU instead of using a US cloud provider with an EU region.
Scope: Backup storage path through Hetzner as a German provider with EU data-center locations.
Preconditions: The customer uses the standard Resistro storage path; custom storage architectures would need separate review.
Evidence: Current storage provider Hetzner Online GmbH; public privacy notices identify Hetzner as hosting provider.
Customer expectation: For DACH procurement checks, there is no US-provider CLOUD Act path as with AWS, Azure, or Google Cloud EU regions.
Not covered: No legal advice, no immunity from lawful German or European authority requests, and no statement for customer-side third-party storage.
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.
Stale-backup alerting after roughly one day
Resistro alerts when monitoring sees no successful backup signal for longer than the current 28h stale threshold.
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 beyond roughly one day under the monitored path.
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 guarantee 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 configured backup interval and monitoring.
Preconditions: Backups need to run successfully without a longer disruption chain.
Evidence: Backup cadence plus monitoring, without hard guarantee language.
Customer expectation: Potential data loss in normal operation is bounded to roughly one hour.
Not covered: No hard uptime or data-loss 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 guarantee, no fixed RTO, and no self-service restore portal.
Customer-triggered restore drills
Customers can trigger restore drills on demand to verify the restore path for their own databases.
Scope: On-demand drill triggering against the customer's own backup data.
Preconditions: A valid backup must exist for the selected database.
Evidence: Drill trigger endpoint, drill result logging, compliance PDF generation.
Customer expectation: A restore drill verifies that the restore path works for the customer's data at the time of the drill.
Not covered: A drill is not a production restore and does not constitute a backup guarantee beyond the verified restore path.
Compliance PDF export
After a restore drill, Resistro generates a downloadable compliance PDF documenting the result.
Scope: PDF export of drill result as audit evidence.
Preconditions: A restore drill must have been completed successfully.
Evidence: PDF generated from drill result data including timestamp, database, and outcome.
Customer expectation: The PDF provides structured evidence of a completed restore drill for audit or internal compliance purposes.
Not covered: Not a legal certification. Does not cover production restore outcomes or PITR.
Deduplicated agent uploads
The Resistro agent deduplicates repeated backup data before upload, reducing storage and transfer volume.
Scope: Client-side deduplication for repeated data blocks across backup runs.
Preconditions: Requires the Resistro agent at a version that includes deduplication support.
Evidence: Dedup agent upload path active in production.
Customer expectation: Unchanged data blocks are not re-uploaded on subsequent backup runs.
Not covered: No compression guarantee beyond deduplication. Does not apply to first-run or fully changed datasets.
Explicitly not covered
- No point-in-time recovery today
- No uptime guarantee with service credits
- No support response-time guarantee
- No database-version migration in the restore path
- No MySQL/MariaDB point-in-time recovery or physical/native backup guarantee today
- No statement for managed database platforms such as RDS or Supabase
- No hard requirements outside the defined ICP
- No legal advice on CLOUD Act, GDPR, or third-country-transfer assessment
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.
Next steps
Get started or dig deeper
Open the app, inspect live status, or review the legal documents that support the current offer.
Promise boundaries
If a statement is not represented on this page, it should not be read as part of the current promise.