Skip to main content

​
Deployment Models

Choose a deployment model before planning networking, secrets, data flows, and operational ownership. The local repository setup is a development environment; it is not a packaged self-hosted production distribution.

​
Supported paths

ModelCurrent statusConto operatesYour organization operates
Hosted ContoSupported defaultApplication, database migrations, service monitoring, and platform updatesUsers, agent credentials, wallets, policies, approvals, webhook consumers, and incident contacts
Dedicated tenantEvaluated with Conto before implementationThe agreed isolated Conto environment and platform updatesThe same application-level responsibilities as hosted Conto, plus agreed network connectivity
Local developmentSupported for evaluation and contributionNothing in your local environmentNode.js, PostgreSQL, secrets, email behavior, migrations, seed data, and all local operations
Customer-operated productionNot currently offered as a turnkey distributionNoneEverything; no supported Docker Compose, Helm, Kubernetes, or Terraform package is currently provided
Do not infer production support from the ability to run the source repository locally. If your architecture requires customer-operated infrastructure, confirm that requirement before designing the integration.

​
Hosted architecture boundary

The hosted product exposes the dashboard, REST/OpenAPI endpoints, SDK and MCP integration surfaces, webhooks, and testnet workflows. Your organization retains control of:
  • which people and agents receive credentials;
  • wallet custody mode and funding;
  • policy values, approval routing, and counterparty configuration;
  • storage and rotation of API, SDK, webhook, and wallet secrets;
  • webhook availability, replay handling, and downstream accounting or ERP integration;
  • authorization to enable live funds.
Conto operates application deployment, schema migration, and the hosted service dependencies. A customer integration should treat Conto as an external service and implement timeouts, idempotency, retry limits, request-ID logging, and reconciliation. For monitors and orchestrators, use /api/livez to check the process without dependencies and /api/readyz to decide whether the instance should receive traffic. /api/health remains the human-readable dependency summary.

​
Local development prerequisites

  • Node.js 20.19 or newer
  • npm
  • PostgreSQL with both pooled DATABASE_URL and direct DIRECT_URL connection strings
  • an ENCRYPTION_KEY generated specifically for the environment
  • email delivery configuration for real registration-verification and invitation flows
Use the repository README for the local commands. A healthy local process without PostgreSQL is sufficient only for viewing public pages; dashboard and onboarding workflows require the database.

​
Operational questions to settle

Before implementation, record:
  1. hosted or dedicated-tenant path;
  2. regions and network egress requirements;
  3. wallet custody and live-funding owner;
  4. secret storage and rotation owner;
  5. webhook destination, verification, replay, and recovery behavior;
  6. backup and reconciliation requirements for your own downstream records;
  7. incident contacts and rollback authority.
Continue with the Production Readiness Checklist after the sandbox integration is working.