{"slug":"business/41-deployment","title":"Deployment","section":"business","sectionLabel":"Business","status":"unclassified","type":"document","path":"business/41-deployment.mdx","bytes":2707,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\nThis page summarizes deployment-relevant facts for operators and partners integrating with IntegrateWise.\n\nFor canonical detail, see:\n\n- `docs/spec/INTEGRATEWISE_CANONICAL_SPEC_v1.0.md`\n- `docs/architecture/PRODUCT_ARCHITECTURE.md`\n- `docs/ops/RUNTIME_TOPOLOGY.md`\n- `docs/internal/operations/DEPLOYMENT_RUNBOOK.md`\n\n## Runtime boundaries\n\n- IntegrateWise Customer Zero and production SaaS run on Cloudflare infrastructure.\n- Do not deploy production services without explicit founder instruction.\n- Use preview environments before production.\n- Always unset `CLOUDFLARE_API_TOKEN` before running `wrangler` commands intended for non-production verification.\n\n## Environment separation\n\nTreat these environments as independent:\n\n- local development\n- preview\n- production\n\nConfiguration, secrets, feature flags, tenant policy, and runtime bindings differ by environment. Do not assume a behavior proven in local development is automatically valid in production tenant context.\n\n## Service ownership\n\nOperators should keep clear ownership across:\n\n- gateway: entry, auth, API surface\n- pipeline: ingestion, normalization, Spine hydration\n- connector: connection lifecycle and transport adapters\n- intelligence: signals, trigger policy, proposal shaping\n- knowledge: chunking, embedding, retrieval\n- governance: policy, approval, audit\n- twin runtime: runtime-bound session coordination\n\nDo not redeploy services in isolation when schema, contract, or governance changes affect multiple boundaries.\n\n## Credential and secret handling\n\n- Never write credentials, tokens, IPs, or secrets into code, comments, docs, logs, or chat outputs.\n- Secrets are resolved just-in-time.\n- Provider credential rotation should not require product action from users.\n- Any integration workbooks, runbooks, or debug logs must redact secrets.\n\n## Rollback and recovery\n\nDeployment rollback is environment-specific. Operators should:\n\n- validate affected migrations or schema changes before promotion\n- confirm provider adapter compatibility after deployment changes\n- review feature policy and tenant policy after runtime configuration updates\n- keep rollback manifest or prior deployment identifiers available\n\nFor step-by-step rollback behavior, use the internal deployment runbook rather than approximating from this page.\n\n## Observability after deployment\n\nAfter deployment, verify:\n\n- gateway health and auth behavior\n- connector registration and provider health\n- ingestion pipeline latency and backpressure behavior\n- projection freshness and cache behavior\n- audit event continuity\n- approval and outcome flows end to end\n\nUse API surface health checks and provider health indicators, not assumed timing.\n"}