When a self-hosted Canvas LMS fits better than Brightspace
A vendor-run Brightspace subscription fits an institution or business that wants D2L to operate the platform, has no staff to patch servers, databases and mail relays, and accepts the hosted service's terms for uptime, data location and upgrades. Self-hosted Canvas LMS fits when you need control over where the platform runs, whether that is your own data center or a private cloud, and you already have operations staff who can run a Rails application with PostgreSQL, Redis, a background job daemon and an outgoing SMTP server. The decision turns on three questions: who operates the platform, which LTI tools and integrations are mandatory, and what Instructure's hosted service provides that the AGPLv3 code does not.
Start with operations, because it is the cost that recurs. The Canvas Production Start guide describes an Apache and Passenger stack, a background daemon for automated jobs, an SMTP server, PostgreSQL 14 or later and Redis 6.x or above, and it recommends at least 8GB of RAM and Ubuntu 22.04 LTS as the tested platform. Someone must own patching, backups, scaling and upgrades to each release tag. The guide directs installation problems to the community mailing list or IRC channel rather than to Instructure support, so ask whether your team can accept that support model or whether you need a partner under a written scope. Confirm which LTI 1.3 tools your departments require and check each vendor's Canvas registration before you commit. Finally, list the hosted features you depend on, such as vendor support, hosted uptime commitments and certifications, and confirm with Instructure which of them, if any, are not in the open-source code. Confirm Brightspace capabilities against D2L's current documentation before comparing them.
Which scenarios favor Brightspace and which favor self-hosted Canvas LMS
This table compares common buyer situations and names the option that tends to fit better, along with the condition that makes it so. Read each row against your own staffing, hosting rules and support expectations, since the right answer usually depends on one or two conditions rather than on the platform alone. Treat the rows as starting points for a decision, not as a ranking.
| Buyer scenario | Better fit | Condition that makes it so |
|---|---|---|
| Small college with no LMS engineers | Brightspace | Fits when the college wants the vendor to host, upgrade and support the platform, and has no staff to run Rails, PostgreSQL, Redis and mail services. |
| University with a strict data residency requirement | Self-hosted Canvas LMS | Fits when the university must keep student records inside its own data centers or a named region and has an operations team able to run the stack there. |
| Training team that needs a contractual uptime commitment | Brightspace | Fits when the team needs a vendor-backed service level in writing; confirm the exact terms with D2L, since a self-hosted install puts uptime on your own team unless a support partner covers it. |
| School district with an existing ops team | Self-hosted Canvas LMS | Fits when the district already runs Linux servers, databases and backups, and can staff upgrades and an SMTP relay without adding a new skill set. |
| Institution that already has Instructure contracts for other tools | Brightspace or hosted Canvas | Fits when procurement, identity and support already sit with Instructure, so self-hosting would add a second relationship to manage; confirm bundling terms directly. |
| Institution that depends on Brightspace-specific tools or analytics | Brightspace | Fits when courses rely on Brightspace features that do not map cleanly to Canvas, such as its gradebook or analytics setup; audit those dependencies before choosing Canvas. |
| Organization that wants code it can inspect and modify | Self-hosted Canvas LMS | Fits when the team needs to read or patch source under the AGPLv3 license; note that modifications you run as a network service carry AGPL obligations, so check them with counsel. |
Where Canvas data lives when you run it yourself
Running Canvas yourself moves hosting, identity, backup and evidence work from Instructure to your team or partner. Each card below names a control, the condition under which it matters, and what to confirm before you compare it with a Brightspace subscription.
Data location and residency
With a self-hosted Canvas install, you decide the region, data center and cloud account where the database, file storage and logs sit. This matters when a residency rule or research data agreement limits where student records can be processed. Confirm where Brightspace data is hosted, which regions D2L offers and whether backups and support access cross borders, then document the same answers for your own Canvas deployment.
Hosting model choice
You can keep Instructure's hosted service, run Canvas on your own servers or cloud accounts, or hand operation to a third-party hosting partner. Each model shifts patching, capacity and uptime duties differently. The Canvas Production Start guide describes the components a production install needs, including Apache with Passenger, a background job daemon and an outgoing SMTP server. Ask every candidate operator which of these they run and who answers at 2 a.m.
Identity and SSO integration
Canvas accounts, single sign-on and LTI tool launches depend on how your identity provider is connected. In a self-hosted deployment, you configure the authentication link, certificates and session settings yourself, and you own the cutover when students and staff move. Test sign-in for every role, including guest and external reviewers, before the Brightspace login is switched off. Check how your identity provider and Canvas exchange tokens, because a misconfiguration can lock out an entire cohort.
Backup and retention ownership
A hosted Brightspace subscription usually includes backups under the vendor's terms, but a self-hosted Canvas install makes backups your job. The PostgreSQL database, uploaded course files and Redis-held session data need separate recovery plans, and retention periods for learner records must match your policy. Restore a full course and a full database into a test environment at least once, and record how long it took. Ask D2L to state its backup and retention commitments in writing so you can compare them.
Compliance evidence
Frameworks such as ISO/IEC 27001 or SOC 2 are assessed against a provider's operating controls, so when you run Canvas, your organization must produce the evidence for access reviews, change records, vulnerability handling and incident response. DeployOpen prepares systems, controls and evidence for these assessments, but it does not issue audit reports, attestations or certifications, and an independent auditor or certification body makes that determination. Ask D2L which certifications and reports cover Brightspace and for which regions, and confirm them directly with D2L.
Data export and exit
Your ability to leave any LMS depends on exporting course content, learner records and grades in usable formats. Canvas supports Common Cartridge and IMSCC imports, so exported Brightspace packages can come in, but learner history and grade records need separate handling. Schedule a periodic export of course data, gradebook and enrollments from your Canvas instance to storage you control. Test a restore so that a future move, whether to Brightspace or another platform, does not depend on a single vendor's export tool.
What Instructure's hosted service adds that the AGPL code lacks
Canvas LMS is created and maintained by Instructure, and its source code is released under the AGPLv3 license. That license lets you download, run and modify the code yourself, but it does not transfer the operations, support or hosted features that Instructure sells as a separate offering. Before you compare Canvas with Brightspace on course design and gradebook, decide which hosted service capabilities your institution actually depends on. Write them down as a list: support hours and response channels, uptime commitments, hosted integrations with your student information system, managed upgrades, data center location, and any add-on products your teams use today. Each item is a question to put to Instructure, not an assumption to carry into the comparison.
For each item on that list, ask Instructure in writing to confirm whether it is included in the hosted subscription, available as a separate contract, or excluded from the self-hosted code entirely. Do not rely on the license alone to answer this. Ask the same question about the D2L Brightspace subscription so both sides of the comparison use the same line items. If a feature is only available through the hosted service, your self-run install will need either a replacement built and operated by your team or a partner, or a decision to accept that the capability is gone. Record each answer with the date and the name of the person who gave it.
Support deserves its own check. The Canvas Production Start guide directs people with installation problems to the community mailing list or IRC channel rather than to Instructure support. A self-run Canvas install therefore has no support path built into the open project that you can count on for production incidents. If your organization needs a named response channel, service hours or an escalation route, arrange that separately before cutover, either through a contract with Instructure for a self-managed arrangement, if one is offered to you, or through a third party. Confirm the terms in writing, because the cost of this support is one of the largest recurring items when you compare a self-run Canvas with a D2L subscription.
Operating Canvas yourself compared with a Brightspace subscription
Under a D2L subscription, the vendor hosts and operates the Brightspace environment. Your institution's obligations are mainly contractual: confirming service levels, data handling terms and how support requests are routed. Your team still administers courses, enrollments, integrations and single sign-on, but it does not manage servers, databases or the software release cycle.
- Patching and upgrades: D2L applies platform updates on its own schedule, so the question for your team is when changes land and how you test your integrations against them.
- Backup and monitoring: Ask D2L to state in writing the backup frequency, retention, restore testing and uptime monitoring it provides.
- User tickets: Vendor support handles platform faults, while your help desk typically handles course and account questions first.
- Staffing: Expect a smaller administrator team focused on configuration, training and integrations rather than infrastructure.
- Cost driver: Subscription and add-on module fees recur every term, and changes to licensing are set by the vendor.
Before you renew, check the service terms for data location, exit assistance and what is included in support tiers.
Running Canvas yourself means your own team becomes the operator. The Canvas 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. It requires PostgreSQL 14 or later since the stable/2024-11-20 release, Redis 6.x or above for caching and OAuth2, and a server with at least 8GB of RAM. A production install also runs Apache with Passenger, a background daemon for automated jobs, and an outgoing SMTP server.
- Patching and upgrades: Your staff track the release tags in the canvas-lms repository, test each one, and apply Ruby, PostgreSQL and Redis updates alongside them.
- Backup and monitoring: Your team owns database backups, restore tests, queue health for the background jobs, and mail delivery monitoring.
- User tickets: Your help desk must triage every fault, because the guide points installation problems to the community mailing list or IRC rather than to Instructure support.
- Staffing: Plan for administrators with Linux, Ruby on Rails, PostgreSQL and mail skills, plus an on-call rota for outages.
- Cost driver: Most costs are recurring labor and infrastructure rather than licenses, and they grow with the number of environments you run.
Confirm with your own team that they can meet the version requirements and cover on-call before committing to this model.
A services partner can plan, install, harden and operate Canvas inside your infrastructure while your institution keeps ownership of the servers, data and accounts. Responsibilities are divided in a written scope, so the split between your staff and the partner must be explicit. DeployOpen is one such implementation partner, and its work is fixed-scope, with ongoing support available as a retainer.
- Patching and upgrades: The partner can take on the release testing and the Ruby, PostgreSQL and Redis upgrade path, as agreed in scope.
- Backup and monitoring: The partner can configure backup jobs, restore testing and alerting, while your team confirms recovery objectives.
- User tickets: Your help desk remains the first line for users, with defined escalation to the partner for platform faults.
- Staffing: Your team still needs an administrator who understands the course model, integrations and access control, even if infrastructure work is outsourced.
- Cost driver: Fees depend on the written scope, the number of environments and the support level chosen, so ask for each service to be priced separately.
Ask any partner to show the responsibility matrix, incident response terms and how it documents changes before you sign.
What drives the cost of each option
Brightspace and self-hosted Canvas LMS put cost in different places. A D2L subscription bundles the platform and most hosting, while running Canvas yourself moves infrastructure, database operation, support and upgrades onto your own budget and staff. Use the cards below to build a comparable list of components before you request quotes.
Brightspace subscription and add-ons
D2L does not publish list prices, so the subscription and any add-on modules must come from a quote against a written scope. Ask which features, sites, user counts and support tiers are included, and which are priced separately. This is a recurring cost, and it usually grows with enrollment or user count. Confirm the renewal terms and how price changes are capped before you compare it with a self-hosted total.
Canvas hosted subscription
If you stay with Instructure's hosted service, the recurring fee covers hosting, operations and vendor support, and the price is set by Instructure. Ask Instructure for a quote that states the user or enrollment basis, the support level and any integration limits. Compare the hosted fee directly with the self-hosted components below, not with the AGPLv3 code, which costs nothing to download.
Compute, memory and storage
The Canvas Production Start guide recommends a server with at least 8GB of RAM and an Ubuntu 22.04 LTS base, and it expects Apache with Passenger, a background jobs daemon and an SMTP service. Compute is recurring, and it rises with concurrent users, course media and the number of environments you keep for staging and testing. Ask your cloud or data center team to price a production tier and a non-production tier separately.
PostgreSQL and Redis operation
Canvas requires PostgreSQL 14 or later and Redis 6.x or above for caching and OAuth2. Operating these services includes patching, failover, connection tuning, monitoring and tested restores, and it recurs every month. Managed database services can reduce staff time but add a per-instance charge. Confirm which versions your chosen Canvas release supports before you size either service.
Backup, recovery and storage
Backups of the database, uploaded files and course media are a recurring cost that grows with retention length and the size of course content. Plan for at least one restore test, which is a one-time setup task with recurring repetition. Ask whether your backup tooling and offsite copies fall under your current licenses or need new spend, and confirm the recovery targets your institution requires.
LTI tool licensing and integrations
Brightspace and Canvas both host LTI integrations, but the tools behind them carry their own licenses, such as publisher content, proctoring, plagiarism checking and video. Each tool must be registered with the new platform, and some vendors charge again for a new LMS connection. Build a list of every LTI tool in use, then ask each vendor for its license terms for a self-hosted Canvas deployment before you commit to the move.
Staff time for operations and support
Running Canvas yourself means paying administrators for upgrades, plugin and configuration work, security patching and incident response, plus developers for any local changes. Staff time is the largest recurring cost in most self-hosted budgets, and it depends on how many environments you run and whether you need on-call coverage. Ask for a written split between internal staff and outside support, and state what each party is responsible for.
What a move from Brightspace to self-hosted Canvas LMS involves
The sequence turns a Brightspace estate into a tested Canvas LMS instance, with courses, tools, learner records and sign-in verified in order before any learner depends on it.
Inventory courses, LTI tools and integrations
List every active and archived course, every external tool launched from Brightspace, and every feed that moves data in or out, such as the student information system, enrollment syncs, and single sign-on. Assign an owner to each item and mark which courses must carry over for an open term. The step is done when the inventory names an owner and a keep, retire or rebuild decision for each item. Ask D2L and your own administrators to confirm which integrations are configured on your tenant, since the inventory depends on your configuration.
Export course packages from Brightspace
Export the courses marked to keep as course packages from Brightspace. Then open each package and check which components it carries, such as content modules, discussion topics, quizzes, question banks, rubrics, grade items, release conditions and calculated grades. Record the components that do not travel as a rebuild list for course designers. The step is done when every kept course has a package on file and the rebuild list covers each component the package omits. The sibling migration page covers the export detail.
Import Common Cartridge files into the Canvas sandbox
Import the Brightspace packages into a non-production Canvas course through the Course Import Tool. Canvas documents imports from Common Cartridge ZIP and IMSCC files, and from Blackboard exports, but the import guide does not describe Brightspace exports specifically, so treat the first import as a test. Compare the imported course against the original, module by module, and log each missing or altered item. The step is done when a test course matches the source for content and structure, and every defect has a ticket.
Review quizzes and question libraries
Open each imported quiz and question bank in Canvas and check question types, answer keys, points, feedback, randomization and time limits against the original. Confirm that question banks are linked to the right courses and that any item the import dropped is rebuilt by a course designer. Instructors should run one quiz as a student to confirm scoring. The step is done when each quiz has been checked, scored once end to end, and signed off by the course owner.
Archive learner records and grades outside the LMS
Export learner-level grades, enrollments and activity history from Brightspace using its data export tools, and store them in an archive your records policy covers. Do not rely on Canvas to hold historical grades for regulatory or appeal purposes unless your retention plan says so. Confirm the archive can be read without Brightspace running. The step is done when a sample of archived records has been opened and matched against the source for a few learners and courses.
Re-register LTI tools and integrations
Register each LTI tool in Canvas with its vendor, confirm the keys, launch URLs and permissions, and place it in the course navigation or assignment settings where instructors need it. Test one launch and one grade passback per tool, and re-point any scheduled feed from the student information system to the Canvas endpoints. Ask each tool vendor to confirm Canvas support in writing before cutover. The step is done when every kept tool launches from a test course and returns grades where required.
Cut over identity and single sign-on
Connect Canvas to your identity provider, map user attributes and roles, and test sign-in for students, instructors, administrators and guest accounts. Plan the switch so that accounts exist before the first course opens and the old Brightspace login is closed on a set date. The step is done when a test user from each role can sign in, reach their courses and see the right enrollment, and the cutover date is agreed in writing with the owner.
Run a pilot term before full cutover
Open a small set of real courses in Canvas as a pilot, with instructors who have tested their courses and a support route for questions. Track login problems, missing content, grading issues and tool failures, and fix them before the wider cutover. The step is done when the pilot has closed with no open high-severity defects and the owners have approved the full move. Set the pilot length with your academic calendar, since no timeline is given here.
What buyers ask before moving from Brightspace to self-hosted Canvas
How much effort does running Canvas LMS yourself actually take?
Running Canvas yourself is a continuing operations job, not a one-time install. The Canvas Production Start guide describes a production stack with Apache and Passenger, a background daemon for automated jobs, an outgoing SMTP server, PostgreSQL 14 or later, and Redis 6.x or above, and it recommends at least 8GB of RAM. Effort rises with the number of institutions or sub-accounts, the volume of courses and files, integration count, and how often you upgrade against the stable release tags. Ask any provider for a written scope that lists each of these components and who patches them.
Can our own team install and run Canvas without outside help?
A team with strong Linux, Ruby on Rails, PostgreSQL and mail administration skills can attempt it, but the Production Start guide does not offer vendor support. It directs people with installation problems to the community mailing list or IRC channel, so most institutions plan for either outside implementation help or internal engineers who already know this stack. Before committing, confirm who will handle a failed upgrade, a broken background job or a plugin conflict, and whether that person has time for it.
How long does a Brightspace to Canvas migration take?
No reliable duration can be given without knowing your content. The main drivers are how many courses and terms you move, how much of the content is Common Cartridge compatible, how many quizzes and question banks need rechecking, how many LTI tools must be re-registered, and how identity and SIS integrations are cut over. Ask any implementation partner for a fixed-scope written plan with milestones and a timeline agreed before work starts, and for an inventory of your course and integration volume that supports it.
What does the migration need from our institution's staff?
Expect demand from several groups at once. Administrators must agree on account structure, roles and data retention. Course owners must review imported courses, quizzes and question libraries. LTI vendors must provide or confirm credentials for re-registration. Identity and SIS staff must support single sign-on and enrollment feeds during cutover. Plan named owners for each group early, since delays in one group usually stall the cutover date.
Can we export our Brightspace courses and data before the contract ends?
Yes, but the formats differ by data type. Brightspace course content can be exported as course packages, and Common Cartridge is the format that Canvas's Course Import Tool reads as IMSCC or Common Cartridge ZIP files. Learner-level records such as grades, enrollments and activity history are not part of course packages and need Data Hub CSV exports. Confirm with D2L which export sets your contract includes, and check the Brightspace export guidance before you plan the archive.
Does Canvas import content from Blackboard as well as Brightspace?
Canvas's Course Import Tool can import Blackboard exports from versions 6, 7, 8, 9 and Ultra, according to Instructure's import guides. That covers Blackboard migrations in general, but a Brightspace course still has to reach Canvas through a Common Cartridge export. Test a sample course from each source system before you commit to a migration plan, because import results vary with the content type and any custom components.
Can Canvas LMS run inside our own cloud account or data center?
Yes. The Canvas code is released under the AGPLv3 license, so you can install it on servers in your own cloud account, a private data center or an isolated network. Your team or an implementation partner then owns the hosting, database, backups, patching and the AGPLv3 obligations that apply if you modify and distribute the code. Instructure's hosted service adds its own operations and support, which the self-hosted code does not include, so compare that scope with your team's capacity.
What does the AGPL code lack compared with Instructure's hosted service?
The repository gives you the application code, install guides and community channels, not Instructure's managed operations. Hosted service support, upgrades run by the vendor, uptime commitments and contractual support levels are not part of the open-source code. Ask Instructure for its current hosted terms in writing, and ask any self-hosting partner which operations, backups, security monitoring and upgrade tasks their written scope covers.
How DeployOpen helps you evaluate, implement or migrate Canvas
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Brightspace exit to self-hosted Canvas LMS, we start with a written scope that fits your courses, integrations and hosting constraints.
How we scope
- We agree scope, deliverables and timelines in writing before any work starts.
- The written scope lists which Brightspace courses, Common Cartridge exports and LTI tools are in or out.
- Engagements are fixed-scope, and ongoing support is available as a retainer after handover.
How we build
- We install Canvas LMS on your infrastructure following the project's Production Start guide.
- We configure PostgreSQL, Redis, the background job daemon and outgoing SMTP for your environment.
- We test Common Cartridge imports, quizzes and question banks on sample courses before any bulk migration.
How we hand over
- We document the installation, configuration, backup procedures and upgrade steps for your own administrators.
- We record which learner history was kept outside the LMS and where that archive is stored.
- We prepare the re-registration list for LTI tools and confirm each one with its vendor before cutover.
How we support
- Security testing of the Canvas deployment and its integrations can be scoped separately from the build.
- We prepare systems, controls and evidence for compliance assessments, but auditors issue any attestation.
- Upgrades, monitoring and continuous testing are available under a retainer agreed in writing.
