Private SaaS

Text size

Private SaaS

Private SaaS runs StackGen in your AWS, Azure, or Google Cloud account. You own the cloud resources and application data. StackGen operates the application and delivers upgrades through a pull-based GitOps workflow.

Architecture

StackGen runs in a dedicated Kubernetes cluster. PostgreSQL and object storage also run in your account.

Argo CD polls a Git repository dedicated to your environment and syncs changes to the in-cluster Kubernetes API. StackGen does not require inbound network access to the cluster to deliver a release.

StackGen encrypts Kubernetes secrets with the public certificate from your Sealed Secrets controller. Only the controller in your cluster can decrypt them.

Network and IP address sizing

These are the reference values StackGen deploys by default. Confirm the final numbers with StackGen, because per-release capacity and your own scale can change them.

	AWS	Azure	Google Cloud
VPC or VNet	/16	/16	/16
Node subnets	3 private /20, one per availability zone	One /18 system subnet, one /18 user subnet	3 private /20, one per zone
Edge subnets	3 public /24 for NAT and the load balancer	Included in the subnets above	3 public /24 for NAT and external load balancing
Database subnet	Shares the private tier	Delegated /24	Private Service Access range for Cloud SQL
Pod addresses	Allocated from the private subnets	Allocated from the user subnet	Secondary range, /16 by default
Service addresses	Cluster-internal	Cluster-internal	Secondary range, /20 by default

A /16 gives room to grow and is the simplest option. If your address space is limited, plan the minimum from pod density rather than node count:

• AWS and Azure assign pod IP addresses from your subnets. Allow roughly 50 pod addresses per node, so a 6-node cluster needs about 300 to 400 usable addresses plus node, load balancer, and NAT addresses. A /22 per node subnet is workable, and /20 leaves headroom.
• Google Cloud takes pod and service addresses from secondary ranges, so the node subnets stay small. Keep the secondary ranges non-overlapping with any connected network.
• All ranges must avoid overlap with networks you peer, route, or connect by VPN.

Kubernetes compute sizing

	AWS	Azure	Google Cloud
Node size	m7g.2xlarge, 8 vCPU and 32 GiB, ARM64	Standard_B8ms user pool, 8 vCPU and 32 GiB, plus a Standard_D2as_v4 system node	e2-standard-8, 8 vCPU and 32 GiB
Node count	3, autoscaling to 6	4 user nodes and 1 system node	4, autoscaling to 6
Baseline compute	24 vCPU and 96 GiB	34 vCPU and 136 GiB	32 vCPU and 128 GiB
Peak compute	48 vCPU and 192 GiB	34 vCPU and 136 GiB	48 vCPU and 192 GiB
Node disk	256 GiB gp3	60 GiB user, 128 GiB system	60 GiB pd-balanced

Plan for roughly 32 vCPU and 128 GiB of schedulable capacity in a production environment, and keep one node of spare capacity so rolling upgrades do not exhaust the cluster.

Reference database sizing:

• AWS: Amazon RDS db.t4g.medium, 20 GiB growing to 200 GiB, Multi-AZ.
• Azure: PostgreSQL Flexible Server B_Standard_B2s, 32 GiB.
• Google Cloud: Cloud SQL db-custom-2-4096, which is 2 vCPU and 4 GiB, with 32 GiB storage.

Object storage starts small and grows with your usage. Size it from your retention policy rather than a fixed number.

Responsibilities

You own:

• The cloud account, subscription, or project.
• Network design, firewall policy, DNS, and TLS certificates.
• The Kubernetes cluster, PostgreSQL service, and object storage resources.
• All data in your databases and object storage.
• The identity-provider application, credentials, and redirect URIs.
• The decision to expose StackGen through a public or internal load balancer.
• Backup, retention, and disaster recovery policy for customer-owned data services.
• Any infrastructure access that you grant for installation or support.

StackGen owns:

• StackGen chart versions, GitOps manifests, and application images.
• Application configuration and release updates in the deployment repository.
• Sealing application secrets with your Sealed Secrets public certificate.
• Read credentials for StackGen container images.
• Application upgrades through GitOps.
• Application support within the access and diagnostic information you provide.

Network requirements

The cluster initiates all deployment traffic. Allow outbound HTTPS to:

• The GitHub organization that hosts your deployment repository.
• ghcr.io for StackGen application images.
• Your identity provider.

If you use the packaged in-cluster PostgreSQL option on a supported cloud, also allow registry.devopsnow.io, or mirror that image into an approved registry.

Other destinations depend on the features you enable:

• Your selected AI provider, such as OpenAI, Anthropic, Gemini, or Azure OpenAI.
• SendGrid for email notifications.
• Langfuse for LLM tracing.
• Unleash for remotely managed feature flags.
• GitHub, GitLab, Azure DevOps, or Bitbucket for project Git configurations.

Azure and Google Cloud deployments currently use cert-manager with Let's Encrypt HTTP-01 for automatic certificate issuance. That flow requires public DNS and inbound ports 80 and 443. Discuss customer-provided TLS certificates with StackGen if the service must remain internal.

Set up SSO

Users sign in to StackGen through your identity provider. Local password login is not used.

Supported providers are Microsoft Entra ID, Google, and GitHub. Confirm any other identity provider with StackGen before you select this deployment model.

1. Create an application registration

Create an OAuth application for StackGen in your identity provider.

Microsoft Entra ID

1. In the Microsoft Entra admin center, go to App registrations and select New registration.
2. Enter a name, such as StackGen, and select the account types your organization requires.
3. Add a Web platform under Authentication and enter the redirect URI from step 2 below.
4. Under Certificates & secrets, create a client secret and copy its value immediately.
5. Copy the Application (client) ID from the Overview page, and the OAuth 2.0 token endpoint (v1) from Endpoints.

For screenshots, group claims, and role mapping, follow Configure your Microsoft Entra ID OAuth 2.0. Use your own StackGen hostname in the redirect URI instead of the Managed SaaS example.

Google

1. In the Google Cloud console, open APIs & Services > Credentials for the project that owns your workspace applications.
2. Select Create credentials > OAuth client ID and choose Web application.
3. Add the redirect URI from step 2 below under Authorized redirect URIs.
4. Copy the generated client ID and client secret.

GitHub

1. In your GitHub organization settings, open Developer settings > OAuth Apps and select New OAuth App.
2. Set the homepage URL to your StackGen hostname.
3. Set the authorization callback URL to the redirect URI from step 2 below.
4. Generate a client secret and copy its value.

2. Register the redirect URI

Add this redirect URI to the application, replacing the hostname with your StackGen hostname:

https://<stackgen-domain>/auth/callback

3. Restrict and assign access

Decide which users reach StackGen, then assign them in your identity provider. For Microsoft Entra ID, create groups or app roles that match the StackGen Admin, DevOps, and Developer roles, and assign users or groups to them.

4. Share the details with StackGen

Provide the following through your agreed secure channel:

• Client ID and client secret.
• The identity provider and tenant or organization name.
• For Microsoft Entra ID, the tenant-specific OAuth endpoints.
• The email address for the first StackGen administrator.
• Any group or role claim mapping you configured.

StackGen completes the authentication configuration in your environment. Rotate the client secret before it expires and send the new value to StackGen.

Automatic group membership synchronization is not enabled by default. Confirm requirements with StackGen if you need identity-provider groups to drive StackGen access. For in-product group management, see User Groups.

Included services and integrations

AI integrations are optional. If you enable them, you provide credentials for the selected provider. Azure infrastructure can optionally provision Azure OpenAI, but your onboarding team must configure the application endpoint and credentials separately.

Product Git integrations are separate from the deployment repository. StackGen uses the deployment repository to update the platform. Your projects use Git configurations to publish generated infrastructure code.

Email notifications use SendGrid in the current package. SMTP is not configured.

Cloud differences

AWS

• Amazon EKS runs application workloads in private subnets.
• Amazon RDS for PostgreSQL and Amazon S3 provide data services.
• An AWS Network Load Balancer can be internet-facing or internal.
• AWS Certificate Manager terminates TLS at the load balancer.
• Mountpoint for Amazon S3 CSI uses IAM Roles for Service Accounts.

Azure

• Azure Kubernetes Service uses separate system and user node pools.
• Azure Database for PostgreSQL or packaged in-cluster PostgreSQL provides the database.
• Azure Blob Storage provides shared object storage.
• NGINX terminates TLS in the cluster.
• Azure OpenAI can be provisioned as an optional private resource.

Google Cloud

• Google Kubernetes Engine uses private worker nodes and Cloud NAT for outbound access.
• Cloud SQL for PostgreSQL or packaged in-cluster PostgreSQL provides the database.
• Cloud Storage FUSE provides shared object storage.
• NGINX terminates TLS in the cluster.
• The default Cloud SQL configuration is zonal. Request a high-availability design if your recovery requirements need it.

Review and complete the Private SaaS prerequisites checklist with your cloud, network, security, and identity teams.