Runtime & deployment
This is the technical core of the operating requirements: how your application has to be built and packaged so the platform can run it.
Your application runs in one of four runtime types without code changes, deploys, upgrades and rolls back fully automated from a declarative definition, delegates login to the platform's IAM, keeps its secrets in the platform Vault, survives restarts, and tells the platform how it is doing.
Runtime types
The platform offers four runtime types. Your application must support at least one of them, or a combination, and it must run there without code changes. Parameterisation is permitted.
| Runtime type | Typical fit |
|---|---|
| Managed Containers | Containerised applications that don't need Kubernetes-level control |
| Kubernetes / Cloud Native | Applications shipped as Helm charts or manifests, needing K8s primitives |
| Codesphere Reactives | Applications run directly from the repository via a Landscape definition |
| Virtual Machines | Applications that cannot (yet) be containerised |
Cloud agnosticism is mandatory. The application must not have hard dependencies on cloud-provider-specific managed services or proprietary cloud APIs. Dependencies of this kind are usually the largest piece of adaptation work.
Confidential Computing
Applications must be compatible with the platform's Confidential Computing standards: encryption of data at rest, in transit and in use. What that means for you depends on the runtime type:
- Managed Containers, Codesphere Reactives and the platform's managed services: conformity is handled by the platform. Nothing to do.
- Kubernetes and Virtual Machines: you are responsible for conformity with the platform's Confidential Compute standards yourself.
Deployment
The platform deploys your application from a Landscape definition, a complete, declarative description of build, configuration and execution. Deployment happens by executing that definition, and nothing else:
- Deploy, upgrade and rollback run fully automated in the platform's DevOps environment, repeatably: a second run produces the same result.
- No manual intervention on host systems.
- Configuration exclusively via parameters, values, CRDs or environment variables. No config baked into images, no hand-edited files on servers.
- No secrets in the container image or source code. Secrets are drawn from the platform's Vault service at runtime.
Artefacts live in openCode
Deployment artefacts must be versioned in the specified openCode Git repository or its registry, and may only be sourced from there. External registries are not part of the production deployment path. Access to the DevOps environment is granted exclusively through openCode accounts.
Domain and TLS come from the platform
Your application is reached under a domain provided by GovTech, with SSL certificates provided by GovTech. It must not require its own domains or certificates, and it uses the platform's TLS termination rather than bringing its own transport security.
External connections need approval
Every outbound connection your application makes, such as APIs it calls or services it depends on, must be documented and expressly approved by GovTech before the application goes into operation.
Identity and access management
Your application uses the platform's central Identity and Access Management service. Concretely, it must support:
- OIDC / OAuth2 integration: login is delegated to the platform's IAM; no parallel, application-own authentication
- Claims mapping: platform-issued claims map onto your application's roles and permissions
- Logout: ending the session actually ends access
Your role and permission model must be documented comprehensibly.
Where the application requires it, directory integration (AD/LDAP) should be possible through platform mechanisms. Whether it is required for your application is settled in the Leistungsbeschreibung (Anlage 1).
Data storage and persistence
Two legitimate ways to hold data:
- Use a platform managed service: the platform offers a selection of databases (e.g. PostgreSQL) as managed services.
- Bring your own database as part of the application: permitted, but then you deploy and manage it yourself.
Either way:
- Backup and restore must work, run regularly, and be traceably documented.
- Database schema migrations must be executable in an automated way and documented.
Availability, resilience and scaling
- No single points of failure in critical components
- Robust against pod restarts, rolling updates and node failures: the application recovers on its own, without data loss and without manual intervention
- Stateful components designed for resilience: state survives restart and relocation
- Resource requests and limits, security level and scaling boundaries are stated, together with recommendations for Horizontal Pod Autoscaling
Observability and supportability
| Requirement | Level |
|---|---|
| Structured logging via the platform's logging service | Must |
| No sensitive data or secrets in logs | Must |
| Documented, working health checks (liveness/readiness) | Must |
| Runbooks for operations and incident handling | Must |
| Prometheus-compatible metrics | Should |
| Defined service level indicators (error rate, latency, throughput) | Should |
| Distributed tracing via OpenTelemetry | Should |
The should items are not admission-relevant on their own, but they simplify service reporting and incident response considerably.
What must demonstrably work
Before an application is admitted, the platform verifies operational readiness in its development and operations environment:
- Automated provisioning including deploy, upgrade and rollback
- Security checks passed, where the platform exercises its testing rights (details)
- Observability demonstrated: logs, health checks, metrics
- A successful restore/recovery test
- RTO/RPO capability validated against the profile targets (details)
The RTO and RPO values you demonstrate are fixed contractually. Architectural constraints cannot be raised against them afterwards.
General guidance. The binding requirements are in the contract documents of your procedure, which may contain further or more specific requirements.