> For the complete documentation index, see [llms.txt](https://docs.digitalapi.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.digitalapi.ai/marketplace/concepts/concept-architecture.md).
# Architecture & platform
Astra splits cleanly into two planes: a management plane that decides policy and reads metadata, and a data plane that enforces that policy on every live call. Understanding this split, the product family around it, and the stack it runs on explains how the marketplace publishes an API without ever standing in the request path.
### Management plane vs data plane
Astra is the management plane and stays out of the request path. The gateway is the data plane and terminates every live call. The same concern is split across the two: Astra defines a plan's limits and the gateway enforces them; Astra provisions a credential and the gateway validates it on every call; Astra reads usage and the gateway meters it.
What each plane owns
* **Management plane (Astra):** imports specs and metadata, governs by scoring specs against a ruleset, publishes the catalogue, defines products and plans, manages subscription state and approvals, provisions app credentials, and reads usage for analytics.
* **Data plane (gateway):** authenticates the credential or API key, enforces rate limits and quotas, routes to the backend, applies security and traffic policy, meters usage, and allows or rejects each call in real time.
### The product family
Three products form one path from publishing an API to consuming it. Marketplace manages and configures the gateway, then publishes its catalogue to the Developer Portal. Consumers subscribe in the portal; their apps then call the gateway directly. Astra Gateway is first-class, and third-party gateways federate the same way.
What each product does
* **Astra Marketplace:** the provider control plane that federates gateways, governs and publishes, manages products, plans, and subscriptions, and provides provider analytics.
* **Astra Gateway:** the data plane that terminates live calls, authenticates credentials, enforces limits and policy, and meters usage.
* **Developer Portal:** the consumer experience, a branded catalogue for discovering, subscribing, getting keys, and tracking usage.
### The technology stack
Astra is built on Drupal CMS and PHP, deployed on Kubernetes, and multi-tenant by design so that every data access is scoped to its tenant. The stack runs in five layers, from the experience consumers touch down to the platform it all runs on.
What each layer holds
* **Experience:** Developer Portal (Drupal / Twig theme), API Studio test console, MCP servers, API GPT assistant.
* **Application:** PHP 8.4 services, plugins and event subscribers, governance and rating engines, the subscription state machine.
* **Data:** PostgreSQL 17, cache bins, Queue API for async usage, billing, and email.
* **Integration:** gateway connectors, billing adapters, identity (Okta OAuth2 / SAML SSO).
* **Platform and DevOps:** Docker Compose locally, Kubernetes at runtime, GitHub Actions CI/CD.
The ecosystem is open across gateways (Astra Gateway, Apigee, Kong, APISIX, AWS, Azure APIM, IBM), spec and repo sources (SwaggerHub, GitHub, Bitbucket, Postman), identity (Okta, Azure AD, SAML SSO), billing adapters (Stripe, Kill Bill, Zuora, Chargebee), and an AI layer (MCP servers, API GPT assistant).
### Deployment models
The same multi-tenant codebase ships in three operating models, so you can pick the one that fits your security and compliance needs:
* **SaaS:** DigitalAPI-hosted, fully managed and multi-tenant, with upgrades handled for you. Best for teams that want zero ops.
* **Private cloud:** single-tenant and dedicated, running in your AWS, Azure, or GCP account with VPC isolation. Best for stricter isolation and control.
* **On-premises:** single-tenant and self-hosted in your data centre, with full data residency and air-gap capability on customer-managed Kubernetes. Best for regulated and sovereign workloads.
> **How-to:** for step-by-step configuration, see the How-to guides.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.digitalapi.ai/marketplace/concepts/concept-architecture.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.