DSpace hosting: managed cloud or your own server?

What DSpace needs to run

As our overview of what DSpace is explains, since DSpace 7 the platform has consisted of two separate applications that can live on the same machine or on different ones. It is worth understanding, because it changes how you size the server.

• Backend: a Java application that exposes the REST API. Traditionally it is deployed inside an application server such as Tomcat; since DSpace 8 it is also distributed as a runnable JAR with embedded Tomcat, which simplifies operations considerably. It needs a modern Java runtime: Java 21 for DSpace 10, Java 17 for DSpace 8 and 9. Current releases no longer run on Tomcat 9.
• Frontend: an Angular application with server-side rendering that runs on Node.js and consumes the API. It is what end users see. In DSpace 10, its base URL configuration must match the backend's exactly, or server-side rendering and redirects break.
• PostgreSQL: the database that holds metadata, users, permissions and references to files. Oracle support has been discontinued, so every current installation runs on PostgreSQL.
• Solr: the indexing engine, organized in several cores. The search core powers search and facets, oai serves OAI-PMH, statistics stores usage data and authority holds authority control. The first two can be rebuilt by reindexing; the last two cannot, because that data exists only there.
• The assetstore: the directory where deposited files live. It sits outside the database and is almost always the partition that grows fastest.

It is a stack with more parts than a library catalog. That is why, when BiblioLabTech implements DSpace for a university, the infrastructure conversation happens in the first meeting rather than at the end of the project: it defines timelines, recurring cost and who gets called when something goes down.

Storage: the difference that surprises

The database of a typical university repository takes only a few gigabytes, because it holds metadata. What grows is the assetstore, and it grows fast, because every item brings real files. A useful order of magnitude for budgeting: a PDF thesis with images runs between 2 and 20 MB, a scanned article a few MB, and a dataset or a video can reach hundreds of MB each.

The practical consequence is that disk is sized on the expected annual growth of deposits, not on today's collection, plus room for backups and indexes. For a new repository, the rule we use is simple: estimate the gigabytes of the first year, multiply by three to leave margin for growth and backups, and require storage that can be expanded without migrating the instance. Running out of disk in a repository does not just stop deposits; it can also stop indexing and leave search results out of date without anyone noticing.

A complete DSpace backup is two backups

This is the point we have most often seen handled badly, even at institutions with a strong IT department. In DSpace, a complete backup means two backups: the PostgreSQL dump and a copy of the assetstore. Backing up only the database leaves a repository that starts, shows every record and cannot deliver a single file. Backing up only the files leaves a folder of PDFs with no descriptions, no structure and no permissions.

There is also a correct order: database first, then files. DSpace treats the database as the authoritative record, so it is better to end up with a file on disk that the database does not know about (invisible and harmless) than with a record whose file does not exist, which users will find and fail to download. As a complement, DSpace can export the entire hierarchy as METS-based AIP packages that bundle metadata and files together. That is more consistent but slower and heavier, so the sensible approach is to combine both schemes at different frequencies.

DSpace hosting models: managed cloud vs. your own server

Neither model is better in the abstract. The choice depends on whether the institution has an infrastructure team with real capacity to take on one more service, and on how strict its data policies are.

There is a middle ground that works very well for universities with strict data policies: the server belongs to the institution, physical or in its own cloud account, and the provider administers DSpace remotely. The data never leaves the campus, and operations stay with people who know the platform. It is the model BiblioLabTech applies when the IT department requires the machine to remain under its control.

At the other end is Universidad Americana in Paraguay, whose DSpace repository BiblioLabTech hosts and operates with HTTPS, automated backups and monitoring included. For a library without a dedicated infrastructure team, that model removes in one stroke the question of who applies Friday's security patch.

Domain, HTTPS and discoverability

The repository should live on a university subdomain, such as repository.university.edu, and never on a provider's domain. This is not about branding: every item in the repository will be cited, and if the domain changes with the provider, every published URL changes too. Technically it only requires pointing a DNS record.

The TLS certificate should renew automatically, and there is a DSpace 10 detail worth checking with your provider: the reverse proxy, Apache or Nginx, must forward the Host header correctly, because server-side rendering of the frontend depends on it. Done wrong, this produces a repository that works for people but is invisible to search engines.

The same logic extends to interoperability. If the repository is to be harvested by aggregators such as OpenAIRE, BASE or CORE, the OAI-PMH endpoint must be published, reachable from outside and compliant with the relevant metadata guidelines. A repository without exposed OAI-PMH exists only for people who already know its address. Funders are raising the bar as well: under Plan S, a compliant open-access repository must be registered in OpenDOAR, assign persistent identifiers to deposited versions, provide article-level metadata under a CC0 dedication and guarantee uptime of at least 99.7%, excluding scheduled maintenance. Hosting decisions feed directly into that last requirement.

Backups, availability and the SLA

A backup that has never been restored is not a backup. These are the parameters worth putting in writing:

• Scope: database and assetstore. If the proposal only says "daily backup", ask explicitly whether it includes the files.
• Frequency: a daily database backup; the assetstore supports incremental backups, because files already deposited do not change.
• Retention: 15 to 30 days for the database, plus a longer-term monthly copy of the files.
• Location: off the production server. A backup on the same disk protects against nothing.
• Restore test: at least once a year, documented, restoring both layers together.
• RTO and RPO: how long the service may be down, and how many hours of deposits can be lost in the worst case.
• Committed availability: 99.5% monthly uptime allows about 3.6 hours of downtime per month; 99.7% about 2.2 hours; 99.9% about 43 minutes.

For a repository, the RPO usually matters more than the RTO. A site that is down for two hours is an annoyance; losing a week of deposits at the end of a semester is a problem of a different kind.

Questions to ask a DSpace hosting provider

1. Which DSpace version do you install, and how often do you apply maintenance releases? With DSpace 10.0 released in May 2026 and 10.1 in September 2026, the supported lines are 8.x, 9.x and 10.x.
2. Does the backup include the assetstore as well as the database, and in what order are they taken?
3. How much storage does the fee include, how much does expansion cost, and how fast can it be done?
4. Is the server dedicated to my repository or shared with other institutions?
5. What monthly availability do you commit to, and what happens if you miss it?
6. If I decide to leave, will you hand over the PostgreSQL dump and the complete assetstore, within what time frame and at what cost?
7. Do the domain, the certificate and, if there is one, the handle prefix stay in the institution's name?
8. Does support cover questions about using the repository, or only infrastructure incidents?

The sixth question is the most important and the least asked. DSpace is free software and the data belongs to the university, so any serious provider should deliver a complete copy of both layers without argument. The seventh has a consequence that is easy to miss: if the handle prefix is registered to the provider, changing providers means breaking every published citation, a problem we cover in our DSpace migration and upgrade guide.

When each model makes sense

Choose managed cloud if the IT team has no capacity for one more service, if nobody at the institution administers Java and PostgreSQL, if you want a predictable cost that includes storage growth, or if the repository must be continuously available for harvesting by aggregators.

Choose your own server if institutional policy requires files to stay on campus, if you already run virtualized infrastructure with formal backups and trained staff, or if the repository must integrate with internal systems that are not exposed to the internet. Consider the hybrid model, an institutional server with external administration, when both sets of conditions apply.

In all three cases the software is the same and moving between models is feasible: it comes down to transferring a database, an assetstore and a set of configuration files. If you are also considering a research information layer, sizing changes, so read what DSpace-CRIS is first. If you need the overall project figure, it is in our guide to DSpace implementation cost. BiblioLabTech quotes its DSpace implementation service with and without hosting, as two separate lines, precisely because the right answer depends on each institution.