Helderwyn Museum of Making: a self-hosted CMS for museums — an open-source .NET museum website

For each Raytha use case we take a realistic brief, build the site on a fresh Raytha instance, and publish what comes out: the site, the files behind it, and a kit you can use to rebuild it yourself. This one is a museum website — the page a visitor opens to see what is on view, the accession label a teacher reads before a school tour, and the sign-in a member uses to open an exhibition packet or book a Study Vault table. It is written for the agencies and freelancers who build sites for museums, historic houses and craft collections, and for museum IT and web teams that want to own their stack.

If you are looking for a self-hosted CMS for museums, or an open-source .NET CMS for museum websites, this is the kind of site that fits: exhibitions with wall text, a floor plan of galleries, collection objects with accession numbers, programs, people and journal as structured content, server-rendered pages, and a members-only room and staff room built on Raytha's own user accounts and groups. Built on a fresh Raytha instance, with no client-side app in the layout.

Helderwyn Museum of Making is fictional. The museum, the river town of Rookwater, its people, objects, exhibitions and figures are invented and labeled as such, and phone numbers use the 555 range. There are no payment, registration, upload or sign-up forms; the member and staff accounts exist only for the demo.

A museum site built around the accession wall

Most museum sites bury the collection behind a search box and a stock photo of a white gallery. Visitors and teachers mostly come with one question — what is on the wall, and where — so this site is organized around labels and a floor plan.

• The accession wall. The home page is a gallery wall of featured objects. Each card shows a generated plate, the accession number (HMM.year.sequence), the maker and the date — the same fields a wall label carries in the gallery. Object pages add materials, dimensions, credit line, on-view status and the gallery on the plan.
• A floor plan as navigation. Six galleries are drawn on a plan: Entry Hall, Tool Hall, Textile Wing, Ceramic Court, Workshop Gallery and the Study Vault. Each room is a link; gallery pages list the objects, exhibitions and programs that live there.
• Exhibitions with wall text. Current, upcoming and closed shows, each with a status, dates, curator, wall text and a list of featured accession numbers that pull the matching objects onto the page.
• Programs. Tours, demos, talks, family Sundays, school groups and member evenings. Public programs are open with admission; member and staff programs stay hidden when you are signed out.
• People, journal and visit. Curators and educators with roles; a short journal of installs and Vault notes; a visit page with hours and how admission works at the desk (no online checkout on this site).
• Site search across exhibitions, objects, galleries, programs, people, journal and packets.

Design: the accession wall

The look is a museum wall label on warm paper: cream walls, deep ink, a museum red for accession numbers, brass and moss accents carried from the Tool Hall into the cards and the plan. Headings are set in Source Serif 4, body text in Public Sans, and accession numbers, stamps and meta in Courier Prime. There are no wide display fonts. Object plates, exhibition posters, gallery plans and portraits are generated, so no real object, building or person is pictured.

Why a museum looks at a self-hosted CMS

• Collection data stays on infrastructure you control. Accession numbers, loan files and member accounts are the kinds of records museums are careful about. With Raytha, the content, the member sign-ins and the server logs stay on servers the museum or its IT provider controls, and the public pages carry no tracking or advertising scripts.
• Members-only areas without a second product. Raytha has public user accounts and user groups. Exhibition packets, favorites lists and Vault booking notes check CurrentUser.UserGroups in the template on the server, so a packet is never sent to a browser that should not see it. The same feature runs a small staff room for loan checklists and gallery notes.
• No per-seat pricing. Curators, educators, registrars, docents and seasonal staff can each have an editor account, and every member can have a sign-in. Raytha has no seat licensing, which matters for a museum whose volunteer and seasonal head count changes with the exhibition calendar.
• You own the code and the content model. Raytha is open source. Exhibitions, objects, galleries and packets are content types you define; the templates and content are files you can keep in your own repository, hand to the next agency, or move to a new server without asking anyone.
• On premises and .NET, if museum IT needs it. Many museums already run Windows servers and .NET line-of-business software, or have a county or university IT provider who does. Raytha is ASP.NET Core with PostgreSQL, so it can run on the museum's own network or private cloud. Single sign-on, role-based admin permissions and audit logs are built in. You can also deploy it on Railway.
• Works next to the collections system. The collections management system, ticketing and the donor database stay where they are. Raytha runs the public site around them, and its REST API and webhooks can carry object lists or exhibition dates in from other systems.

Raytha fits museums, and the agencies that build for them, that want to own their stack: the code is open source, the content model is yours, and the site can run on servers the museum or its IT provider controls, with member accounts kept in-house. If the museum would rather not run it, Raytha can be fully hosted and managed for you under contract. Where another platform may suit you better is if you need a large plugin marketplace, or an all-in-one marketing suite with CRM and marketing automation built in. For fair comparisons with platforms museums and .NET teams often evaluate, see Raytha vs WordPress, Raytha vs Umbraco, Raytha vs Kentico and Raytha vs DNN.

How the members-only areas work

• Two user groups: members and staff. Staff accounts can see everything members see; admins see everything.
• Each packet and some programs have an audience field (everyone, members, staff). The detail template reads it and the signed-in user's groups and renders either the content or a lock panel with a sign-in link. The packets list marks member packets with a lock and leaves staff checklists out for everyone else, and so does search.
• The members room at /members is a site page with its own template: signed out, it explains what is behind sign-in; signed in as a member, it shows a member card, member programs, exhibition packets, favorites lists and Vault booking notes.
• The staff room at /staff-room shows desk coverage, staff programs, loan intake and return checklists and gallery notes, only for staff accounts. A signed-in member sees a short note pointing back to the members room.
• Sign-in uses Raytha's built-in login page, restyled to match. There is no registration form: in the story, a member account is opened at the desk when you join. For more on the pattern, see creating a members-only website.

What is in the kit

Seven content types (exhibitions, objects, galleries, events, people, journal, packets), two user groups, site pages for About, Visit, Membership, Search, the members room and the staff room, menus, and generated object plates, posters, gallery plans and portraits — all rebuildable with one command from the kit in the examples repository. Route check: 87 routes checked, 0 failed.