--- title: "Technical Proof of Concept (PoC)" description: "Deploy your application on STACKIT: tenancy strategy, landing zone, resilience requirements, the architectural blueprint, cost tracking and IaC pipelines." sidebar: label: "Technical PoC" order: 6 attrs: data-icon: cloud-arrow-up source_url: "https://framework.stackit.cloud/isv/technical-proof-of-concept/" source_file: "docs/isv/technical-proof-of-concept.mdx" --- The Technical Proof of Concept (PoC) phase is where your architectural planning becomes reality. The goal of this phase is to deploy a working version of your application on STACKIT to validate technical feasibility, performance, and cost-efficiency before moving toward a production-ready state. ## Deployment Strategy & Landing Zone A critical decision before rolling out your infrastructure is defining your tenant strategy. This decision heavily impacts your STACKIT Organization, Folder, and Project structure: - **Multitenant Strategy**: Multiple customers share the same infrastructure and application instance, separated logically. ![Multitenant folder and project structure](./files/multitenant-strategy.svg) - **Customer Dedicated (Single Tenant)**: Each customer receives an isolated STACKIT Project and infrastructure environment. ![Dedicated folder and project structure](./files/dedicated-strategy.svg) **Accelerate your setup.** To support a fast, automated, and standardized rollout of your cloud environment, STACKIT provides Infrastructure-as-Code (IaC) assets: - **Landing Zone Accelerator** — best-practice templates for setting up your STACKIT environment. Dedicated Landing Zone repositories tailored specifically for Multitenant and Customer Dedicated models are planned: github.com/stackitcloud/stackit-landing-zone - **STACKIT GitHub Repositories** — open-source projects, Terraform providers, and SDKs: github.com/stackitcloud ## Resilience, Scaling, and Compliance When building your PoC, you must design for growth, stability, and security: {/* prettier-ignore */} 1. **Scaling**: How does your application architecture scale to handle sudden user growth or increased workloads without performance degradation? 2. **Redundancy & High Availability (HA)**: Define your availability requirements. Does your application require a Single-Region setup, or do you need a Multi-Region architecture to prevent downtime? 3. **Compliance (TOMs)**: By signing the Partner Base Agreement (PBA), your organization technically committed to the Technical and Organizational Measures (TOMs) outlined in Annex 2. Your PoC architecture must reflect and implement these security and data protection standards. ## Architectural Blueprinting & Target Design Once you have defined your deployment model, isolation strategy, and resilience requirements, translate these specifications into a formal **Architectural Blueprint**. Mapping your software components (microservices, stateful data, caching layers, external interfaces) directly to STACKIT services — such as SKE, PostgreSQL Flex, Object Storage and STACKIT Network Area — creates a clear target architecture. This blueprint serves as the essential foundation for precise infrastructure cost modeling and subsequent automation via IaC. ## Infrastructure Calculation & Cost Tracking With your Architectural Blueprint defined, model and track your resource consumption against your initial business case estimations: - **Computing Calculator** — model your estimated monthly compute, network, and storage footprint for the target PoC architecture: calculator.stackit.cloud/computing - **STACKIT Price List** — reference for a complete overview of all SKUs, as some newer platform services may not yet be reflected in the calculator. ## Infrastructure as Code (IaC) & CI/CD Pipelines To achieve high reliability and low operational overhead, manual infrastructure provisioning via the portal should be avoided for production-grade software. Infrastructure as Code (IaC) is the state-of-the-art industry standard for cloud-native deployment. ### Infrastructure as Code Using declarative tools ensures your infrastructure is repeatable, version-controlled, and audit-ready: - **Primary Tooling**: Use the official STACKIT Terraform Provider to declare compute, storage, network, SKE (Kubernetes), and database resources: registry.terraform.io - **Automation-First**: Maintain all IaC scripts within version control (e.g., GitHub, GitLab, STACKIT GIT). - **STACKIT Git Pipelines**: If you host your repositories on STACKIT Git, the built-in pipelines run your IaC and build workflows next to the code — the first-steps guide walks through the initial runner and workflow setup: docs.stackit.cloud — Pipelines first steps ### Recommended CI/CD Pipeline Architecture A standardized Continuous Integration / Continuous Deployment (CI/CD) pipeline automates the lifecycle of both your infrastructure and application workloads. {/* prettier-ignore */} 1. **Code Commit & Trigger**: Changes to application code or IaC templates trigger the automated pipeline. 2. **Linting & Static Security Analysis**: Validate Terraform configurations (`terraform validate`, `tflint`) and scan container images for vulnerabilities — either by running Trivy directly as a pipeline step, or by relying on the vulnerability scans the STACKIT Container Registry performs on pushed images. Running both gives you a gate in the pipeline and continuous rescanning of images already stored. 3. **Infrastructure Provisioning (IaC Step)**: Run `terraform plan` for automated verification, followed by `terraform apply` to provision or update STACKIT resources in the target PoC environment. 4. **Workload Deployment**: Deploy application containers to STACKIT Kubernetes Engine (SKE) with Helm as the packaging format — either driven by the pipeline through the Terraform Helm provider (keeping infrastructure and workload in one declarative run), or pull-based via a GitOps engine such as Argo CD or Flux that reconciles the chart from your Git repository. Avoid imperative `kubectl apply` steps, as they leave no reconcilable desired state. PaaS applications are deployed via Cloud Foundry (`cf push`). 5. **Automated Integration Testing**: Execute smoke tests against the freshly deployed endpoints to verify service availability. 6. **Secrets Management**: Ensure pipeline runners access STACKIT service accounts via short-lived API tokens or integration with STACKIT Secrets Manager — never hardcode API keys or credentials in repositories. 7. **STACKIT Container Registry**: Central registry for your build artifacts, including vulnerability scanning of pushed images: docs.stackit.cloud — Container Registry ## Phase Completion Criteria The PoC phase is complete when the following milestones are verified: - [ ] Target Architectural Blueprint established and mapped to STACKIT services. - [ ] Application is successfully deployed and running in the STACKIT PoC project. - [ ] Infrastructure provisioning is automated using IaC (e.g., Terraform / Landing Zone Accelerator). - [ ] Tenant isolation strategy (Multitenant or Customer Dedicated) is implemented in the folder/project hierarchy. - [ ] PoC environment costs calculated and discussed with the Partner Manager. - [ ] Automated CI/CD deployment pipeline is established. - [ ] Security and compliance controls (PBA Annex 2 TOMs) are technically validated. - [ ] **Milestone achieved**: PoC validated — ready to proceed to the [ES³ Self Assessment](/isv/es3-self-assessment/). ## Support & Contact Throughout the PoC phase, use the following resources to support your development: - **STACKIT Knowledge Base** — technical documentation, API references, and practical tutorials: docs.stackit.cloud - **STACKIT Status Page** — real-time information on platform availability and system maintenance: status.stackit.cloud **Need assistance?** If you encounter technical blockers during your PoC, contact your Partner Manager or the ISV Factory team at `isv-sales@digits.schwarz`.