01
Connect your repo
Link your GitHub, GitLab, or Bitbucket account. Select the repository and branch you want to deploy.
Canopy Host - engineering infrastructure
From commit to running workload, with the evidence in between.
Canopy Host is a software-delivery control plane. Push code, build an artifact, promote a known release, and inspect what the runtime reports back. The record is part of the deployment, not a reconstruction job after something changes.
Looking for our AI product? See Cortex, our AI knowledge and operations platform →
01Connect a repository and select a branch.
02Build a deployable application image.
03Run the requested workload and record the deployment.
LiveIn production today
3 providersGitHub, GitLab, Bitbucket
5 interfacesAPI, dashboard, CLI, MCP, SDK
Auto-SSLEvery domain, automatic
The problem
Cloud platforms are complex for teams that just want to ship.
Major cloud platforms were designed for enterprise scale. To deploy a web app, teams configure load balancers, security groups, networking rules, and container orchestration before they ship product.
Canopy Host removes that complexity. Connect your repo. Push your code. Canopy handles HTTPS, domains, build logs, databases, and environment variables from one dashboard - and gives you release provenance and policy gates when you're ready for them.
How it works
Three steps from code to deployment.
02
Build intelligence
Canopy detects common frameworks, dependencies, build command, output directory, and start command from your project files.
03
Your app is deployed
Canopy builds your container, provisions HTTPS, and gives you a running app with custom domain support.
What you get
Build, deploy, control, understand, recover.
Deploy
Git integration
Connect GitHub, GitLab, or Bitbucket with OAuth. Canopy watches for pushes and triggers builds automatically. One asymmetry worth knowing: Bitbucket Cloud does not expose a webhook secret, so Bitbucket deliveries cannot be signature-verified the way GitHub and GitLab deliveries are - a Bitbucket API limitation, not a Canopy gap.
Automatic build detection
Node.js projects include tested framework detection for Next.js, Astro, Vite, Nuxt, SvelteKit, Remix, Express, static sites, and generic Node apps. Override settings when needed.
Automatic SSL & custom domains
Every default subdomain and custom domain gets HTTPS automatically. Add your own domain and point DNS at Canopy - no certificate management required.
Canopy Connect: pipelines & manual approval
Every deploy runs as a pipeline through Canopy Connect - clone, build, test, and deploy shown as separate stages with scoped logs, and a timeline view of every run for an environment. Optionally require a human to approve the final release step before it goes out. See the full breakdown below.
Deploy templates
Save any environment as a reusable template, or launch a new project from a private, team, or Canopy-approved global template.
Operate
Database hosting
Create a database from the dashboard and connect it through an injected environment variable.
Operational recommendations
Canopy watches real resource usage and proposes conservative, reversible rightsizing changes - you apply, dismiss, or revert.
No bandwidth charges
Canopy does not charge bandwidth or egress fees. Your monthly bill is your plan fee.
Hosted MCP servers (preview)
Host your own MCP servers on Canopy, with org-private catalogs and per-team access control. Network isolation between servers is still being hardened - treat this as an early look, not a finished guarantee.
Sandboxed agent execution (experimental)
Run agent-driven tasks in an isolated, resource-limited sandbox with a declared network egress allowlist, instead of a shared shell. Off by default while we finish verifying it - ask us about current status before relying on it.
Control
Releases & promotion policies
Immutable, named releases move through environments under policies-as-code - require a clean security scan, a different approver than the author, or a passing evaluation score before a promotion is allowed.
Team management
Invite people to a team and manage project access from the dashboard. SAML SSO and SCIM are planned work, not current availability.
Custom roles (preview)
Build named roles from a fixed action set for access that doesn’t fit owner/admin/developer/viewer cleanly - a hard escalation guard means an admin can never mint or assign a role carrying an owner-only action like billing or SSO.
Private npm registry
A real, npm-compatible registry for your team - `npm install`/`npm publish` against Canopy directly, scoped to your own packages, with per-package access control. Public namespaces are on the roadmap, not open yet.
Workflow marketplace
Publish a workflow once, install it on any team you have access to. Installing a new version never silently grants it more permission than you already approved - a version that asks for more requires you to re-consent, explicitly.
Understand
Audit log
A hash-chained audit log of every governed event - builds, deploys, promotions, and policy decisions.
Budgets & cost attribution
Set a spend budget per team and see your bill broken down by category, not just a total at the end of the month. Storage, bandwidth, and sandbox/workflow usage are priced today; AI-token and container-time attribution are still rolling out.
Signed build provenance (preview)
Every build produces a signed attestation binding the artifact to the commit and pipeline that built it. The evaluation checks behind it are still being built out - two of five planned checks run today.
Artifact Passport
One page per build artifact: its provenance, an outward lineage graph, every environment currently running it, a blast-radius query ("if this base image has a CVE, who’s affected"), and a citation-grounded risk summary - any point without a fact backing it is dropped, never shown with a caveat.
Recover
Rollback to a previous build
Roll a deployment back to any previous build. When that build has a captured artifact, rollback is a direct image swap - no rebuild; otherwise Canopy rebuilds from the target commit.
The adoption bridge
Canopy Connect: bring the CI/CD you already have, and every deploy becomes a real pipeline.
Canopy Connect does two things. First, it's a bridge: it imports the CI you already run - GitHub Actions, GitLab CI, Bitbucket Pipelines, Jenkins, CircleCI, or anything else via a generic adapter - unmodified, no rewritten config, no migration. Second, it's the orchestration behind Canopy Host's own deploys: a push doesn't just "build somewhere," it runs as a named pipeline with distinct clone, build, test, and deploy stages, each with its own scoped logs. Both feed the same place: one unified, per-environment timeline that merges your existing CI runs with Canopy's own builds.
That timeline shows every run in order, from either source - what triggered it, which commit it built, how long each stage took, and whether it passed or failed - so "what actually happened to this deploy" is a page you can look at, not a question you have to ask someone. This is live and generally available today (`host.ci`), not a roadmap item.
Two separate approval gates exist, and they're not the same thing. Any environment can be set to require a human to approve every deploy that reaches it, regardless of where it came from. Separately, when a project uses release promotion policies, moving a build from one environment to the next can require its own approval step before that promotion happens. Set either, both, or neither, per environment.
This works the same way across GitHub, GitLab, and Bitbucket, with two honest differences that come from the providers themselves, not from Canopy: Bitbucket Cloud has no webhook secret field, so Bitbucket deliveries can't be signature-verified the way GitHub's and GitLab's are, and Bitbucket pipeline steps have no stable name Canopy can read back, so they appear in the timeline as "step-1", "step-2", and so on instead of the job name you gave them. A richer, multi-line check-run status isn't implemented for any of the three providers yet.
What Canopy Connect gives you
- Your existing CI/CD, imported as-is - no migration required to get value from Canopy.
- Separate clone, build, test, and deploy stages for Canopy's own builds, not one opaque step.
- Scoped logs per stage, so a failing test doesn't bury the build output you need.
- One unified timeline of every run for an environment, from any source, in order, with pass/fail status.
- An optional approval gate on any environment's own deploys, when you want a human in the loop.
- A separate optional approval gate on promoting a release to the next environment, when you use promotion policies.
The execution layer underneath
Every Canopy Host deployment runs through Canopy Forest.
When Canopy Host builds and deploys your app, Canopy Forest is what turns that into a real, running workload: it places it on execution capacity, keeps checking that what's actually running matches what you asked for, and reconciles the two if they drift. You don't configure Forest directly - Canopy Host is the interface, and Forest is why an app deploy here isn't permanently pinned to one machine.
Why this matters
- Your app isn't tied to one physical machine - Forest can move execution capacity underneath it.
- A build can happen on one machine and the resulting artifact can run on another.
- Deploys are tracked as desired state versus what a Grove actually observes, not assumed from a command that appeared to succeed.
Developer experience
API, dashboard, CLI, MCP, and SDK - the same platform, five ways in.
Core workflows - projects, environments, deploys, domains, and databases - are
available from the canopy CLI, the @canopy/sdk TypeScript
package, an MCP server for AI coding agents, and the REST API directly, not just the
dashboard. Coverage across all five surfaces is deepest for these core workflows and
still catching up for some newer, less-used capabilities.
Who it is for
- Indie developers and side projects.
- Startup teams that need to move quickly.
- Internal tools, dashboards, and admin panels.
- Teams that want release provenance and policy gates without enterprise overhead.
- Teams in Europe that care where data lives.
Good to know
Canopy Host is intentionally simple.
It may not fit every workload. Every plan includes a 14-day free trial to test without commitment.
Not a fit if you need
- Multi-region or multi-zone deployment today.
- Kubernetes-native workloads.
- Custom networking or VPC configuration.
- A committed uptime SLA as a standard self-serve feature.
- Serverless or edge computing.
Canopy Host pricing
Pricing, without a long sales conversation.
Starter is EUR 20/month. Pro is EUR 50/month. Business is EUR 250/month with priority support. Enterprise is custom. Every plan includes a 14-day free trial. No bandwidth charges and no egress fees.
Included in all plans
- GitHub, GitLab, and Bitbucket integration.
- Automatic SSL for every domain.
- Custom domains.
- Build logs.
- Environment variable management.
FAQ
Common deployment questions.
Does Canopy Host require a Dockerfile?
No. Canopy detects your stack automatically. You can provide a Dockerfile if you want full control, but it is not required.
What runs my application?
Canopy Host uses Canopy Forest, Canopy’s own execution layer, to place your workload and keep checking that what’s actually running matches what you asked for. Forest is built on proven infrastructure primitives underneath it - Kubernetes among them - but you never configure any of that directly; Canopy Host is the only interface you need. See how it works on the Canopy Forest page.
What databases does Canopy Host support?
MariaDB, PostgreSQL, MongoDB, and Redis are live today, provisioned from the dashboard. A few more engines are on the roadmap - contact us if your application needs one that isn’t listed yet.
Can I deploy more than one branch of the same repo?
Each project links to one repository and branch today. Pull request preview planning exists internally, but automatic preview provisioning is not generally available yet.
What happens if I downgrade?
Your app continues to run. If you exceed plan limits, remove apps or upgrade to maintain all deployments.
How does this relate to Cortex?
Canopy Host and Cortex are two independent products from the same company. Canopy Host deploys and runs your apps; Cortex is an AI knowledge and operations platform. Some teams use both - Canopy Host can optionally link a project to Cortex for AI build analysis - but neither product requires the other. See /platform for how the two connect.
Get started
Deploy your first app on Canopy Host.
Simple Git-based deployment on European infrastructure - 14-day free trial to start.