Which Canvas option fits your situation
Keep Instructure's hosted Canvas if your main pressure is operational: you want the vendor to run hosting, upgrades and support, and you have no in-house team for a Ruby, PostgreSQL, Redis and Passenger stack. Self-host the AGPLv3 code if your main pressure is location control, meaning course content, student records and logs must sit in a country, data center or network you choose, and you have people or a partner who can operate the platform for years. The decision turns on four things: operating capacity, data obligations, support expectations and migration effort. The code license alone does not decide it, because the license governs what you may do with the software, not who keeps it running at 2 a.m. during a term start.
Before you choose, confirm the facts that will drive the answer. Ask Instructure in writing what the current subscription covers, where it stores data, which regions are available, and what contractual support and uptime terms apply. Then map your own obligations: records-retention rules, any requirement for on-premises or in-country hosting, and whether your accreditor or regulator expects evidence of how the platform is patched. For self-hosting, the Canvas Production Start guide is the document to test against your environment, because it sets the minimum server, database and cache versions and points installation problems to community channels rather than to Instructure support.
A self-hosted choice also needs an answer to a harder question: who will be your first line of support when a release upgrade fails or an LTI tool breaks. If that role will sit with your own staff, budget for the people and on-call coverage before you migrate. If it will sit with a partner, the scope, response expectations and upgrade cadence belong in a written agreement before work starts. Institutions that cannot staff that role often find the hosted subscription is the lower-risk option, even when the license would allow them to run the code themselves.
Scenarios where each option is the better fit
This table pairs common buyer situations with the option that usually fits them better, and the condition that tips the decision. Read each row against your own staffing, data location rules, budget model and existing vendor relationships, because the same facts can point either way.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Central IT team with no Ruby or PostgreSQL operations experience | Instructure-hosted Canvas | No one on staff can run Ruby, PostgreSQL, Redis and Passenger upgrades, and the institution does not want to hire or contract for them |
| Institution with strict data location rules | Self-hosted Canvas LMS | Policy requires student records and course files to stay in a named country, data center or private network that Instructure's hosting cannot be placed in |
| Team that needs to modify the code | Self-hosted Canvas LMS | The AGPLv3 license permits changes, and you have engineers who can maintain patches through each release tag and carry them forward |
| Budget review of recurring subscription spend | Self-hosted Canvas LMS | Leadership wants recurring subscription costs replaced by hosting, staff or partner costs, and the one-time migration effort is accepted in the business case |
| School with an existing platform partner | Instructure-hosted Canvas | A current managed service partner already runs infrastructure, support and upgrades, and the school wants that partner to continue with Instructure's hosted service |
| Institution that needs vendor-backed support for incidents | Instructure-hosted Canvas | Staff need a contracted support channel with defined response commitments, which the self-hosted installation guide does not provide |
| Institution with its own engineering and support capacity | Self-hosted Canvas LMS | Internal or partner staff can own upgrades, backups, monitoring and community-based troubleshooting on a defined schedule |
| Institution planning a move to a different LMS within a few years | Instructure-hosted Canvas | A short horizon makes one-time self-hosting work hard to recover, so confirm exit and export options before deciding |
What Instructure's hosted service adds beyond the code
A hosted Canvas subscription moves a set of operational responsibilities from your team to Instructure. In general terms, a hosted contract typically covers running the platform, applying upgrades on the vendor's schedule, the hosting environment and its databases, and a named vendor that is accountable when something breaks. The exact scope is what you are buying, so confirm it in writing before comparing costs. Ask Instructure which hosted features are included, what availability and response commitments apply, which support tiers exist and what they cover, how data backup and disaster recovery are handled, and which regions host your data. Ask whether any of these are priced separately, such as additional storage, sandbox environments or premium support.
The open-source repository changes the picture for self-hosters. The canvas-lms project publishes dated release tags, such as release/2026-05-20, so new code arrives as numbered snapshots rather than a managed rollout. Nobody chooses the upgrade window for you in a hosted contract, but in a self-hosted install your team or partner must pick which tag to adopt, test it against your own plugins, LTI tools and customizations, schedule the database migrations and roll back if needed. Read the release notes for each tag you consider, and decide before you go live how often you will upgrade and who signs off on each change.
Before you weigh the hosted service against running Canvas yourself, write down what your current subscription actually delivers today. Compare that list line by line with the operational duties described in the Production Start guide and with the upgrade cadence you can sustain. Where the hosted contract covers a duty that you would otherwise staff, record the cost of that duty as part of the comparison. Where a duty is not covered by the contract at all, such as your own customizations or integrations, it will fall to you under either option.
How hosting and data control differ
With Instructure-hosted Canvas, Instructure operates the application, databases and infrastructure under its subscription terms. Your institution controls course design, user roles and integrations inside the product, but the physical location of stored data, backup practices and the security controls around the platform are defined by Instructure's hosting arrangements. Your contract and Instructure's published security documentation are the sources to review.
- Data location: Confirm in writing which regions store your course content, learner records and backups, and whether that changes for disaster recovery.
- Operational control: Upgrades, patching and infrastructure changes happen on Instructure's schedule, not yours.
- Identity: Single sign-on and provisioning are configured within Canvas and your identity provider, so confirm which connectors your contract supports.
- Evidence: Ask Instructure for its current security and compliance documentation and whether it covers the frameworks your assessor requires.
- Exit terms: Ask how you can export course packages and learner data at the end of the contract.
Before relying on this model, ask your assessor which obligations apply to a third-party processor and what evidence you must keep from the vendor.
When your own team runs Canvas in a cloud account or data center, the code, databases and course files sit inside your boundary. You decide where data lives, how backups are encrypted and who has administrative access. The cost is that you also own the operating controls that Instructure would otherwise carry, including patching, monitoring and incident response. The Canvas Production Start guide describes a stack of Ruby, PostgreSQL 14 or later, Redis 6.x or above, Apache with Passenger, a background job daemon and an outgoing SMTP server.
- Data location: Course files, submissions and grades stay wherever you place the database and object storage.
- Access control: Administrative and database access are granted by your own team and logged in your own systems.
- Identity: You configure SSO and provisioning against your identity provider, and you test failure modes such as provider outages.
- Evidence: You generate and retain logs, change records and backup test results yourself for any assessment.
- Support path: Installation questions go to the community mailing list or IRC channel, so your team must be able to resolve issues without vendor tickets.
Confirm with your assessor how the hosting provider, your own staff and any open-source components appear in the system boundary.
A partner-operated model keeps Canvas inside your cloud account, data center or air-gapped network while an outside firm plans, installs, hardens, backs up, upgrades and documents the platform. Data location and ownership stay with you, but the people operating the system are external, so their access, background checks and offboarding need written terms. DeployOpen works this way for self-hosted platforms: it prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work.
- Data location: The platform and its data remain in your environment under your ownership.
- Access terms: Define in the written scope which partner accounts exist, how they are approved and how they are removed.
- Identity: SSO configuration and role mapping are delivered as documented controls that your team can review.
- Evidence: Partner work produces configuration records, runbooks and test results that feed your assessor's review.
- Responsibility split: Agree in writing who handles patches, backups, restores and incidents, and what each party must provide.
Ask your assessor which obligations apply to a partner with administrative access, and confirm that the scope names every control the partner operates.
What the self-hosted stack asks of your team
Running Canvas yourself means operating a Ruby application on top of PostgreSQL, Redis, a web server and background jobs, plus mail delivery. Each component carries its own patching, backup, capacity and monitoring duties, and together they replace the hosting work Instructure does for you today.
Ruby runtime
Canvas is a Ruby on Rails application, and the Production Start guide was written and tested on Ubuntu 22.04 LTS and recommends at least Ruby 3.4.1 as of the 2025-07-02 release. Your team owns the runtime version, gem updates and the security patches that follow. Check which Ruby version each Canvas release expects before you schedule an upgrade, because a platform upgrade can require a runtime upgrade first.
PostgreSQL database
PostgreSQL holds courses, grades, enrollments and submissions, so it is the component where data loss would hurt most. Canvas requires PostgreSQL 14 or later since the stable/2024-11-20 release. You own backups, point-in-time recovery, major version upgrades and tuning as enrollment and submission volumes grow. Ask your team to rehearse a restore, not just confirm that backups run.
Redis cache and OAuth2
Redis supports caching and OAuth2 token handling in Canvas, and the guide calls for Redis 6.x or above. Because sessions and cached data depend on it, an outage here degrades logins and page performance quickly. Your team must monitor memory use, decide on persistence settings and plan failover. Confirm whether your Redis setup is managed or self-run, since that changes who answers at 2 a.m.
Apache with Passenger
Production Canvas runs under Apache with Passenger, which manages the Ruby application processes that serve users. Your team handles TLS certificates, Apache configuration, process limits and log rotation. Capacity problems often show up here first as slow responses or queued requests, so plan monitoring of worker counts and response times alongside the database metrics.
Background job daemon
Canvas runs a background daemon for automated jobs such as scheduled tasks, imports and notifications. If it stops, work queues silently and users notice later, so process supervision and alerting matter. Effort rises with the number of scheduled integrations, bulk imports and the frequency of Common Cartridge migrations, each of which adds job load.
Outgoing SMTP server
Canvas sends notifications, password resets and course messages through an outgoing SMTP server that you provide. Your team owns sender authentication records, bounce handling and deliverability checks. Mail that stops or lands in spam is often reported as a Canvas fault, so confirm the relay, its sending limits and who monitors bounces before go-live.
How a move to self-hosted Canvas unfolds
The sequence below takes an institution from a license and feature decision to a cutover on its own infrastructure, with a checkpoint at each stage so that no step goes live before the one before it is verified. Effort depends on course volume, integrations and in-house skills, and the timeline is set in the written scope rather than assumed here.
Confirm license and feature needs
Start by listing the features your courses, accessibility obligations and integrations depend on, and confirm them against the AGPLv3 license terms and the current canvas-lms repository. Your legal or procurement team owns the license review, and your academic and IT leads own the feature list. You are done when the list is signed off and every feature is marked as core, supported by a plugin, or to be replaced. Ask any vendor or partner to confirm in writing which features they have tested on self-hosted builds.
Stand up a non-production Canvas environment
Build a staging instance by following the Production Start guide in the canvas-lms project wiki, which was written and tested on Ubuntu 22.04 LTS. Install Ruby (the guide recommends at least 3.4.1 as of the 2025-07-02 release), PostgreSQL 14 or later, Redis 6.x or above, Apache with Passenger, a background jobs daemon and outgoing SMTP, on a server with at least 8GB of RAM. Your platform engineers own the build. You are done when the staging site loads, background jobs run and a test email is delivered.
Import a test set of courses
Export a representative sample of courses from the hosted instance as Common Cartridge or IMSCC packages and import them into staging with the Course Import Tool. Include a few large courses, courses with embedded media and courses with quizzes. Course designers should review each imported course for broken links, missing files and quiz formatting. You are done when every test course has a signed-off review and the defects are logged against a fix list.
Validate SSO and LTI integrations
Reconnect your identity provider, SIS feeds and LTI tools to the staging instance and test each one with a test account for every role. Your identity and integrations team owns this work, and each tool vendor may need to re-register or reissue credentials for the new domain. You are done when a login, an enrollment sync and a tool launch succeed for each role, and the results are recorded in the test log.
Migrate grades and student records separately
Course packages do not carry the gradebook or learner records, so export grades and enrollment data through their own routes and load them into staging under a controlled process. Registrar and records staff should verify that totals match the source for a sample of courses before anything moves forward. You are done when reconciliation reports show matching counts and totals, and a retention plan for the source records is documented.
Set up backups and an upgrade cadence
Configure automated backups of the PostgreSQL database, uploaded course files and configuration, and test a full restore on a separate server. Agree an upgrade cadence that tracks the dated release tags in the canvas-lms repository, and run each upgrade in staging first. Platform operations owns backups and upgrades. You are done when a restore has been completed from backup and the first upgrade has been rehearsed in staging.
Define support ownership and escalation
Decide who answers each problem before go-live. The Production Start guide directs installation problems to the community mailing list or IRC channel rather than Instructure support, so you must name an internal team or a partner for the production issues that the community cannot resolve in time. Write the on-call roles, severity levels and contact paths. You are done when the support model is approved and each role has a named owner.
Cut over to the self-hosted instance
Schedule a freeze on course edits in the hosted instance, run the final course export and import, repeat the grade and record reconciliation, switch DNS and integrations, and keep the hosted instance available for a rollback window agreed in advance. Instructors and students should be given a clear contact path during the first weeks. You are done when the production checks pass, the rollback window closes without a rollback, and the hosted subscription can be ended on the date you choose.
Questions buyers ask before choosing a Canvas path
How much effort does running Canvas LMS ourselves actually take?
Expect the work to be an ongoing platform operation, not a one-time install. The Canvas Production Start guide, written and tested on Ubuntu 22.04 LTS, assumes you run the Ruby stack, PostgreSQL 14 or later, Redis 6.x or above, Apache with Passenger, a background job daemon and an outgoing SMTP server, and it recommends at least 8GB of RAM. Effort rises with course volume, file storage, integrations such as SIS and LTI tools, and how many environments you keep for testing. Ask any partner to size these components against your own enrollment and course data before agreeing a scope.
Can our in-house team run self-hosted Canvas without outside help?
It depends on whether you already operate Ruby on Rails, PostgreSQL, Redis and Passenger services in production. The Production Start guide points installation problems to the community mailing list or IRC channel, so the first-line troubleshooting is yours. Teams without that depth usually need either a hire with the right skills or a partner for the initial build and handover. Check who on your staff would own patching, backups, failover and on-call before deciding.
What does a DeployOpen engagement cover for self-hosted Canvas?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including cloud accounts, data centers or air-gapped networks. For Canvas, that could cover the stack build, integration with your identity and SIS sources, course migration planning, security testing and runbooks. Most engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. A quote follows from the written scope.
How are Canvas upgrades handled when we run the code ourselves?
Upgrades become your responsibility or your partner's. The canvas-lms repository publishes dated release tags, such as release/2026-05-20, and the project wiki holds the install guides you would follow for each change. Each upgrade needs a staging test against your plugins, LTI tools and database migrations, plus a rollback plan. Ask any provider how they track release tags, how long a tested upgrade cycle takes in your environment, and whether that work is in the base fee or a retainer.
What support exists beyond the community mailing list or IRC?
For a self-hosted Canvas install, the documented support route in the Production Start guide is the community mailing list or IRC channel, not Instructure. Any commercial support must come from a partner or your own staff. Confirm with Instructure whether it offers a support agreement for self-hosted customers, and what it covers, before you rely on it. Ask a partner for response expectations in writing, and what happens to your tickets and runbooks if the engagement ends.
How long does moving from hosted Canvas to self-hosted Canvas take?
No timeline is supplied for this migration, so confirm it against your own environment rather than a generic estimate. The main drivers are the volume of courses and files, how many integrations need re-testing, whether you rebuild the server stack or reuse an existing one, and how much validation your academic calendar allows. Common Cartridge and Blackboard import paths exist for content, but grades and student records need separate handling. Ask any provider for a milestone plan tied to a written scope.
Do AGPLv3 obligations apply if we only run Canvas internally?
Canvas is released under the AGPLv3, and the AGPL's network clause is the provision that matters for modified versions offered to users over a network. Whether your institution triggers source-sharing duties depends on whether you modify the code and how users reach it, so take this question to your legal counsel rather than relying on a summary. Keep a record of every change to the codebase, including local plugins and theme work, so the answer is easy to verify later.
What do the hosted subscription and self-hosting cost each include?
Hosted Canvas bundles the platform, hosting, operations and vendor support into one subscription, while self-hosting moves those costs onto your budget. Self-hosted costs include servers or cloud capacity for the application, PostgreSQL, Redis and file storage, staff or partner time for upgrades and incidents, backups, and a one-time migration effort. Ask any vendor for a quote that lists each component, which costs recur, and which items are one-time, so you can compare like with like.
How DeployOpen helps evaluate, implement and support Canvas LMS
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including your cloud accounts, data centers or air-gapped networks. For a team weighing Instructure-hosted Canvas against running the AGPLv3 code, that means DeployOpen can take on the work the Production Start guide leaves to the operator: standing up the Ruby runtime, PostgreSQL 14 or later, Redis 6.x or above, the Apache and Passenger web tier, the background job daemon and outgoing SMTP. DeployOpen is not an official Instructure partner, reseller or certified provider, so the engagement is an independent implementation service built on the open-source code. Before any work starts, the written scope should name the Canvas release tag you will deploy, the hosting environment, who owns the database and file storage backups, and which integrations (LTI tools, SIS feeds, single sign-on) must work on day one.
Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work begins. For Canvas, a useful scope separates one-time work from recurring work. One-time items include the initial installation, the migration of course content through Common Cartridge packages, configuration of the Course Import Tool workflow, hardening and documentation. Recurring items include applying each new release, patching the operating system and runtime, testing backups by restoring them, and handling incidents. Retainers cover that ongoing upgrade and support work, and DeployOpen can also run continuous security testing of the deployed application and its APIs. Ask for the scope to state the release cadence you expect to follow, the response expectations for production incidents, and how upgrades are tested before they reach learners. DeployOpen does not publish a price list. A quote follows from the written scope, so the inputs that move the price are the number of environments, the size of the course catalog, the integrations, and the level of support you choose.
DeployOpen also prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. If your institution must show how student records, access controls and backups are handled, ask for those artifacts to be part of the scope, then give them to your own auditors or certification bodies for assessment. Before committing, decide who will take over operational ownership, check the Canvas Production Start guide against your own environment, and confirm with DeployOpen how documentation and runbooks will be handed over. A scoped evaluation is a reasonable first step if you are not yet sure which path fits.
