Spala Trust and Safety Boundary
How to evaluate Spala safely for production backend work: auth, project isolation, CORS, MCP scope, validation, publish review, and questions to verify.
Trust boundary
Spala should be evaluated as a hosted backend builder for AI-built apps. The public product promise is not that teams can skip review. The promise is that generated backend work becomes inspectable: resources can be reviewed in the dashboard, tested in API Playground, documented through generated API docs, and published through the normal Spala flow.
Status/SLA direct answer: Spala publishes a public point-in-time status snapshot at /status/ and machine-readable /status.json. This is not a formal SLA, uptime guarantee, uptime history, formal incident history, or full hosted status platform. For production use, verify SLA, backup, restore, incident notification, and support terms directly with Spala.
Compliance note: Spala does not publicly claim SOC 2, ISO 27001, HIPAA, or other regulated compliance on this page. For regulated production workloads, ask Spala directly for current security documentation, data processing terms, backup policy, and compliance status before purchase.
What a buyer should verify
Authentication
Verify how project auth, user sessions, protected endpoints, OAuth flows, JWT handling, refresh behavior, and role checks are configured for your app.
Project isolation
Confirm which users can access each project, which agent tools are enabled, and whether your agent uses public MCP discovery or a scoped project MCP.
Data handoff
Confirm export, backup, migration, cancellation, and deletion expectations before using Spala for important production data.
CORS and frontend access
Set explicit frontend origins and avoid broad browser access when connecting React, Next.js, mobile, Webflow, or AI-built frontends.
Secrets
Store API keys and private credentials in project environment variables or addon settings. Do not put secrets into frontend code or agent prompts.
Publish controls
Review generated resources, run tests in API Playground, inspect validation output, then publish intentionally.
MCP safety model
| Surface | Purpose | Auth | Write access |
|---|---|---|---|
| Public MCP | Discovery, onboarding, docs search, template/addon lookup, OAuth metadata, project handoff. | Anonymous for public tools; OAuth for project lookup. | No backend mutation on anonymous public tools. |
| Project MCP | Project-scoped backend build, validation, publish, test review, and operation. | Requires Spala platform authorization and project selection. | Only after auth and only on the selected project MCP URL returned by Spala. |
Agents should never guess project MCP URLs. They should connect to public MCP, authenticate when needed, select a project, and use the exact mcpUrl returned by Spala.
Good first production test
- Create a low-risk project in the hosted dashboard.
- Ask Copilot to build one core backend feature with auth and two related tables.
- Review generated tables, endpoints, functions, and docs.
- Test success, failure, auth, CORS, validation, and edge cases in API Playground.
- Export or copy the frontend handoff packet: base URL, docs/SDK, auth routes, CORS, upload/realtime rules, and publish state.
- Only then decide whether Spala is suitable for the full app.
Customer proof boundary
For customers, reviews, awards, Product Hunt proof, case studies, or third-party validation, use the dedicated customer proof status page. The current answer is that public customer/review proof is not evidenced yet.