01
Connect your repo
Link your GitHub, GitLab, or Bitbucket account. Select the repository and branch you want to deploy.
Canopy Host - engineering infrastructure
Canopy Host is The Canopy Corporation's engineering infrastructure and control layer for shipping software: connect your GitHub, GitLab, or Bitbucket repository, push your code, and Canopy detects your stack, builds a container, and deploys it with automatic HTTPS, custom domains, build provenance, and no bandwidth charges.
Looking for our AI product? See Cortex, our AI knowledge and operations platform →
The problem
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
01
Link your GitHub, GitLab, or Bitbucket account. Select the repository and branch you want to deploy.
02
Canopy detects common frameworks, dependencies, build command, output directory, and start command from your project files.
03
Canopy builds your container, provisions HTTPS, and gives you a running app with custom domain support.
What you get
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.
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.
Every default subdomain and custom domain gets HTTPS automatically. Add your own domain and point DNS at Canopy - no certificate management required.
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.
Save any environment as a reusable template, or launch a new project from a private, team, or Canopy-approved global template.
Create a database from the dashboard and connect it through an injected environment variable.
Canopy watches real resource usage and proposes conservative, reversible rightsizing changes - you apply, dismiss, or revert.
Canopy does not charge bandwidth or egress fees. Your monthly bill is your plan fee.
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.
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.
Bring your own compute (BYOC) for builds and sandbox runs: enroll infrastructure you control and Canopy routes a team’s work there instead of its own cloud, over an outbound-only signed protocol so Canopy never gains inbound access to your infrastructure. Off by default while we finish verifying it - ask us about current status before relying on it.
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.
SAML single sign-on and SCIM provisioning for your identity provider, invite-based team management, and role-based access from the dashboard.
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.
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.
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.
A hash-chained audit log of every governed event - builds, deploys, promotions, and policy decisions.
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.
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.
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.
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 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.
Developer experience
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.
Good to know
It may not fit every workload. Every plan includes a 14-day free trial to test without commitment.
Canopy Host pricing
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.
FAQ
No. Canopy detects your stack automatically. You can provide a Dockerfile if you want full control, but it is not required.
Yes. Dokku handles containerisation and deployment. Canopy adds dashboard, Git integration, teams, database provisioning, API, and billing.
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.
Each project links to one repository and branch today. Pull request preview planning exists internally, but automatic preview provisioning is not generally available yet.
Your app continues to run. If you exceed plan limits, remove apps or upgrade to maintain all deployments.
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
Simple Git-based deployment on European infrastructure - 14-day free trial to start.