Back to blog
ClauseMindsProduct6 min read

Customer-owned deployment: running ClauseMinds in your cloud accounts

customer-owned deploymentClauseMinds Enterpriseself-hosted contract softwareSupabase Vercel Railway deploymentmanaged private deployment vs customer cloudcontract obligation platform deployment
Creative team working together with laptops on deployment and infrastructure planning
Product6 min read
customer-owned deploymentClauseMinds Enterprise

Enterprise teams can install ClauseMinds into their own Supabase, Vercel, and Railway projects with a guided setup wizard, encrypted provider tokens during provisioning, and handoff when you are ready. Here is how it differs from managed private deployment and when to choose it.

Key takeaways
  • Customer-owned deployment runs ClauseMinds in cloud projects the customer controls—Supabase for database and storage, Vercel for the frontend, Railway for API and workers—rather than only on ClauseMinds-managed dedicated infrastructure.
  • Enterprise teams use a guided setup wizard after operator approval: connect providers, validate credentials, run provisioning and health checks, then complete handoff. Setup tokens are encrypted during the window and purged afterward.
  • It complements managed private deployment (Growth and Enterprise): managed means we operate the stack; customer-owned means your org holds the cloud relationships and configuration.
  • v1 does not automatically migrate existing shared-SaaS data; plan uploads and cutover with your implementation team.

Some security questionnaires stop at “dedicated environment.” Others ask which cloud accounts hold contract files, extracted text, and application metadata, and who can access provider consoles. Customer-owned deployment exists for that second case.

On this path, ClauseMinds installs into your Supabase project, your Vercel project, and your Railway project. You retain direct relationships with those providers for billing, regions, backups, and compliance artifacts. ClauseMinds provides the same obligation intelligence product—uploads, review queue, governing truth, actions, calendar—with the runtime tied to your infrastructure.

This article explains what the v1 flow includes, how it differs from managed private deployment, and how to start the conversation with sales when procurement or InfoSec requires full cloud ownership.

Two Enterprise-grade boundaries: managed vs customer-owned

Managed private deployment provisions a dedicated ClauseMinds environment on infrastructure we host and operate. You get isolated URLs, database, and object storage without running cloud projects yourself. Growth workspaces can request it when eligible; Enterprise can use it as well.

Customer-owned deployment is the step further: the same product semantics, but Supabase, Vercel, and Railway resources live in accounts your organization creates and pays for. That is often the cleanest answer when policies require subprocessors to be limited to named providers under your enterprise agreements—or when your platform team standardizes on specific regions and backup tooling.

Neither option in v1 silently copies an existing shared tenant into the new stack. Teams should plan what to re-upload, which workspaces to recreate, and when to cut over communications and integrations.

  • Managed private: ClauseMinds operates the dedicated stack; request from Billing when your plan allows.
  • Customer-owned: you operate the cloud projects; ClauseMinds guides install and validation after approval.
  • Both: workspace RBAC, traceability, and review workflows match the standard product behavior.

What the setup wizard expects (v1)

After sales and operations enable the feature, a workspace admin requests customer-owned deployment from Billing. When the request is approved, the wizard unlocks for connecting each provider.

You will attach a Supabase project for Postgres and Storage, a Vercel project for the web application, and a Railway project for backend services and workers as needed for your processing configuration. The UI walks through validation so misconfigured credentials surface early instead of during production traffic.

Provider tokens used during setup are stored encrypted and are purged when you complete final handoff, reducing long-lived third-party access from ClauseMinds into your accounts.

Security and procurement talking points

Customer-owned deployment shifts more operational responsibility to your organization: you configure provider-side encryption, backup policies, and access to cloud consoles. ClauseMinds still ships application-level tenancy, upload validation, and structured logging practices that avoid unnecessary contract content in logs—but the data plane is yours.

External AI posture remains a deliberate choice. Dedicated and customer-owned environments align with teams that want model providers off by default and opt-in only after review.

For subprocessors, your answers often become simpler for application data at rest because primary storage sits in your Supabase project rather than a multi-tenant bucket shared across unrelated customers.

When to choose customer-owned deployment

Choose it when cloud account ownership is non-negotiable for legal, risk, or platform standards, and you have staff who can own Supabase, Vercel, and Railway day-two operations—or partners who will.

Choose managed private deployment when you need isolation and a crisp vendor boundary but prefer ClauseMinds to run and patch the environment.

If you are unsure, it is reasonable to pilot managed private deployment first and plan customer-owned as a later phase once workflows are trusted.

After go-live: ownership and support boundaries

Once the wizard completes, your platform team typically owns provider-level changes: scaling plans, region moves, backup retention, and IAM to cloud consoles. ClauseMinds continues to ship application updates through the same release channels you use today, with compatibility expectations documented per major version.

Support tickets should clearly separate “application behavior” from “infrastructure in your project.” That speeds triage when an upload fails because storage permissions drifted versus when review queue logic regressed in a release.

Document internal runbooks for credential rotation, disaster recovery drills, and who approves provider upgrades—especially when procurement requires change windows aligned with enterprise standards.

Explore ClauseMinds

Continue with product pages and feature guides that connect this topic to the wider ClauseMinds workflow.

FAQ

Is customer-owned deployment the same as self-hosting every dependency from source?

No. It is a supported install into standard ClauseMinds cloud targets (Supabase, Vercel, Railway) with a guided wizard—not an arbitrary on-prem compile-your-own stack. Different shapes may be discussed under Enterprise services agreements.

Can we migrate automatically from the shared ClauseMinds app?

v1 does not automatically migrate existing workspace data. Treat cutover as a planned project: export what you need, re-upload contracts, and align users on the new URLs.

Who can request customer-owned deployment?

It is an Enterprise option enabled per workspace after commercial and security review. Workspace admins request it from Billing once the capability is turned on for their organization.

Does customer-owned deployment change how obligations and review work in the app?

No. Workspace RBAC, obligation extraction, review queues, governing truth, timelines, and actions behave like the standard product. The difference is where Postgres, object storage, and the web/API runtimes are hosted—not the product semantics teams see day to day.

Related reading

See how ClauseMinds handles this in practice

ClauseMinds is built for source-grounded obligation extraction, human review, governing truth, deadline tracking, and operational follow-through across legal ops, procurement, finance, and operations.

    Customer-owned deployment: running ClauseMinds in your cloud accounts — ClauseMinds Blog