Identity
Tenant-aware identity
Companies, workspaces, memberships, sessions, and invitations live behind a dedicated product boundary.
Enterprise delivery
Win enterprise trust without surrendering your foundation.
Give architecture, security, and procurement teams a backend they can inspect: source-owned services, explicit boundaries, customer-cloud deployment, and responsibilities documented before rollout.
Availability, acceptance criteria, evidence, and support targets are documented before purchase.
01 / Buyer review
The foundation enterprise stakeholders can inspect.
Product depth matters, but so does the delivery boundary around it. Launch Rail makes both visible before the pilot begins.
Authz
Central policy decisions
Roles, relationships, and resource decisions remain enforceable across services—not only in the interface.
Trust Center
Reviewable security inputs
Data flows, tenant boundaries, attributable audit events, and shared responsibility support your own review program.
By agreement
Defined support path
Onboarding, upgrade guidance, escalation, named contacts, and response targets are written into the proposal.
Golden path
Customer-controlled AWS
Deployment runs from your environment with customer-held credentials and reviewable infrastructure artifacts.
Custom module
Product-specific development
Missing domain capabilities and integrations can be scoped as first-class ecosystem work with explicit acceptance criteria.
02 / Deployment
One polished path now. Other models stay honest.
Customer-owned AWS is the current golden path through the design-partner pilot. Managed Cloud and broader targets remain visible without being presented as ready.
Design-partner pilot
Customer-owned AWS
Deploy from your environment into your AWS account using generated artifacts and ambient credentials. Your team retains responsibility for cloud policy, operations, backups, and regional choices.
- Customer-held credentials
- Reviewable infrastructure plan
- Source and version lockfile
- Shared-responsibility handoff
Deployment flow
01Plan
02Review
03Deploy
Planned
Managed Cloud
A future operating model for teams that prefer Launch Rail to run the stack. It is not sold as available today.
- Roadmap visibility only
- Release gate required
- Terms still to be defined
Planned
GCP and isolated environments
Additional cloud and isolated-network delivery require separate validation instead of implied parity with AWS.
- Architecture review first
- Dependency inventory
- Support boundary by agreement
03 / Support and procurement
Commercial expectations written down before rollout.
Support channels, response targets, custom work, evidence, and acceptance criteria follow the proposal—not an implied public SLA.
Support model
Final targets are proposal-defined.
Module source license
Support requests
Response target
Proposal-defined
Custom work
Separately scoped
Complete ecosystem
Email + control plane
Response target
Proposal-defined
Custom work
Available as add-on
Custom delivery
Named channel by agreement
Response target
Custom target
Custom work
Priority scope
Your team owns
The source, the deployment, and the product decision.
- Licensed Go source and product-specific changes
- Customer data and the supported AWS environment
- Generated infrastructure artifacts
- Update adoption, pinning, and testing decisions
- Product integrations and operating policy
- The customer experience built on top
Launch Rail maintains
The release and support system around the foundation.
- Module releases and compatibility guidance during support
- Shared service conventions and blueprint dependencies
- Documented deployment and recovery paths
- Security advisories and signed release metadata
- A roadmap gated by repeated customer demand
Start with the real requirements
Bring us the architecture, security, and procurement questions.
We'll map them to available modules, the customer-owned AWS path, existing evidence, and any explicit gaps before a pilot begins.