Backend contract
Spala supports PostgreSQL product databases, published REST endpoints, managed product authentication, backend workflows, and staging or production database environments.
Trust center
Know what works before you commit.
Spala makes backend resources inspectable before publish. This page separates verified product behavior from the assurances that still depend on your project, plan, or contract.
Current product
What is verified today.
These statements are backed by current implementation and tests in the Spala product. They describe platform capability, not automatic correctness for every generated project.
Review and publish
Executable resources have draft and published states. Published artifacts are integrity checked, and invalid runtime snapshots fail closed instead of loading silently.
Frontend handoff
Projects can produce JSON and Markdown API docs, OpenAPI, JavaScript and TypeScript SDK output, and request snippets. Generated docs still need live route testing.
Project MCP
Authorized project-scoped MCP supports inspection, builder changes, validation, publishing, and review. It requires the configured browser, OAuth, or token flow.
Export surfaces
Spala exposes project, data, and packaged runtime exports, including JSON, CSV, and runtime ZIP output. Secret-bearing bundles require secure handling.
Production correctness
Authentication, tenant isolation, CORS, webhooks, migrations, and failure behavior must be accepted against the actual project before launch.
Exact boundaries
What we do not ask you to assume.
Clear limitations are part of a useful product evaluation. They prevent a platform feature from being mistaken for a customer-specific guarantee.
- 01AI generation is assisted, not autonomous assurance.
The hosted builder includes planning, generation, validation, repair, and publish gates, but complex one-prompt production generation is not currently proven reliable.
- 02Public MCP discovery is not project mutation.
The public endpoint exposes product and documentation tools. Public project listing and handoff currently fail closed. Use an authorized project MCP configuration for project work.
- 03Exports do not make Spala open source.
Runtime and data exports exist, but the Spala product itself is not open source. Export capability is also not a promise of a frictionless migration to every other platform.
- 04Snapshots are not disaster-recovery backups.
Project snapshots intentionally exclude database rows, uploads, environment secrets, database configuration, runtime artifacts, and encryption keys. Production recovery needs separate backups.
- 05No blanket security or compliance guarantee.
Spala has authentication, authorization semantics, static analysis, and sandbox validation. It does not publicly claim SOC 2, ISO 27001, HIPAA, or vulnerability-free operation.
- 06No public formal SLA or uptime history.
The reliability page and status JSON are evaluation aids, not an uptime guarantee, incident archive, or account-specific support commitment.
Evaluation plan
Run one representative workflow.
A small proof is more useful than a generic checklist. Choose a workflow that includes identity, data ownership, a write, a protected read, and a frontend handoff.
- 01Model the real roles and data.
Define the user types, tenant boundary, sensitive fields, and the two or three records that must stay connected.
- 02Inspect every generated resource.
Review the PostgreSQL schema, auth behavior, endpoint inputs, validation, workflow effects, and draft or published state.
- 03Test success and denial paths.
Exercise valid requests, invalid data, missing auth, wrong-user access, wrong-tenant access, CORS, and retry behavior.
- 04Verify the handoff.
Open the generated docs and SDK, then connect a small frontend path using the exact API base URL and authentication contract.
- 05Confirm commercial requirements.
Before production, document backups, restore, deletion, export, support, incident communication, compliance, and managed-delivery terms for your account.
Test Spala against your actual app.
Start with a low-risk workflow, or scope a managed build when you want the Spala team involved in implementation and handoff.