Choosing your deployment path
When a customer orders your application in the Customer Portal, the platform must be able to create a new instance — or a new tenant, if your application is multi-tenant — fully automatically, through the platform's unified interface for Managed Services. No tickets, no manual configuration, no intervention on your side or ours. Where your application requires a licence key, generating and applying it is part of that automation.
There are two ways to meet that requirement. Decide which one applies to you before you start building: it shapes the whole integration, and switching later is expensive.
Path A — Landscape blueprint
The preferred path. Your repository carries a fully tested, idempotent ci.yml — the Landscape blueprint. The platform deploys, configures and scales new instances from that blueprint alone, repeatedly and without manual intervention.
Choose this when
Your application is single tenant and can be deployed as a set of containers, platform managed services and/or Reactives. A new instance can be created by adjusted configuration.
What you deliver
ci.yml— tested and idempotent. If you maintain several execution profiles, state explicitly which one production runs.provider.yml— registers the application with the platform's unified Managed Services interface.- Configuration supplied entirely through environment variables and secrets, never baked into the image.
What you get
- No direct interaction with Kubernetes at any point.
- Confidential Computing handled by the platform, not by your application.
- Instance creation, configuration and scaling driven from the blueprint alone.
Path B — Custom Provider
If provisioning your application needs something a Landscape blueprint cannot express — dedicated vClusters, a centralised multi-tenant instance, or allocating API keys in an external system — you provide a Provider Backend. It implements the platform's unified Provider API (provider.yml plus a REST API) and manages the lifecycle of those resources autonomously.
Choose this when
You have deep infrastructure, Kubernetes and operational knowledge, and creating a new customer instance cannot be achieved via Path A.
What you deliver
- A service implementing the Provider API across the full resource lifecycle — create, read, update, delete.
- Operation and availability of that backend, since the platform depends on it to provision your application.
provider.ymlto register it.- Enabling your application to support Confidential Computing.
Ask us for the Provider API specification before you start down this path.
Which one applies to you
| If this describes your application | Path |
|---|---|
| A new customer instance is your containers, deployed again with different configuration | A |
| Tenants are separated within one Landscape, or each customer gets their own Landscape | A |
| Each customer needs a dedicated cluster | B |
| Provisioning has to allocate credentials or capacity in a third-party system | B |
| You run one central multi-tenant instance and add tenants to it | B |
If your case is not clearly on one side, raise it with us rather than deciding alone.
Whichever path you take, the application registers through provider.yml. A listing in the GovTech Store is only possible once that registration is validated and the complete deployment sequence has been shown to run reliably from end to end.