Platform
Canopy is one system. Two products are how you experience it.
It would be easy to describe Canopy as a list of features - deploys, pipelines, citations, a CLI, an API. That list is real, but it misses the point. The reason those things work well together is that they were never built as separate features bolted onto a marketing page. They share one identity system, one navigation and interface pattern, one underlying infrastructure, and - genuinely unusual for a platform this size - one real, internal system that governs what's turned on, what's still in preview, and what's off, everywhere, all the time.
What makes this one platform, not two
- One identity system, not a login per product.
- One navigation and dashboard shell pattern, reused across every surface.
- One shared infrastructure substrate underneath both products.
- One governance system deciding what's live, preview, or off - see below.
The organizing idea
A push doesn't hit one feature. It moves through a system.
Take an ordinary Canopy Host deploy. Buildpacks detect your stack. Canopy Connect orchestrates the pipeline that builds and ships it. A saved template may have supplied the environment's starting shape; the Registry may have supplied a package it depends on. Monitoring watches what happens once it's live. None of these are independent add-ons you switch on one at a time in isolation - they're stages of the same pipeline, reading and writing the same underlying project and environment records. That's what "integrated" means here: not that features are compatible with each other, but that they were never separate to begin with.
Unified identity and navigation
One login. One dashboard shape, reused everywhere.
Unified authentication
Canopy Host owns its own login, signup, and password reset - independent of Cortex. A linked account can open the Cortex dashboard or Symphony through a single sign-on handoff, without a second password, but neither product requires the other to authenticate. One identity, used consistently, not a shared login that creates a hidden dependency.
Unified navigation
Canopy Host's own dashboard (host/app) and its internal staff console
(host/administrator) share the same application shell and navigation
pattern, built on the same internal component library used across Cortex's dashboard
and Symphony. The practical effect: once a shape - a sidebar, a header, a settings
page - is familiar in one Canopy surface, it's familiar in the others too, because
it's genuinely the same shell, not a visual copy of it.
Dashboard, API, CLI, SDK, MCP
Five doors into the platform. Every one leads to the same rooms.
The dashboard, the REST API, the CLI, the TypeScript SDK, and an MCP server for AI coding agents all exist for both Canopy Host and Cortex. This isn't five separate reimplementations - the dashboard calls the same API a CLI command does, so nothing on either product is dashboard-only. Cortex's CLI and MCP server are separate packages from Canopy Host's, scoped to Cortex's own resources, but built to the same interface philosophy.
canopy for Host, a separate Cortex CLI for its own resources.@canopy/sdk, a typed TypeScript client, for building your own tools against either product.Engineering Graph Preview
Connective tissue between commits, builds, and deployments - not a graph to look at, a question to ask.
The Engineering Graph isn't a visualization feature. It's the relationships between engineering events - a commit, the pipeline it ran through, the artifact it built, the environment it deployed to - modelled so "what does this change actually touch" is a query, not something someone traces by hand across dashboards. The read/traversal/ correlation layer is real and tested on the Host side today (17 node kinds, ~34 relationship types), gated behind the `host.graph` platform feature: opt-in per team, preview, not a finished guarantee.
The longer-term direction - and it is a direction, not a shipped feature - is for this graph to reach into Cortex too, so a question like "the reports page stopped working, what changed?" could walk an evidence chain from a support report through the service, deployment, artifact, build, and commit that produced it. Today, Cortex has no entity graph of its own, and the one edge connecting a Canopy Host project to a Cortex organization resolves to an empty stub - Host deliberately doesn't reach into Cortex to hydrate it. That connection is real future work, not something to imply exists.
What it's for, today and once built out further
- Today: tracing a deployment back through its pipeline, build, and source commit.
- Today: seeing which environments and projects share a dependency.
- Today: understanding blast radius before approving a promotion.
- Direction, not built: connecting that engineering context to Cortex's knowledge of support and operational data.
The genuinely meta part
Platform Features: the system that governs the rest of this page.
Every capability described across this site - Canopy Connect, Buildpacks, Registry, Templates, Monitoring, the Engineering Graph, MCP hosting, Spaces, and more - is registered in a single internal system called Platform Features. It's a real, independently built governance layer: each capability has a declared owner, a lifecycle stage (generally available, preview, or experimental), and a resolved on/off state that the dashboard, API, CLI, and staff console all check consistently, with a hash-chained audit log of every change. It's what lets this site say "preview" or "experimental" next to a feature name and mean it - the label comes from the same system that actually controls whether the feature runs, not from separately-maintained marketing copy.
Why this matters, concretely
- A capability's status here (live, preview, experimental) is sourced from the same registry that gates it in the product - not a copywriting decision made separately.
- New capabilities can ship dark, get enabled for internal testing, then reach general availability, without a separate flag system per feature.
- Every change to a capability's state is logged, so "who turned this off, and when" is always answerable.
What's governed by that system today
A sample of what's live, what's preview, and what's still off.
"AI" isn't its own row here on purpose - it isn't one feature. It shows up as Cortex's retrieval and drafting pipeline, as Canopy Host's optional AI build-analysis link, as the MCP servers that let coding agents call either product, and as the (experimental, off-by-default) sandboxed and automation surfaces above. Treating "AI" as a single toggle would hide more than it explains.
Shared infrastructure
One substrate underneath, not one per product.
Secrets storage, the primary database, the background job runner, and telemetry (metrics and logs correlated by request ID) are shared infrastructure that both products run on - not a separate stack each. That's an operational choice, not a customer-facing feature: it means the team maintains one set of operational practices instead of two, and it's part of why a change to "how deploys work" or "how retrieval works" gets the same engineering scrutiny either way.
What this does not mean
- Your Cortex data and your Canopy Host project data are not stored together or cross-queryable - see Security.
- Shared infrastructure is an internal engineering detail, not a claim about data sharing between customers or between products.
What's not shared
On purpose.
Sharing everything would mean a single point of failure across two products with different users, different data sensitivity, and different release cadences. The surface area that connects them stays small and mostly optional.
- Separate billing accounts, support queues, and dashboards for each product.
- Separate team/role models - a Canopy Host team is not a Cortex workspace.
- No shared training data - your Cortex knowledge base never trains anything outside your own project.
- The one real integration point is opt-in: a Canopy Host project can link to Cortex for AI build analysis, and fails closed (a clean error, not a broken pipeline) if it isn't configured.
Start with a product
Pick where you want to begin.
Most teams start with one product and add the other later, if at all.