Fail-closed publish loading
Published resources are integrity and shape checked. Invalid integrity, sandbox, or topology prevents a bad published snapshot from loading.
Reliability
Publish deliberately. Recover deliberately.
Spala validates published resources and records execution detail, but production reliability also depends on your database, backups, monitoring, support agreement, and acceptance tests.
Runtime safeguards
What Spala provides.
These platform mechanisms make project state and failures easier to inspect. They are not a substitute for a customer-specific recovery plan.
Draft and published state
Executable resources distinguish working drafts from the published state that is eligible to run.
Execution visibility
Spala records execution history, logs, debug and variable snapshots, background work, agent metrics, and AI build run ledgers.
Database switch rollback
Database switching includes connection preflight, introspection, runtime reconnect, and rollback on failure. Customer migrations still need rehearsal and backups.
Frontend activation rollback
A project can stage, validate, activate, serve, and roll back a static frontend package under its isolated runtime path.
Complete operations stack
No complete distributed tracing, external alerting service, historical uptime platform, formal incident archive, or public SLA is currently proven.
Recovery boundary
A snapshot is not a backup.
Spala project snapshots protect selected project definition state. They intentionally do not contain everything required to recover a production system.
Included in project-state recovery
- Project metadata and supported resource definitions
- Draft and published configuration state covered by the snapshot flow
- A controlled way to return editor resources to a known project state
Requires a separate backup plan
- PostgreSQL rows and database recovery
- Uploaded files and external service data
- Environment secrets and encryption keys
- Runtime artifacts and infrastructure configuration
Production requirement: define database, upload, secret, and infrastructure backups separately. Rehearse a restore before relying on the system for revenue-critical data.
Acceptance run
Test the failure path, not only the happy path.
A reliability review should prove that the app fails visibly, protects data, and has a known recovery owner.
- 01Baseline every public surface.
Check the dashboard, selected project API, documentation, and any project MCP connection from the account that will operate them.
- 02Exercise retries and duplicate delivery.
Test network timeouts, repeated form submissions, duplicate webhooks, background-task retries, and partial external-service failures.
- 03Publish and roll back a controlled change.
Record the previous state, publish a representative resource set, verify behavior, and demonstrate the documented rollback route.
- 04Restore real data in staging.
Prove database and file restore using your own backup system. A project snapshot alone is insufficient.
- 05Write down ownership and escalation.
Confirm monitoring, log retention, incident notification, support channel, response expectations, and who can publish or restore.
Match operations to the cost of failure.
Use the public status snapshot for a quick signal, then confirm account-specific uptime, backup, restore, incident, and support requirements in writing.