Three departments want their own digital exhibit online. IT does not want three WordPress installs with three plugin piles. The archives team needs Dublin Core that exports cleanly. The museum wants linked data, not a folder of JPEGs with vague filenames.
Omeka S (~530 GitHub stars, GPLv3 from the Corporation for Digital Scholarship) is built for that GLAM shape: one installation, many sites, one shared pool of items, media, and metadata. Universities, libraries, archives, and museums use it to publish collections, class projects, and finding aids without each group rebuilding the same catalog from scratch.
How it is organized
Think network, not single blog:
- Items, item sets, and media — the shared collection layer; items can represent objects, people, places, or events and link to each other for complex stories.
- Resource templates — reusable metadata forms built from RDF vocabularies (Dublin Core, FOAF, BIBO, plus imports); DPLA-ready templates ship for federal aggregation workflows.
- Sites — independently themed exhibits built from pages, layout blocks, and selected resources from the pool.
- Modules and themes — extend with maps, imports, CSV ingest, Omeka Classic bridges, and site-specific design without forking core.
- API — REST with JSON-LD as the native data format for linked open data publishing.
Omeka Classic still exists for simpler single-site projects. Omeka S is the answer when central IT wants one LAMP stack and many curators.
Why self-host?
Institutional control. Collection metadata, uploaded files, and access rules stay on your server, not a hosted trial that caps items or disappears when funding shifts.
Multi-site without multi-server. Add a site for a faculty seminar this term and another for a permanent archive gallery; supervisors manage users and vocabularies once.
Interoperability. JSON-LD, RDF vocabularies, and modules for Fedora, DSpace, Zotero, and CSV meet the "connect to campus systems" requirement better than a generic CMS with an gallery plugin.
Canadian hosting. A Canadian university or heritage org hosting on Beauharnois or Toronto infrastructure keeps object files and patron-facing sites under the same residency story as the rest of the public web presence.
Stack honesty. Omeka S is LAMP: Linux, Apache, MySQL/MariaDB, PHP (see the official system requirements). Node is only for building front-end assets during install or updates (npm install, npx gulp init from git, or use the release ZIP). Plan backups for the database and the writable files/ directory. GPLv3 applies to the software; "Omeka" is a registered trademark, so read branding rules if you white-label.
Getting it running
Fast path for production: download the latest release ZIP from GitHub, create MySQL database and user, edit config/database.ini, make files/ writable by the web server, browse to the URL and finish the web installer.
Developers clone from GitHub, run gulp init, then the same browser setup. Updates need backups first; git installs run npx gulp deps and reconcile local.config.php with the dist template.
On Swift Host, this fits managed VPS or dedicated LAMP hosting with enough disk for high-resolution scans and a routine MySQL dump job.
Who it's for (and who should skip it)
Good fit: university digital humanities labs, regional archives, small museums, library special collections, any institution publishing structured metadata plus interpretive sites.
Skip it: if you need a corporate marketing site with a blog (use WordPress or your main CMS); if you cannot maintain PHP/MySQL security patches; if a single simple Omeka Classic site is enough and you will never add a second exhibit.
Bottom line
Omeka S is the institutional publishing layer between cataloging standards and public storytelling: one install, many exhibits, shared items, linked data out of the box. Self-hosting is how you keep that pipeline on your terms.
Talk with Swift Host if you want LAMP sizing, TLS, and backup scope for Omeka S on Canadian servers. We are in St. Albert and actually answer the phone.
