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 Run for application hosting
Cloud SQL for PostgreSQL for the database
Cloud KMS for key custody
Cloud Storage only when the customer wants a GCP-native storage boundary
Vertex AI only 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.