Service Management
A service is a complete backend — schema, API, database, and (when hosted) a deployment. This page is the feature overview: how services are created and the sections that manage them. Each section has its own reference, linked below.
Lifecycle
- Create a service from a prompt (below).
- Design the schema in the Schema Editor.
- Deploy it (hosted plans) to get a live API.
- Manage it from the service detail sections — dashboard, data, logs, API keys, settings.
Creating a service
Creation is prompt-based, from the workspace Service List → Create Service (/{workspace}/services/new):
- Describe the backend you want in a prompt; the AI derives a service name and generates the initial schema.
- Sample prompts (e.g. “SaaS Essentials”) pre-fill common starting points.
- You can attach files or import an Excel spreadsheet to seed the schema from existing structure.
The create flow is a prompt/AI + import experience — it is not a “pick a template (Blank / SaaS Starter / API Only)” wizard. The template-selection steps described in manage/services.mdx do not match the current UI; treat this page as the accurate create flow.
Service detail sections
Open a service to reach its detail sections. The tabs are gated by plan and deployment:
The detail tabs (Dashboard, Data, API Keys, Docs, Logs) are shown only for hosted plans with a deployed service. Self-hosted services show only the Editor — you own and run the generated code, so the hosted-only surfaces (metrics, data browser, hosted logs, in-app API keys) don’t apply.
| Section | Purpose | Reference |
|---|---|---|
| Editor | Visual schema design (+ AI chat) | Schema Editor |
| Dashboard | Runtime metrics (hosted) | Service Dashboard |
| Data | Browse records in the deployed database (hosted) | — |
| API Keys | Create/revoke service API keys (hosted) | API Key Management |
| Logs | Recent service logs (hosted) | — |
| Deployments | Deployment history | — |
| Environment | Environment variables/config | Environments |
| Docs | Generated API documentation (hosted) | — |
| Settings | Name, members, plan, GitHub, deletion | Service Settings |
Access, monitoring, and billing
- Access control — per-service roles (Owner / Admin / User / ReadOnly), managed in Service Settings → Members. Granular per-service assignment is a Business-plan capability.
- Monitoring — metrics, logs, and top endpoints on the Service Dashboard; platform reliability in Monitoring.
- Plan & billing — compute tiers and add-ons in Service Settings → Plan & Add-ons. Authoritative pricing lives on the billing page (the client’s tier table is illustrative; catalog reconciliation is tracked in
mavric/apso-platform-server#134).
Some items in the tracking issue are intentionally out of scope here: user-flow diagrams are deferred (see issue #12), and finalized plans/pricing depend on the Stripe-catalog reconciliation (#134). The Data browser, Logs viewer, and Deployments sections are not yet documented in depth and are good candidates for follow-up component pages.