Skip to main content
7 min read

Private SaaS prerequisites checklist

Private SaaS prerequisites checklist

Complete this checklist with your cloud, network, database, identity, and security teams. Share the completed copy with StackGen before deployment.

StackGen confirms supported Kubernetes versions, capacity, and cloud service versions during the architecture review.

Deployment details​

  • Cloud provider: AWS / Azure / Google Cloud
  • Region:
  • Account ID / subscription ID / project ID:
  • Environment name:
  • StackGen hostname:
  • Production or non-production:
  • Customer technical owner:
  • Customer security owner:

Cloud and access​

  • A dedicated cloud account, subscription, or project is available.
  • The team applying the infrastructure has approved permissions for networking, Kubernetes, IAM, database, object storage, DNS, certificates, and secrets.
  • The access method for StackGen-assisted installation is approved.
  • The access method for ongoing support is approved, or support will use customer-exported diagnostics only.
  • Cloud audit logging is enabled for administrative actions.
  • Resource quotas cover the agreed Kubernetes, load balancer, database, storage, IP address, and NAT resources.

Record approved identities:

  • AWS role ARNs:
  • Azure groups or service principals:
  • Google Cloud users, groups, or service accounts:

Network​

Reference sizing: a /16 VPC or VNet, three private /20 node subnets on AWS and Google Cloud, /18 system and user subnets on Azure, and three public /24 subnets for NAT and load balancing. See network and IP address sizing for smaller address plans.

  • VPC or VNet CIDR is approved:
  • Private subnet CIDRs for Kubernetes nodes are approved:
  • Database subnet CIDRs are approved:
  • Pod and service CIDRs do not overlap connected networks:
  • Roughly 300 to 400 usable addresses are available for pods at peak node count, on AWS and Azure:
  • NAT or another approved outbound path is available to private worker nodes.
  • Public or internal load balancer is selected:
  • Users and administrators can route to the StackGen endpoint.
  • Firewall rules allow the cluster to reach PostgreSQL, object storage, DNS, and the identity provider.
  • Network inspection or proxy requirements have been shared with StackGen.

Outbound allowlist​

  • HTTPS access to the customer deployment repository on GitHub is allowed.
  • HTTPS access to ghcr.io is allowed for StackGen images.
  • Access to the selected identity-provider endpoints is allowed.
  • registry.devopsnow.io is allowed if the packaged in-cluster PostgreSQL image is used, or the image will be mirrored.
  • Optional AI, email, tracing, feature flag, and project Git destinations have been reviewed.

Record proxy URL and certificate trust requirements, if any:

DNS, ingress, and TLS​

  • The StackGen hostname and DNS zone owner are identified.
  • The load balancer is approved as internet-facing or internal.
  • A TLS certificate and private-key handling process are approved.
  • AWS: the ACM certificate ARN and Route 53 zone are available, if applicable.
  • Azure or Google Cloud: public DNS and ports 80 and 443 are available for Let's Encrypt HTTP-01, or a customer-certificate design is agreed with StackGen.

Record:

  • Hostname:
  • DNS zone:
  • Certificate source and renewal owner:
  • Load balancer type:

Kubernetes and GitOps​

Reference sizing: nodes with 8 vCPU and 32 GiB, such as m7g.2xlarge on AWS, Standard_B8ms on Azure, or e2-standard-8 on Google Cloud, giving about 32 vCPU and 128 GiB of schedulable capacity. See Kubernetes compute sizing.

  • A dedicated EKS, AKS, or GKE cluster will be provisioned or is available.
  • Cluster capacity and node architecture match the StackGen-approved sizing.
  • Spare capacity of at least one node is available for rolling upgrades.
  • Argo CD is installed and healthy.
  • The Sealed Secrets controller is installed and healthy.
  • The Sealed Secrets public certificate has been exported and can be shared with StackGen.
  • Argo CD can read the deployment repository and sync to the in-cluster Kubernetes API.
  • Container image pull credentials can be stored as a Sealed Secret.
  • Kubernetes and add-on ownership, patching, and alerting are assigned.

Record:

  • Cluster name:
  • Kubernetes version:
  • Node architecture:
  • Node instance or machine type:
  • Minimum and maximum node count:

PostgreSQL​

  • Managed PostgreSQL or packaged in-cluster PostgreSQL is selected.
  • AWS deployments use Amazon RDS for PostgreSQL.
  • The database administrator can create the StackGen application databases.
  • Private cluster-to-database connectivity is tested.
  • Encryption at rest and in transit meets your policy.
  • Backup retention, point-in-time recovery, and restore testing are defined.
  • High availability and read replica requirements are agreed.
  • Database credentials can be provided through the approved secret process.

Record:

  • Database type and version:
  • Endpoint and port:
  • High-availability mode:
  • Backup retention:
  • Restore owner:

Object storage​

  • An S3 bucket, Azure Blob container, or Google Cloud Storage bucket is available.
  • The bucket or container is private and encrypted.
  • Workload identity or the approved storage credential is configured.
  • StackGen workloads can list, read, write, and delete objects as required.
  • Retention, backup, lifecycle, and deletion policies are approved.

Record:

  • Bucket, container, or storage account:
  • Region:
  • Encryption key owner:

SSO​

  • Identity provider: Google / GitHub / Microsoft Entra ID
  • An application registration for StackGen is created in the identity provider.
  • https://<stackgen-domain>/auth/callback is registered as a redirect URI.
  • Users or groups are assigned to the application.
  • Client ID and client secret are available through the approved secret process.
  • The initial StackGen administrator email is confirmed.
  • Microsoft Entra ID tenant endpoints are recorded, if applicable.
  • Role or group claims have been reviewed with StackGen.
  • The team understands that automatic group synchronization is not enabled by default.

Record:

  • Identity provider:
  • Tenant or organization:
  • Administrator email:
  • Client secret rotation owner and date:

Optional integrations​

  • AI provider and credential owner are identified, if AI features will be enabled.
  • SendGrid and approved sender details are identified, if email notifications will be enabled.
  • Project Git providers and token requirements are identified.
  • Langfuse or Unleash endpoints are identified, if enabled.
  • Data residency and outbound traffic for each optional service are approved.

Operational readiness​

  • Monitoring and alert routing are agreed.
  • Incident contacts and support access are agreed.
  • Database and object storage recovery procedures are tested.
  • Credential rotation owners are assigned.
  • Maintenance windows and release communication contacts are recorded.
  • The final architecture and completed checklist have been reviewed with StackGen.

See Private SaaS for the architecture and responsibility split.

Last updated on