Solutions · For SaaS vendors
Your product. In your customer’s cloud.
Build a repeatable delivery model for customers who need your software inside their own cloud account. Start with a defined deployment pattern and a clear split of responsibilities.
- Customer AAWS · eu-west-3healthyRunning v2.4, healthy.
- Customer BAWS · us-east-1healthyRunning v2.4, healthy.
- Customer CAWS · eu-central-1healthyRunning v2.4, healthy.
- Customer DAWS · ap-southeast-2awaiting approvalStill on v2.3, awaiting the customer’s approval.
- Customer EAWS · eu-west-1healthyRunning v2.4, healthy.
- Customer FAWS · ca-central-1healthyRunning v2.4, healthy.
- Deployment model
- One environment per customer account
- Access
- A scoped role each customer grants
- Releases
- Planned per account, approved per account
- Status
- Pilot use case
The problem
Every customer install should not be a project.
Enterprise buyers ask for your software inside their account. Done by hand, each install is a new runbook, a new security review and a new on-call surface. Here is the shape we work toward with you.
Without: Each install is rebuilt from a wiki page.
With Kapten: One packaged application shape, provisioned per account.
NavigatorArchitectureWithout: Security reviews start from a blank questionnaire.
With Kapten: An access request listing each permission and why.
WardenSecurity reviewWithout: Updates ship to customers one by one, by hand.
With Kapten: A release planned per account, approved by its owner.
HelmsmanReleasesWithout: Cost questions land in your support queue.
With Kapten: An estimate the customer reviews against their own cloud commitments.
PurserCostWithout: Nobody is sure who handles an incident.
With Kapten: A runbook and responsibility matrix handed over at install.
KaptenOrchestration
How it works
Make the next customer deployment familiar.
Bring a repeatable application shape
Identify the services, data stores and configuration your product needs. Use that shared architecture as the starting point for each customer environment.
Separate customers deliberately
Agree account ownership, region and access for each deployment. Keep customer-specific configuration and credentials scoped to the environment they belong to.
Plan how you will operate the fleet
Define who releases updates, investigates incidents and maintains the infrastructure. A repeatable install needs a repeatable operating model behind it.
Workflows
Start from a recipe built for this.
Each workflow names the specialists it brings in and where it stops to ask you. Copy the prompt into your agent, or read the run step by step.
All workflowsInstall into a customer’s cloud
Deploy your product into an enterprise customer’s own account with a repeatable shape, a scoped role and a clear split of responsibilities.
› Prepare an install of our product in Globex’s AWS account, eu-central-1. They will create the role. Generate the access request and the plan.
- Navigator
- Warden
- Purser
- Bosun
- Helmsman
Security posture audit
A read-only review of what is exposed, what holds secrets and who can reach what, with a fix proposed for every finding.
› Audit the security posture of all environments in project “atlas”. Look for public databases, leaked secrets and anything wider than it needs to be.
- Warden
- Navigator
- Kapten
Database migration rehearsal
Run a risky schema migration against a restored copy of production first, measure it, and only then schedule the real one.
› Rehearse migration 0042_split_orders against a copy of production. Tell me how long it locks, and whether the previous release still works after it.
- Bosun
- Helmsman
- Lookout
- Kapten
The crew on this job
Who does what, for you.
Every specialist has a narrow job and a boundary. Nothing reaches your account without a plan you approved.
Meet all eight specialists- NavigatorArchitecturePackages the services and data stores every install needs.
- WardenSecurity reviewWrites the access request for the customer’s security team.
- PurserCostSizes each install and prices it in the customer’s account.
- BosunInfrastructureProvisions in the customer’s account and region, once the role exists.
- HelmsmanReleasesReleases and verifies, account by account.
- KaptenOrchestrationHands over a runbook and a split of responsibilities.
Read before you start
Guides and papers for this path.
- Ownership by designBring-your-own-cloud as an architecture for SaaS teams and the customers they serve.Read the whitepaper
- Plan your first customer-cloud deploymentDefine the account, access model and operating responsibilities before bringing your SaaS into a customer’s infrastructure.
- Guardrails for agents that touch productionScopes, approval tokens, named owners, budget caps, a scoped cloud role and an audit trail in your own account, and why plans are the defence against prompt injection.
- Rollbacks that survive a schema migrationAn image rollback re-points traffic to old code. It does not un-migrate your database. How to make releases you can actually undo.
FAQ
A few practical questions.
Do customers have to share one cluster?
No single topology suits every SaaS. Start with the required customer isolation and choose an account and environment model that matches it.
Can this help with enterprise requirements?
Running in the customer’s account can support their ownership and residency requirements. Their security review still needs to cover access, data handling and operating responsibilities.
Can we roll an update out to every customer at once?
Automated fleet rollout is not something we promise today. In the pilot, releases are planned and approved per customer account. Tell us how you ship updates now and we will scope what fits.
Keep exploring
See how it fits together.
Build with Kapten
Start with one service.
Build from there.
Tell us what you want to deploy. We review each request and follow up about fit and onboarding on your preferred cloud.
Free during early access. No card required. Cloud usage billed separately.