What to Look For in an Omeka Hosting Provider

Omeka is not demanding software. It needs PHP, a database, somewhere to put files, and that is roughly it. Which means almost any web host can technically run it, and almost any web host will happily tell you so.

The trouble arrives later — at upgrade time, at backup time, at the moment a collection grows past what a shared hosting plan was ever meant to hold. By then you have thousands of items and a URL in print somewhere, and moving is expensive.

So it is worth being a little demanding at the start. Here is what we would ask, whether or not you end up hosting with us.

Who does the upgrades?

This is the single most revealing question, and the answer separates real Omeka hosting from generic hosting with Omeka installed on it.

Omeka releases security and feature updates. So do your modules and themes. On a generic host, applying those means logging in over SFTP, replacing directories, running a database migration, and hoping. Most institutions we talk to have at least one site sitting several versions behind, not because anyone decided that, but because the person who knew how to do it left.

Ask the provider directly: when Omeka releases a new version, what happens? If the answer is "you can upload it," you are on generic hosting. If it is "we handle it" or "you click a button," you are somewhere that actually knows the platform.

What happens before an upgrade goes wrong?

Upgrades occasionally break things. A theme depends on a function that changed; a module has not caught up with the new release. This is normal and survivable, but only if there is a way back.

The question is not "do you take backups" — everyone says yes. It is when. A nightly backup is good. A backup taken automatically immediately before the upgrade runs is better, because that is the exact moment things break, and restoring to "last night" means losing a day of cataloguing on top of everything else.

Ask how far back backups go, how long a restore takes, and whether you can trigger one yourself or have to file a ticket and wait.

Can you use your own domain, with SSL, without a project?

Your collection should live at a URL that belongs to your institution. Not a subdomain of your vendor's marketing site, and not something you will be embarrassed to print.

Most hosts allow custom domains. The thing to check is how much work it is, and whether the SSL certificate is included, automatic, and renews itself. Certificate renewal is exactly the kind of task that works fine for two years and then fails on a holiday weekend. It should not be anyone's calendar reminder.

It is also worth asking whether you get a temporary subdomain to work on before launch. Building a site in public because there is nowhere else to put it is a bad way to start.

Are modules and themes limited?

Some hosting plans cap how many modules you can install, or restrict you to an approved list. Sometimes there is a defensible reason — a module with known performance problems, say. Often it is just a way to tier the pricing.

Ask what the limit is and why. Ask specifically whether you can install a module that is not in the official directory, because sooner or later you will want one: something a colleague at another institution wrote, or something built for you. A host that cannot accommodate that is a host you will outgrow.

Who else can log in?

Digital collections are rarely a one-person job, and they should not be a one-login job either. If your account has a single set of credentials shared between three people and a student worker, you have no audit trail and a problem the day someone leaves.

Look for real multi-user accounts, where colleagues get their own logins and you can add and remove people yourself without contacting support.

What happens when you want to leave?

Ask this one even if you have no intention of leaving. The answer tells you how the provider thinks about you.

You should be able to get a full export — database and files — without a support ticket, a fee, or a negotiation. Digital collections are institutional assets with lifespans measured in decades. Any arrangement that makes them hard to move is a preservation risk, whatever else it is.

Do they know what a library is?

Less concrete than the rest, but it matters more than it sounds. Generic hosting support is competent at generic hosting problems. They are not going to know what a finding aid is, why your metadata mapping matters, or why an item's identifier cannot simply be regenerated.

You want the person answering your ticket to understand the collection, not just the server it sits on. The way to test this is to ask a domain question during evaluation and see what comes back.

A note on cost

Managed Omeka hosting costs more than a generic shared plan. That is straightforwardly true and we are not going to pretend otherwise.

What you are buying is the upgrades getting done, the backups existing before you need them, the certificate renewing itself, and someone who knows the platform picking up the phone. Whether that is worth the difference depends on how much staff time you have, and on how you would feel about explaining a lost collection to your director.

For a lot of institutions the honest answer is that a generic host is fine — they have technical staff, they enjoy this work, and they would rather control it themselves. If that is you, host it yourself with our blessing.

For everyone else, the checklist above is the one we would use. Hold us to it too.