Canvas Open Source vs Instructure Cloud: Which Canvas Should You Run?

Canvas open source vs hosted comes down to who maintains the code. The open-source edition is the AGPLv3 canvas-lms repository that you build, host, patch and scale yourself; the hosted edition is Instructure's commercial service, where Instructure runs the same product family and ships updates continuously. In late 2026 the gap between them is wider than a hosting decision: the public repository has had no commits since 30 April 2026, while the hosted service keeps releasing. For almost every institution choosing Canvas today, hosted is the realistic option; self-hosting makes sense only for teams prepared to own a fork.

This comparison is for LMS buyers, administrators and developers deciding between the two, or reviewing an existing self-hosted install. It covers architecture, customisation, operations, integrations, security, pricing models and the scenarios where each fits. If you only need the repository status and how to check it, our Canvas open source status explainer covers that in detail.

Checked against the public instructure/canvas-lms repository (master head commit of 30 April 2026, confirmed unchanged on 31 October 2026), its developer documentation in doc/api and doc/lti, and the authentication provider models in the source, as of October 2026.

Verdict. Choose hosted Canvas (Instructure Cloud) if you want Canvas as a product: maintained, patched, scaled and supported by its vendor, with beta and test environments and the full integration ecosystem. That is nearly every university, school and training organisation. Choose open-source Canvas only if you have a Ruby on Rails team, need to modify the core code or keep everything on your own infrastructure, and accept that you are maintaining a fork with no public stream of fixes behind it. If self-hosting and an actively maintained public codebase are both requirements, look at other open-source platforms rather than Canvas.

Canvas open source vs hosted at a glance

Features and architecture

Both editions start from the same code. The README describes Canvas as "a modern, open-source LMS developed and maintained by Instructure Inc." under the AGPLv3, and the hosted product is what Instructure builds from its own, newer version of that code. The difference is time and surrounding services.

• Time. A self-hosted build today is a spring 2026 snapshot. Every feature, fix and interface change Instructure has shipped to hosted customers since then is missing, and the gap grows with each hosted release.
• Surrounding services. Some capabilities depend on infrastructure that Instructure operates for hosted customers. The Canvas developer docs note, for example, that the live event system used by the LTI 2.0 plagiarism platform "is not available to open source users". Live Events in general need a delivery and subscription service that you would have to build or supply yourself (see below).
• Plugins in the repository. The open-source tree ships a small set of Ruby plugin gems under gems/plugins, including account_reports, moodle_importer and qti_exporter. Anything Instructure sells as a separate product is outside that repository.

Architecturally, a self-hosted Canvas is a large Rails application with a set of supporting services: app servers running Passenger, PostgreSQL, Redis, a background job daemon, file storage on disk or S3, SMTP and the separate canvas-rce-api service for the rich content editor. Our self-hosting Canvas guide lists the requirements and the configuration files in full.

Customisation, hosting and maintenance

This is where the two diverge most for day-to-day operations.

Hosted Canvas

You customise through the extension points Instructure supports: LTI tools in their placements, the REST and GraphQL APIs, developer keys issued by your institution's admin, and theming. You cannot change core code, and you do not choose when releases happen; the vendor's release cadence and its beta and test environments set the rhythm. In exchange, upgrades, scaling, backups and infrastructure are not your problem.

Open-source Canvas

You can change anything, but you own everything:

• The fork. With no upstream commits since April 2026, every bug fix and dependency upgrade is your engineering work. Rails, Ruby gems and Node packages keep releasing, and upgrading them in an application of this size without upstream help is a sustained cost.
• The AGPLv3. Section 13 requires that if you modify Canvas and users interact with it over a network, you offer them the source of your modified version. That matters for anyone running a customised Canvas as a service for clients.
• Deployment. Instructure's alpha Docker tooling, canvas-self-hosted, was archived on 2 June 2026. Production installs follow the manual Production Start wiki or your own container build from the repository's Dockerfiles.
• Capacity. The Production Start guide recommends at least 8 GB of RAM for a single-server install and separate job and Redis servers as traffic grows. There is no published sizing guidance for large deployments.

The practical consequence: hosted Canvas needs an LMS administration team; self-hosted Canvas needs that team plus a platform engineering team with Rails, PostgreSQL and Linux operations skills.

Integrations and reporting

The integration surface is largely the same code, with some operational differences that catch developers out.

The LTI issuer detail matters for vendors: an LTI 1.3 tool that hard-codes Instructure's issuer will not accept launches from a self-hosted Canvas until it is configured for that platform. Many commercial LTI tools are built and tested against hosted Canvas, so check support for self-hosted instances before you license them.

For reporting, both editions have account reports and the APIs. Event-driven reporting differs: on hosted Canvas, admins point Live Events at an SQS queue or HTTPS endpoint; on self-hosted Canvas you run the stream and its consumers. Our article on Canvas Live Events and the Platform Notification Service covers both sides.

Security and scalability

Hosted Canvas: Instructure patches the application and its dependencies, runs the infrastructure and scales it. Your security work is configuration: SSO, MFA for administrators, role and permission design, developer key scopes and the LTI tools you approve. Your due diligence is contractual: ask for security documentation, data residency, incident notification terms and the shared-responsibility split in writing.

Self-hosted Canvas: you own the full security lifecycle. Because the public repository has received no commits since 30 April 2026, any fix Instructure makes in its hosted product does not reach you through the repository, and dependency updates are yours to test and ship. Scaling is also yours: separating app, job, database and Redis roles, putting files on shared storage when you run more than one app node, and load testing for your own peak periods such as term start and exam weeks.

For a governance or audit committee, the difference is simple to state: hosted Canvas is a vendor-maintained service with contractual commitments; self-hosted Canvas, as of October 2026, is an unmaintained upstream that your team must maintain.

Pricing models

Neither side has a price we can quote. As of October 2026:

• Hosted Canvas: Instructure did not publish Canvas prices; subscriptions are quoted per institution, and adjacent products such as Canvas Studio, Canvas Catalog and Canvas Credentials are separate purchases. Ask for multi-year pricing and renewal caps in the quote.
• Open-source Canvas: no licence fee. The cost is infrastructure (several servers or containers, PostgreSQL, Redis, storage, SMTP), the engineering team that maintains the fork and its dependencies, monitoring and backups, and any hosting partner. Because there is no upstream, budget engineering time as an ongoing line, not a one-off install.

Compare five-year totals, including people on both sides. A hosted subscription still needs an internal admin team; a self-hosted install needs that team and the platform engineers. For a broader cost frame, see our LMS comparisons guide.

Best fit by scenario

If you run self-hosted Canvas today

A running instance does not break when upstream stops, but the risk grows each month. A sensible sequence:

1. Check the repository again. Look at the latest commit on master and the newest release/ tag. If public commits have resumed, read what changed before treating the code as maintained.
2. Inventory your changes. List core modifications, custom plugins, LTI tools and integrations. These decide how hard any move will be.
3. Price the options. Keep maintaining the fork, move to hosted Canvas (ask Instructure directly how it handles moves from self-hosted installs), or move to another platform.
4. Plan the data. Canvas exports courses as IMS Common Cartridge, and Instructure's documentation says course exports leave out student interactions and grades, which need a separate export. Learner history needs its own plan whichever way you go.

Whatever you decide, put a review date on it. The status of the public repository is the one fact most likely to change.

How we can help

We help institutions decide between hosted Canvas, a maintained self-hosted fork and other platforms, and we plan the migrations that follow. See our LMS consulting services for an independent review, or our Canvas services for integration and migration work.