Skip to main content
OpenEduCat logo
solutionPage.moduleBadge

Open Source Hostel Management For Boarding Schools

A self-hostable LGPLv3 residence system built around the operational reality of full-boarding and weekly-boarding houses: per-house exeat and curfew rules, parent-approval workflows for off-campus leave, multi-house allocation with cross-house movement tracking, and a full safeguarding audit log of every warden, matron and...

Open source hostel management for boarding schools is a self-hostable LGPLv3 residence system built around the operational reality of full-boarding and weekly-boarding houses: per-house exeat and curfew rules, parent-approval workflows for off-campus leave, multi-house allocation with cross-house movement tracking, and a full safeguarding audit log of every warden, matron and houseparent action against a pupil. Unlike proprietary boarding suites built around a single vendor's idea of how a house should run, an open-source codebase lets DSLs, heads of boarding and external inspectors read exactly how leave approvals, room moves and after-hours sign-ins are recorded before a single boarder is loaded into the system. OpenEduCat publishes its complete hostel module source on GitHub, integrates natively with the main school MIS, fees and parent portal, and gives heads of boarding the same record-keeping rigour that Ofsted National Minimum Standards for Boarding Schools, the ISI Inspection Handbook and BSA Commitment to Care already demand on paper.

20Ofsted National Minimum Standards for Boarding Schools that a residence system must respect100%of warden, matron and houseparent actions written to an immutable audit log1unified record across hostel, MIS, fees and parent portal

solutionPage.featuresTitle

solutionPage.featuresSubtitle

LGPLv3 source transparency for safeguarding audit

Every line of the hostel module is published under LGPLv3 on GitHub, so DSLs, heads of boarding, IT leads and external inspectors can audit exactly how leave approvals, room moves, after-hours sign-ins and warden overrides are stored before the system goes anywhere near a boarder. "Free" SaaS boarding suites will not show you the code, will not tell you which third-country sub-processors see pupil data, and will not let a safeguarding lead diff a release before it ships. LGPLv3 means you (or a third-party auditor) can read the source, fork it, host a forensic copy alongside production and prove to an ISI inspector that the audit trail is not editable by the vendor.

Customisable per-house exeat, curfew and tuck-shop rules

House A runs a 21:30 prep-finish curfew, House B is sixth-form with 22:30 lights-out and Sunday open exeat, the Lower School house has zero exeat without houseparent signature and a tuck-shop ration of two purchases per week. Each rule is configured per house, per year group and per term in OpenEduCat without forking the codebase. Houseparents see only their own house's rule set; matrons and heads of boarding see the cross-house view. Rule changes are versioned in the audit log so an inspector can see who relaxed which curfew on which date and why.

Full safeguarding audit log of warden, matron and houseparent actions

Every sign-in, sign-out, leave approval, room move, sanction, reward, medication entry and houseparent override is written to an immutable audit log keyed to staff ID, pupil ID and timestamp. When an Ofsted boarding inspector, ISI team or DSL asks "who approved this Year 9 boarder's overnight stay off-campus and which deputy head countersigned", the answer is one filter away. The log is retention-policy aware so records survive long enough to meet statutory inspection timescales without manual archiving.

Integration with main school MIS, fees and parent portal

The boarder record IS the pupil record. House allocation, leave dates, medical flags, safeguarding flags and contact details all sit in one OpenEduCat database, so house fees and boarding extras land on the same invoice as tuition, parents see leave requests in the same portal they see reports, and the bursary does not reconcile three spreadsheets at half-term. No nightly CSV sync, no mismatched pupil IDs, no separate audit trail to defend in an inspection.

Multi-house allocation with cross-house movement tracking

Allocate pupils to houses, dorms and rooms; record sibling links, year-group bands and any safeguarding-driven separation requirements. When a pupil moves from one house to another mid-term, the move, the reason code, the approving staff member and the effective date are all recorded against both houses. House-masters keep local control of their own room plan; heads of boarding get the whole-school occupancy view in one screen.

Customisable parent-approval workflow for off-campus leave

Configure the exact chain of consent your school requires: pupil submits leave request, tutor sees it, houseparent approves, parent confirms via portal or signed e-form, host parent (if relevant) confirms, deputy head countersigns for any overnight or international leave. Each step is logged with timestamp and identity. Configurable rules can auto-block leave for pupils on report, with outstanding sanctions or with a parent who has not yet confirmed contact details for the term.

20
Ofsted National Minimum Standards for Boarding Schools that a residence system must respect
100%
of warden, matron and houseparent actions written to an immutable audit log
1
unified record across hostel, MIS, fees and parent portal
LGPLv3
open-source licence: read the source, fork it, self-host it inside the school firewall, audit it

solutionPage.faqTitle

solutionPage.faqSubtitle

What is the difference between open-source and free hostel software for a boarding school?

"Free" usually means no licence fee for a vendor-hosted SaaS hostel product. You do not get the source code, you cannot self-host inside the school's network, you cannot show an inspector exactly how leave approvals and after-hours sign-ins are recorded, and you cannot prove which sub-processors see pupil data. Open source under LGPLv3 means the code itself is published: a DSL can read it, the school can host it on a server inside the boarding-house firewall, an external auditor can verify the audit log is immutable, and the safeguarding committee can fork the module if a future requirement is not met. For boarding-school safeguarding the audit trail of who-saw-what is the whole point, and open source is the only way to prove it.

How does OpenEduCat compare to Reach Boarding, Boarders Plus and Sky Boarding?

Reach Boarding, Boarders Plus and Sky Boarding are well-established proprietary boarding suites with strong workflow features, but each is closed-source, hosted by the vendor in a jurisdiction the vendor chooses, and priced per-boarder per-year. OpenEduCat covers the same workflows (leave, exeat, sign-in, room allocation, parent approval, sanctions, rewards) and adds source-code transparency under LGPLv3, self-hosting (or hosting by a partner in your own jurisdiction), and native integration with the main school MIS, fees and parent portal because it is one platform rather than a third-party bolt-on. Schools that have ever had to extract data out of a proprietary boarding system at contract renewal know why source access matters.

Does this support KCSIE and Ofsted safeguarding compliance?

Keeping Children Safe in Education (KCSIE) and the Ofsted National Minimum Standards for Boarding Schools both require accurate, retrievable, role-restricted records of activity involving boarders, plus clearly defined access controls so that only authorised staff see safeguarding-sensitive information. OpenEduCat's hostel module ships with role-based access (houseparent, matron, deputy head, DSL, bursary) configurable per house, an immutable audit log of every action against pupil ID and timestamp, retention-policy controls aligned to statutory inspection timescales, and the ability to flag safeguarding-sensitive pupils so their record is only visible to the named DSL chain.

Can we customise rules per house without losing the upgrade path?

Yes. OpenEduCat's hostel module is built on the same Odoo-compatible inheritance model as the rest of the platform: per-house rules (exeat windows, curfew times, tuck-shop limits, sanction tariffs, sign-in cadence) are configuration data, not forked code. You change them in the settings, they get versioned in the audit log, and the next platform upgrade brings the new core features without flattening your house-specific configuration. Where a house genuinely needs bespoke behaviour, you (or a partner) extend the module in a separate add-on so the upgrade path is preserved. This is the killer open-source value proposition for boarding: real per-house customisation without ending up on an unupgradable fork.

How does the platform support BSA Commitment to Care alignment?

The Boarding Schools' Association Commitment to Care standards expect documented evidence of pastoral, welfare and safeguarding practice across the boarding day. OpenEduCat captures that evidence as a side-effect of running the house: each pupil record carries the running history of sign-ins, leave, medical entries, sanctions, rewards and houseparent contact, all timestamped and attributable to a named staff member. House-master daily-round screens, weekly pastoral notes and tutor pull-throughs to the academic side all draw from the same record, so the Commitment to Care audit narrative is generated from real operational data rather than reconstructed from emails and notebooks at inspection time.

How does this work for international boarding schools that need data sovereignty?

Because OpenEduCat is open source under LGPLv3, the school chooses where the database lives. A UK boarding school can host inside the UK; an international school in Singapore, Dubai or Switzerland can host inside its own jurisdiction (or with a regional partner) and prove to parents and regulators that boarder data never leaves that jurisdiction. Closed-source SaaS boarding products typically pin the data to the vendor's chosen region; with OpenEduCat the school sets the hosting policy and can change it without renegotiating a vendor contract, which matters for any house with boarders from a country whose data-protection regime restricts cross-border transfers.

¿Listo para Transformar Su Institución?

Vea cómo OpenEduCat libera tiempo para que cada estudiante reciba la atención que merece.

Pruébelo gratis por 15 días. No se requiere tarjeta de crédito.