saasups reads a repository, maps its components and the AWS services they need, prices three target tiers and prepares a reviewed deployment bundle. The saasups team applies it in your AWS account, with your approval. The examples on this page are illustrative and shaped like real output.
Give saasups a public GitHub repository URL. It reads the repository over the GitHub API without cloning it, identifies the components, their languages and dependencies, and assigns each component a 7-R strategy with its rationale. A component the evidence cannot place gets no strategy rather than a default.
Private repositories, source archives and multi-repository projects are agreed in a technical demo.
A deterministic scorecard from configuration and manifests. No language model is called.
The scan-only evidence plus repository context, read by a language model that reasons over the evidence package rather than raw files.
The structural read over a wider slice of the repository, with subdirectory discovery and a per-component pass on multi-module repositories.
| Component | Kind | 7-R | Workload |
|---|---|---|---|
| api | HTTP service | Replatform | transaction heavy |
| worker | background jobs | Rehost | bursty |
| web | static front end | Replatform | light |
| postgres | database | Replatform | io intensive |
| redis | cache | — | light |
Each service in the plan is marked confirmed when a file-cited signal or finding backs it, or inferred when it follows from the component's workload and the architect's rationale. The map is derived from evidence the assessment already captured; no model is asked to invent it.
A confirmed service is a cited need, not a provisioning promise; see what the bundle generates below.
The same component inventory is sized three ways: cost-optimized consolidates light components onto shared compute in a single availability zone; production right-sizes each workload with multi-AZ data; high availability adds replicas, read replicas and headroom everywhere. Supporting services are billed once per tier, not once per component.
An estimate is not an AWS bill. It depends on region, sizing, traffic and reserved-plan assumptions, all of which are printed next to it.
Shared compute, single AZ, smallest sizes
$412/mo
Right-sized per workload, multi-AZ data
$1,180/mo
Replicas and multi-AZ everywhere, headroom sizing
$2,460/mo
Monthly, Annual, Three-year figures, with a deep link into the AWS Pricing Calculator. Illustrative figures. An estimate is not an AWS bill.
Compute paths: Amazon EC2 with Auto Scaling and Amazon EKS. Data stores are encrypted at rest with AWS-managed keys.
From the chosen tier saasups generates an OpenTofu/Terraform bundle, a continuous-delivery workflow for your CI, and a starter Dockerfile per language where the repository has none. Generated files carry a do-not-edit header; the files meant for you to edit say so.
A generated Dockerfile is a reviewable starter, never a build the launch chain will ship unreviewed.
CI workflow forGitHub ActionsGitLab CIJenkinsAWS CodePipeline
Dependencies are sorted topologically and bucketed into waves; stateful components go into the foundation wave so stateless services can rely on them. Each wave gets a cutover runbook in Markdown, and the operator console produces an executive summary alongside it.
Wave plans and runbooks are produced on the operator side and shared as Markdown. The customer workspace has no dependency graph view and no document export.
Runbook per wave: Scope · Pre-cutover · Cutover · Validation · Rollback · Post-cutover. Executive summary alongside, as Markdown.
The saasups team applies the approved plan in your AWS account, with your approval. Nothing is applied from a button in a customer workspace: a plan is previewed, every hard blocker must be explicitly accepted with a reason, a named operator approves that exact plan by fingerprint, and only then does the runner apply it.
Supported compute paths are EC2 with Auto Scaling and EKS. Services the plan prices but the bundle does not generate are listed by name in the bundle's warnings.
Review access and deployment controlsYou launch a CloudFormation stack in your account. It creates the IAM role saasups assumes, gated by an ExternalId.
A plan preview runs against your account. Its summary and cost are what the approval refers to.
On your decision. Every unaccepted hard blocker stops the deploy; acceptance records a reason code.
A named operator approves this exact plan by fingerprint. A plan that drifted cannot ride an earlier approval.
The runner applies through the cross-account role, in your account.
Read-only view of the live estate.
Requires the deployment identifier typed back and checked server-side.
Email and password with mandatory two-factor authentication: a TOTP app plus encrypted backup codes, reset with a saasups operator. Sign-in is rate-limited, and approvals, applies and destroys are written to an audit log.
Access & controlThe vision extends this context into continuous AI SRE and FinOps, controlled intervention and remediation pull requests. These are roadmap capabilities and are not part of today's workflow.
Discuss your codebase, target architecture and delivery requirements in a technical demo.
Have an open-source application? Request a public repo assessment.
Requests are reviewed before analysis. Public reports are published with your consent.
