Skip to end of metadata
Go to start of metadata

Web-based, open-source, Collections Management Software for museums and more ...

CollectionSpace is a web-based, open source collections management and information system for museums and other collecting institutions. You can use it to manage your museum's cataloging, acquisitions, loans, and many other activities.


If you're evaluating or implementing CollectionSpace, you can find readily navigable links to the currently available documentation in the left sidebar, as well as top-level links below.

Tip: The left sidebar makes finding documentation easier


To view the Table of Contents links in the left sidebar, click this icon in the upper-right area of this page:



Using CollectionSpace

If you are new to CollectionSpace, you can get a good sense of how it works from the demo available on the CollectionSpace website:  The User Manual describes how to use CollectionSpace to manage your collections. This manual also provides a useful overview of CollectionSpace's basic feature set.

Installing CollectionSpace

CollectionSpace is installed on a server and accessed using a web browser. No software needs to be installed on your users' computers.

We recommend installing CollectionSpace on a Linux Ubuntu 16.04 server.  You can find installation instructions here: Installing CollectionSpace.

Release Overview and Notes for v4.5


Areas of work for CollectionSpace Release 4.5 are listed below.

  • Preview of the user interface code re-write. A summary of this work, which will be released in 2017, can be found here.
  • Continued work on the community of practice profiles, including:
  • Continued design and development of the shared authority service CSPACE-6905 - Work related to shared authorities Open
  • Other bug fixes as prioritized by the CollectionSpace community.
  • Update code to work with OpenJDK 8
  • Update code to work with Nuxeo 7.x
  • Update recommended Linux platform to Ubuntu 16.04.1 LTS
  • Other bug fixes as prioritized by the CollectionSpace community.
  • Improve general error handling and documentation for CollectionSpace deployments, customization, and configuration.
  • Release of v1 of streamlined migration tool for CSV and other formats:
  • Release of OSS for deploying CollectionSpace via Docker and Ansible:
  • Release of tool for interating with the CSpace API / importing data (not migration):

For the current list of issues - bug fixes, feature enhancements, and more, please see the 4.5 issues filter in the project's issue tracker. You can also track progress on the current sprint by viewing the team's Agile work board.

Release Notes

  • Documentation for using and installing CollectionSpace
  • New Services Layer Features: JSON, OAuth 2, and CORS
  • "Optional" environment variables are needed to activate tenants/profiles.
    • etc...
  • Adding cache-control settings for services' HTTP responses -see CSPACE-7082 - Create a general mechanism for HTTP cache-control settings in the Services Resolved
  • Adding tenant bindings for declaring Nuxeo event listeners -see CSPACE-7083 - Adding tenant bindings for the Nuxeo event listeners. Resolved
  • Adding mechanisms for authorizing batch job invokation -see CSPACE-5985 - Administrator can set role permissions for reports and batch processes Resolved
  • SQL Script for migrating v4.4 Bonsai data to v4.5 schema -see CSPACE-7097 - Create script to migrate Bonsai v4.4 data and schema to v4.5. In Progress
  • SQL Script for migrating v4.4 Herbarium data to v4.5 schema -see CSPACE-7094 - Create SQL upgrade script for v4.4 to v4.5 Herbarium profile instances Open




Upgrading from version v4.1 or earlier to v4.5 or later

Upgrading to Tomcat 7

You'll need to upgrade the existing CollectionSpace Tomcat 6 to the new CollectionSpace Tomcat 7:

First, you'll set up the new Tomcat folder (sample instructions given here for Ubuntu 14.04):

Login to your Ubuntu server using an account with sudo privileges. Go to the directory where you want to install CollectionSpace. We recommend:

CollectionSpace runs as a Tomcat 7 server application. A pre-configured version of Tomcat 7 is provided with the CollectionSpace distribution package.

Start by downloading the CollectionSpace distribution package "tarball":

Unpack the tarball:

This will create an apache-tomcat-7.0.64 directory in /usr/local/share.

Next, make necessary files owned by the cspace user and executable:

You can now remove the tarball:

Then you will need to update any existing environment variables to reflect the path to the Tomcat 7 folder. Most likely, this will only be:


but, depending on how you set your variables, may also include: 


Changing a database table column name

You'll need to change the name of one column in the database:

Starting with version 4.2, due to an upgrade of one of its components, CollectionSpace expects that, in the accounts_tenants table of the cspace database, the column formerly named TENANTS_ACCOUNTSCOMMON_CSID will have been changed to a new name, TENANTS_ACCOUNTS_COMMON_CSID (i.e. with an underscore added between ACCOUNTS and COMMON.) As a result, you'll need to rename that column in your database to reflect this changed expectation.

(Note: if you've instance-qualified your CollectionSpace server, the name of the cspace database might include an instance ID suffix and thus its name may look something like cspace_myinstancename. If so, be sure to substitute that name for each instance of cspace in the instructions below.)

If you plan to continue to use your existing cspace database after upgrading to v4.2 - and you will want to do that under nearly all circumstances - you'll need to - just once - rename that column by sending two short commands to PostgreSQL.  To do so, connect to your PostgreSQL database server using either a graphical client or the command line psql client; log in via an account with administrative privileges, such as CollectionSpace's csadmin account or the default postgres account (if the latter is present); and then:

Connect to the cspace database:

Rename this column in the appropriate database table:

Adding new Environment Variables

You'll need to add several new, required environment variables (three when upgrading to v4.2, four when upgrading to v4.3 or higher):

New environment variable (CollectionSpace 4.2 and higher)Replaces earlier environment variablePurpose / notes


(no previous equivalent)

A string identifying a specific instance of a CollectionSpace server. It should begin with an underscore. The recommended value is simply _default  However, if your server will be part of a configuration where two or more CollectionSpace servers will be storing their data in the same PostgreSQL database server, set this instead to a unique name for your server; e.g., _myservername  (This string will be appended to the names of certain databases and database users, to help avoid naming conflicts.)

DB_HOST(no previous equivalent)The hostname or IP address for the machine/server running the PostgreSQL database server. E.g., localhost,, etc.
DB_PORT(no previous equivalent)The port number that the PostgreSQL database server is listening on. This is usually 5432.
JEE_PORT(no previous equivalent)The web port number used to access the web UI and services API. A default value of 8180 is appropriate. (This environment variable was first introduced in v4.3)

CollectionSpace System Requirements

In CollectionSpace System Requirements, you can find the system requirements for running a CollectionSpace system, as well as a list of supported web browsers for accessing your system.

Configuring CollectionSpace

If you are an implementer, consultant, or plan to host CollectionSpace, you can adapt CollectionSpace for the specific needs of your museum or client via the documentation in Configuring CollectionSpace.

The documentation in Configuring CollectionSpace focuses on configuration: changing the behavior and the look and feel of the system by making changes via web-based Administration pages and by editing text files: HTML templates, CSS stylesheets, XML- and JSON-based configuration files, and properties files.

To learn about customization - extending the system's functionality by working with the system's Java and JavaScript source code or adding code of your own - please see Developing for CollectionSpace.

Maintaining CollectionSpace

Once you have your deployment up and running, you'll want to take care of it. In Maintaining CollectionSpace, you'll find both operational suggestions and troubleshooting techniques.

Upgrading CollectionSpace

If you have an older version of CollectionSpace and want to upgrade it to a newer version, Upgrading CollectionSpace provides pertinent tips.

Migrating to CollectionSpace

When you want to migrate your existing data into a CollectionSpace system, Migrating to CollectionSpace can help you do this.

Developing for CollectionSpace

If you are building or integrating applications or scripts that talk to CollectionSpace systems, or are a CollectionSpace software developer, integrator, or implementer who wishes to extend the system's capabilities by working with its source code, you can find documentation on these topics in Developing for CollectionSpace. This topic area includes details about CollectionSpace's Application Programming Interfaces (APIs).

Hosting CollectionSpace

If you're hosting multiple CollectionSpace systems, whether in-house or as a service provider, Hosting CollectionSpace can help you find resources relevant to this task.

Reference Information

Reference Information provides supporting information and requirements for CollectionSpace, and includes general documents that are referenced from across two or more of the topic areas above.

Documentation Feedback

Many documentation additions and updates are planned. Please feel free to comment on the CollectionSpace project's Talk Mailing List if you have suggestions for improving current documentation, or if there is documentation you would like to see in the future.

  • No labels

1 Comment

  1. In the Configuring CollectionSpace section, a reviewer added this note:

    Need to elaborate on difference between developer and implementer documentation. Need to clarify not just what we mean by dev vs. implementer, but also when someone might want to use one set of documentation over the other (because they're not exclusive distinctions).