We build each customer stack, the platform runs the shared services, and your apps supply product logic.
Each app lists the platform services and AWS resources it needs in one versioned file. Plans choose how much of a customer’s stack is shared or dedicated, our provisioning service builds it, and the Control Plane, where operators set plans and settings, gives the running services their configuration.
Layer 01 · Operator plane
Fleet
Provisions and upgrades each client stack, including the database topology and supported AWS resources selected by its plan. Fleet has its own sign-in and domain and stays outside the tenant request path, so operator actions and deployment failures stay within the affected stack.
Layer 02 · Your own platform stack
Platform
The full platform, bounded per client, with its own database, event-stream and cache boundaries, so resource contention stays inside that stack. Managed connection pooling handles database sessions, and Large and Extra Large deployment tiers add database readers without changing the application contract.
Layer 03 · Your SaaS, plus ours
Apps
Each app declares events, authorization resources, audit types, notifications, plan features and infrastructure in one versioned app declaration. Publishing registers it with the platform. Apps use standard sign-in (OIDC) and event (CloudEvents) formats, typed configuration and authorization checks, which keeps them portable if the deployment changes.
Shared by default, dedicated app by app
Every customer starts on shared infrastructure. Any app a customer runs can move to its own database server, compute, Redis cache and Kafka cluster, for scale or for isolation, when its plan or a paid add-on says so, and back again when that ends. Nobody on your team provisions, migrates or tears down by hand, so you can serve a very large customer on its own infrastructure without building a separate product for it.
- 01
Give each app its own resources
Each app a customer runs can get its own database server, compute, Redis cache and Kafka cluster, at the size you choose. Put them in a plan, or let a customer buy them as a monthly add-on on the subscription they already have.
- 02
Paid first, then provisioned
Nothing is provisioned until the payment is confirmed. Then the platform creates the resource and moves that customer’s workspace onto it, with no ticket and no console step.
- 03
Upgrade, resize or downgrade with the plan
When the subscription changes, the platform compares what the customer is entitled to with what they run, and makes the move: from shared to dedicated, to a larger size, or back to shared. Dedicated compute also scales out on its own, up to the maximum you set, as that app’s load grows.
- 04
Cancel or expire without leftovers
A cancelled add-on keeps its resource until the paid period ends. Then the workspace moves back to shared and the dedicated resource is removed. If a move fails, the add-on is withdrawn and the unused time is credited.
A starter kit hands you code; a platform runs your product
Starter kits and backend services provide application code. Your team still operates identity, tenant isolation, scaling, billing and compliance controls. SynaptaGrid supplies and operates those shared systems.
Review the platform against your deployment requirements
Review the architecture, Control Plane, versioned app contract and AWS resources required for your tenant model.