Kanopy Hosting
Internal runtime model
Builder Insights should be prepared to run inside Kanopy as an internal application platform, especially for the admin control plane and supporting service layer.
What internal hosting changes
- network and ingress assumptions
- identity callback and DNS planning
- secrets and environment management
- deployment verification and rollback expectations
Recommended hosting posture
Treat the admin control plane as the first-class Kanopy workload because it is the most clearly internal-facing runtime surface.
Background jobs, internal APIs, and supporting services should live near the admin runtime when they share internal trust boundaries.
Even if mobile distribution follows a separate path, the mobile experience should be prepared to consume Kanopy-backed internal services where appropriate.
Hosting model decisions
| Decision area | Recommended default |
|---|---|
| First Kanopy target | admin control plane and internal service layer |
| Environment separation | explicit development, staging, and production environments |
| Secret handling | central managed secrets, not static config checked into repos |
| Health verification | startup, readiness, and runtime health checks |
| Rollback posture | defined deployment verification and rollback playbook |
Decision tracker
| Decision | Current recommendation | Owner | Status |
|---|---|---|---|
| First Kanopy target | admin control plane and internal service layer | Platform Engineering and Application Engineering | Drafted |
| Environment model | explicit dev, staging, and production separation | Platform Engineering | Drafted |
| Secret management path | central managed secrets | Platform Engineering and Security | Needs validation |
| Deployment verification standard | health checks plus rollback playbook | Platform Engineering and Application Engineering | Drafted |
Kanopy readiness flow
Clarify which workloads move into Kanopy first and which external dependencies remain outside it.
Confirm domains, callback URLs, internal DNS, and Okta SSO assumptions before migration work starts.
Make environment boundaries, secrets, and configuration ownership explicit.
Health checks, alerting, rollback, and deployment validation should exist before the internal runtime is treated as stable.
Core internal-hosting concerns
SSO, internal DNS, and user-access URLs must line up cleanly or authentication and app reachability will fail in confusing ways.
Internal hosting only improves security posture if secrets, API keys, and environment-specific config are handled intentionally.
Someone needs to own deploy verification, rollback decisions, runtime health, and incident response expectations.
The team should know which external services remain critical and how failures in those services surface inside Kanopy-hosted workloads.
Stakeholder questions to answer
Kanopy or platform owners
- what deployment model is preferred for internal web apps and supporting services?
- what readiness, liveness, and rollback expectations are standard?
- what ingress, DNS, and certificate patterns should this app follow?
- what monitoring hooks are expected for Kanopy-hosted services?
Security and identity owners
- how should Okta callback URLs and internal routing be handled?
- which internal networking assumptions affect the admin control plane and APIs?
Application owners
- which services belong in Kanopy first?
- which environments are needed before production?
- what is the minimal deploy verification checklist?
Decision
Practical starting point
Start by moving the admin control plane and internal service layer into Kanopy before trying to solve every runtime concern at once. That gives the team a clear internal surface to operationalize first.