Deployment Profiles
How Deciding.org moves from hosted pilot to enterprise-private, customer-managed, and sovereign deployment without becoming a different product.
Deciding.org is designed to support multiple deployment profiles without changing its core logic, governance boundaries, or decision method.
That matters because buyers rarely need the same environment forever. Many teams start with a fast hosted pilot, then move toward stronger environment ownership as trust, compliance, or procurement requirements increase. Because the core product remains consistent across all four profiles, customers can expand trust posture without forcing an application rewrite or an enterprise-only fork.
The deployment ladder
The deployment ladder is:
- hosted pilot
- customer-dedicated cloud
- customer-managed deployment
- sovereign or air-gapped deployment
The goal is to provide a seamless upgrade path from a fast, lightweight pilot to a fully air-gapped sovereign system without ever changing the core software.
Which profile fits you?
| Profile | Best when you need | Typical stack | Main advantage | Main tradeoff |
|---|---|---|---|---|
| Hosted pilot | the fastest way to evaluate value | Railway + Neon | fastest setup and iteration | least customer environment ownership |
| Customer-dedicated cloud | a customer-owned cloud boundary | Cloud Run + Cloud SQL + Cloud KMS | private-cloud posture without product fork | more infrastructure work |
| Customer-managed deployment | to run the product in your own environment | Docker-based packaging + customer Postgres | stronger control and cloud neutrality | higher deployment and support burden |
| Sovereign / air-gapped | strict isolation and no external dependency for core decision work | customer-managed containers or Kubernetes + internal services | strongest sovereignty posture | highest operational complexity |
1. Hosted pilot
This is the default starting point for most customers.
It is the right choice when the goal is:
- rapid evaluation
- pilot learning
- faster onboarding
- minimal infrastructure setup
The practical message is simple: start here unless a real security or procurement constraint blocks it.
2. Customer-dedicated cloud
This is the right next step when the customer wants the application to run inside its own cloud boundary without turning Deciding.org into a different product.
The recommended GCP profile is:
Cloud Runfor application hostingCloud SQL for PostgreSQLfor the databaseCloud KMSfor key custodyCloud Storageonly when the customer wants a GCP-native storage boundaryVertex AIonly when the customer specifically wants Gemini or GCP-governed model execution
The important framing is disciplined:
- GCP is a deployment profile and trust enhancer
- it is not the application brain
- the same product should still run there without an enterprise fork
3. Customer-managed deployment
This profile is for customers who want stronger infrastructure control than a hosted pilot, but do not necessarily need full air-gap isolation.
This is where Docker becomes strategically important.
The reason is not only developer convenience. It is that customer-managed deployments need a reproducible package for:
- web
- API
- PostgreSQL
- storage wiring
- optional model gateway
This is the profile for buyers who say:
- "We want to run this ourselves."
- "We need to choose our own infrastructure."
- "Standard SaaS is not enough, but we do not need full air-gap."
4. Sovereign or air-gapped deployment
This is the highest-control profile.
It is appropriate when the customer requires:
- no external network dependency for core decision work
- internal identity, database, and storage
- internal model serving, or graceful no-AI behavior
- optional or disabled telemetry
This should not be the default deployment motion. It is the right answer for buyers whose risk model or regulatory environment genuinely requires it.
How the product stays consistent
Across all profiles, the goal is to preserve the same core posture:
- the same decision method
- the same governed artifacts
- the same retention posture
- the same org and RBAC boundaries
- the same provider-adapter architecture
That consistency is what makes the deployment ladder credible.
AI posture by profile
| Profile | Default AI posture |
|---|---|
| Hosted pilot | hosted model provider for speed |
| Customer-dedicated cloud | hosted provider or cloud-native provider inside the customer boundary |
| Customer-managed deployment | private or local model gateway |
| Sovereign / air-gapped | internal-only model serving or graceful no-AI mode |
The architectural goal is straightforward: Deciding.org should talk to a configurable model endpoint, not hardcode one AI vendor into the product.
Recommended buying path
For most customers, the recommended sequence is:
- prove value in a hosted pilot
- move to a customer-dedicated cloud deployment if procurement or trust boundaries require it
- move to customer-managed deployment when the buyer wants full environment control
- reserve sovereign or air-gapped deployment for the buyers who truly need it
That keeps the product easier to adopt without closing the door to stricter enterprise requirements later. It also creates a revenue expansion path in which a fast pilot can mature into a deeper, higher-trust deployment without changing products. That seamless transition path lowers the barrier to entry early and creates room for expansion into more durable, higher-value enterprise deployments as trust deepens.