Skip to main content
  • Subscribe by RSS
  • Ex Libris Knowledge Center

    Technical Requirements for Alma and Discovery Implementation

    Ex Libris Alma is a pure cloud-based Software-as-a-Service (SaaS). Its architecture is based on leading cloud technologies, offering a secure, scalable SaaS. As a SaaS solution, Alma is accessible over the Web, requiring only a Web browser for the user. The move to a cloud-based SaaS offers great benefits and cost savings, together with faster response time to user requests. This document describes Alma cloud fundamentals, the technology driving the Alma cloud, the IT side of the Alma cloud infrastructure, and the Alma cloud's interaction with on premises institutional/campus systems. 

    The Alma Cloud Deployment Model

    Ex Libris operates its cloud infrastructure as a private cloud, which is solely available for use by its customer community. This deployment model differs from a public cloud, which is available to the general public, or a hybrid cloud, which is a combination of two or more clouds.
    Private cloud implementation provides Ex Libris with the opportunity to benefit from cloud computing without compromising on the architectural control required to ensure integrity of its customers’ data, systems, and processes.
    This document goes hand-in-hand with Getting Ready for Alma and Discovery Implementation.

    Making the Cloud Vision a Reality

    True Multi-Tenancy

    The Alma system is based on multi-tenant architecture, in which the resources – both the software and the underlying infrastructure – are shared, in order to support all customers (“tenants”).
    Strict data isolation is applied to all layers of the Alma application: user-interface branding isolation, database isolation (via Oracle Virtual Private Database), storage isolation, and FTP-level isolation, etc.
    Ex Libris’ resources are focused on maintaining a single, current version of the application, rather than attempting to support multiple software versions for clients. As a result, no client is left behind when the software is updated with new features and innovations. Moreover, this delivery model enables Ex Libris to provide its customers with a fault-tolerant computing environment that includes dynamic resource allocation.

    Vendor-Managed Updates

    Because Alma is designed in accordance with the SaaS model, and deployed as a cloud-based service, it is Ex Libris' full responsibility to handle the software updates and upgrades. Ex Libris is committed to ensuring that its customers always have access to the latest features and incurs all the costs of maintaining and upgrading the required software. This enables all customers to fully take advantage of the latest Alma features and innovation.
    Monthly releases and software updates are performed automatically by Ex Libris seamlessly, without any customer intervention.

    Seamless Integration/Open Platform

    Alma embodies Ex Libris’ Open Platform philosophy. This enables openness and interoperability between Alma and the other institutional/campus systems.
    The Open Platform means open interfaces. It contains Web services, Web adapters, Application Programming Interfaces (APIs), plug-in interfaces, and more.
    The Open Platform allows customers to share customer-written code so that one customer can benefit from the developments of another customer, leveraging the investments made by others for the benefit of everyone.
    The following illustration demonstrates the various options for utilizing the Alma Open Platform to integrate with on premises systems that are part of the institution and library landscape.
    Alma Open Platform.png
    Alma Open Platform


    Cloud security and confidentiality are top concerns with cloud computing and SaaS architecture. Committed to providing its customers with the most secure and reliable environment, Ex Libris has developed a multi-tiered security model that covers all aspects of cloud-based Ex Libris systems. The security model and controls are based on renowned international protocols and standards and industry best practices, such as ISO/IEC 27001:2013 and ISO/IEC 27018:2014, the standards for an information security management system (ISMS).

    Performance and Service Availability

    Ex Libris is aware of the fact that the performance of its cloud applications can have a significant impact on customer adoption and satisfaction. Ex Libris’ cloud data centers leverage their infrastructure-renowned technologies and applications in order to meet the performance service-level agreements (SLAs) to which the Ex Libris is committed.
    Moreover, Ex Libris employs a dedicated cloud services team, which is responsible for monitoring the applications and platform performance and issuing periodic SLA reports.

    Network Communication

    As a library management solution, Alma must communicate with different on premises library systems. This section describes the different on premises systems with which Alma may need to communicate and the communication methods used. Ex Libris ensures that all network communication is done using the appropriate security measures. Therefore, Ex Libris uses up-to-date protocols and standards such as HTTPS and TLS 1.2 (see TLS Support). TLS is an updated and more secure version of SSL. TLS refers to the TLS 1.2 protocol.

    Browser Communication

    As a true cloud solution, Alma requires only a browser. Alma supports all the leading browsers: Chrome, Firefox, and Edge. There is an ongoing process of monitoring new browser versions and certifying their compatibility with Alma. Full browser certification details for Alma can be found here. Browser support information for Primo can be found here, and for Summon here.
    Browser to Alma communication is conducted using TLS, over ports 443. The URLs (domains) to be used are provided to you by your Ex Libris project manager.
    To maintain a consistent level of security and user experience, the use of proxy servers to monitor and control traffic to and from the Alma and Discovery platform will impact the support level and user experience we are able to provide and, as a result, is not supported.

    Network Communication

    To function properly and completely, Alma must communicate with different on premises installed systems, such as financial systems, student information systems (SIS), self-check (SIP) machines, and other third-party systems.
    The sections below describe the different components that Alma may communicate with outside of its cloud network. There is a table listing the different network communications used, as well as a network diagram illustrating the communication, protocol, and direction (in/out). Not all listed communications are necessarily relevant for each institution.
    Ex Libris MFT (Managed File Transfer) provides secure and reliable file transfer infrastructure to support the different Ex Libris products (See Ex Libris MFT). Alma also supports secure FTP (SFTP – over SSH, but not FTPS over TLS) using port 22 or standard FTP using port 21.

    Higher-Ed Platform IP Range

    Some on premises systems with which Higher-Ed products integrate (for example, ERP, SIS, SFTP, SIP machines) may require these Ex Libris regional IP/s in order to communicate with Alma.
    The following IP ranges must be allowed access to/from your institution. (Note that the IP ranges below are in CIDR notation, first/last IP address included.)
    • In the U.S.A. (refers to the NA01, NA02, NA03, and NA04 instances on the Chicago data centers and the NA05, NA06, and NA07 instances on the Seattle data centers):
      • []
      • []
      • [] -  Note that is to enable calls from the Community Zone.
      • []
      • []
      • []
      • []
      • []
      • []
      • []
      • []   
    • In Canada (refers to the Ex Libris Canadian data center):
      • []
      • []
      • []
      • []
    • In Europe (refers to the EU00, EU01, and EU02 instances on the Amsterdam data centers and the EU03, EU04, and EU05 instances on the Frankfurt data centers):
      • []
      • []
      • []
      • []
      • []
      • []
    • In APAC (refers to the AP01 instance on the Singapore data center and the AP02 instance on the Sydney data center):
      • []
      • []
      • []
      • []
      • []
      •  []
      • []
    • In China (refers to the Ex Libris Beijing data center):
      • []

    Access to the above IP ranges may require firewall settings at the institution level and inclusion in the institution's SPF DNS record (in order to avoid Alma emails potentially being handled as spam).

    Primo Classic IP Range

    The following IP ranges must be allowed access to/from your institution. (Note that the IP ranges below are in CIDR notation, first/last IP address included.)
    • In the U.S.A.:
      • (MT NA01 and TC NA)
      • (MT NA02)
      • (MT NA03)
      • (MT NA04) 
      • (MT NA05)
      • (MT NA sandbox)
      • []
      • []
      • [] (SMTP Mail Gateway)
      • (S/FTP)
      • [] (MT NA05 and TC NA sandbox)
      • –
      • –
    • In Canada:
      • (MT CA01)
      • (MT CA01 sandbox)
      • (CA01 implementation)
    • In Europe:
      • (MT EU01)
      • (MT EU02)
      • (MT EU03)
      • (MT EU04)
      • (TC EU)
      • (MT EU sandbox)
      • []
      • –
      • –
    • In APAC:
      • (MT APAC)
      • (MT APAC03)
      • (TC APAC)
      • (TC APAC02)
      • (MT APAC sandbox)
      • []
      • –
      • –
    • In China:
      • (sandbox)
      • (implementation)

    Primo VE IP Range

    Primo VE uses the same IP ranges as the Higher-Ed Platform. For details, see Higher-Ed Platform IP Range.
    In addition, the following IP ranges must be allowed access to/from your institution:
    • In the U.S.A.:
      • –
      • –
    • In Europe:
      • –
      • –
    • In APAC:
      • –
      • –

    Summon IP Range

    There are no special IP requirements for communicating with Summon; Summon’s IP requirements are covered by the Higher-Ed Platform. See Higher-Ed Platform IP Range.

    Bandwidth Requirements

    Number of Alma Named Users Required Minimum Network Bandwidth
    Up to 50 0.025 MB per user
    Above 50 0.015 MB per user
    Above 200 0.01 MB per user
    For example:
    • 10 Alma named users = 0.25 MB
    • 500 Alma named users = 5 MB


    This section is not relevant to Primo VE, which is deployed on the Higher-Ed platform.

    Ex Libris Primo customers that are also Alma users work with Primo in the Ex Libris cloud and thus benefit from a complete cloud environment and smooth updates of both solutions. Alma and Primo communicate within the Ex Libris cloud network and the only external communication is between patrons and Primo functions over port 80 or 443.

    If you have PCs in your institution that are open only to specific servers and ports (and specifically to Primo), make sure that these PCs/firewalls are also open to the Alma server and port.

    If the customer is using on premises / local Primo deployment, Alma communicates with Primo in a bi-directional manner, as follows:

    • Alma to Primo: an OAI-PMH XML of published metadata is sent from Alma to Primo via Secured FTP over ports 21/22

    • Alma-Primo: bi directional HTTPS communication of patron services over port 443

    For more information on Alma-Primo integration, refer to the Alma-Primo Integration Guide.

    Alma-Primo Patron Services

    Patron requests delivered to Alma via Primo (Get It, View It, and so forth) are verified and authenticated prior to any service being rendered. The flow is such that patrons are first required to authenticate external to Alma. After they successfully authenticate, Alma communicates with Primo in a bi-directional manner, over a secured HTTPS port (443), in order to validate the patron authentication prior to providing the requested services.

    Primo Back Office

    This section is not relevant to Primo VE, which is deployed on the Higher-Ed platform.

    In order for staff users to access the Primo Back Office, outgoing HTTPS communication must be allowed/opened on port 1443.

    Alma-MetaLib (when MetaLib is in use)

    For local installations of MetaLib, where MetaLib communicates with Alma for full-text indication, the communication between Alma and MetaLib is via API over HTTP port 80.
    For hosted MetaLib, Alma and MetaLib communicate within the Ex Libris cloud network.


    Summon and Alma are both hosted services and thus benefit from a complete cloud environment and smooth updates of both solutions. Alma and Summon communicate within the Ex Libris cloud network, and the only external communication is between patrons and Summon over port 80 or 443.
    Metadata published from Alma to Summon is sent with secure FTP using port 2022.

    Alma-Summon Patron Services

    Patron requests in Summon (Get It, View It, and so forth) are verified and authenticated prior to any service being rendered. User authentication is provided by Alma. For more information, see the Alma-Summon Integration Guide.

    Summon Admin Console

    The Summon Admin Console is accessed by staff users through Alma, using port 443.

    Alma – Self-Check Machines/SIP-based Systems

    Alma supports communication over the SIP2 protocol, which is used primarily for communication with local self-check machines. The communication is bi-directional.
    Since the vast majority of the SIP-based systems were built and designed without the cloud in mind, the SIP2 protocol lacks several components in order to fully support a cloud-based SaaS – namely, a unique institution ID and secure communication channel (which is supported in SIP3). Once SIP3 becomes the de-facto standard with cloud capabilities, Ex Libris will support it as well.
    To secure SIP2 communication, Alma uses an open source TLS encryption wrapper called Stunnel ( This is a lightweight component installed locally on standard operating systems, such as Linux or Windows (see supported operating systems: This component creates a secure TCP "tunnel" communication over port 6443 (which is open to all and not limited to any IP range) with Alma and also serves as a means to uniquely identify and securely route each institution’s requests.
    The communication flow is as follows:
    • The SIP2 local machines communicate with Stunnel software that is installed on the local Windows/Linux workstation.
    • The Stunnel encryption component encrypts the TCP communication using a standard encryption method and a security certificate, and will send the SIP2 requests to the Alma cloud over the secure port 6443.
    The following diagram describes this architecture:
    Alma Secured SIP Communication.png
    Alma Secured SIP Communication

    Alma – Financial/SIS Systems/Vendor EOD, EDI/SMS (File-Based)

    Alma exchanges data with local financial systems, student information solutions, and embedded order data (EOD) using files. FTP or secure FTP is used to facilitate this communication over ports 21/22. SMS communication is also file-based via FTP or secure FTP.
    For information on integrating Alma with these systems, refer to the Alma Integration with External Systems Guide.

    OCLC Connexion

    OCLC Connexion (Web or client) interacts with Alma using the TCP-based protocol. Communication occurs via a single port (5500), rather than multiple ports, in order to simplify implementation, while maintaining secure and separate access per institution to the service. This port is open on Ex Libris' side. Ensure that it is open for your institution as well for the workstations which require OCLC Connexion communication with Alma.
    To support communication via port 5500, configuration is required in both Alma and OCLC Connexion (Client/Web). For details, refer to Importing Records from OCLC Connexion.

    Resource Sharing (ILL)

    Communication can be configured between Alma and a resource sharing partner - either peer-to-peer or broker-based. For details, see Resource Sharing Partners.
    Peer-to-peer communication takes place over port 9001. Broker-based communication takes place over port 443.

    Data Providing

    Alma supports several different standard methods of sharing Alma title data with third-parties. Some involve standard online protocols to allow authorized individuals to search their Alma catalog directly (Z39.50 – TCP, OAI-PMH – HTTPS, SRU-SRW – HTTPS, Google scholar and other third-parties from the Discovery services page and Alma delivery – HTTPS).
    Others involve publishing data for use outside of Alma (using Alma’s robust publishing platform) in a file-based manner using FTP or Secure FTP.

    Digital Resources

    Institutions that use digital functionality must have HTTPS access to the Ingest and Delivery URLs specified in the S3 Regions and Buckets section of the following page:

    Alma Authentication

    To ensure data privacy, end-user authentication must be performed via an institutional identity management system (such as Lightweight Directory Access Protocol/LDAP, SAML 2.0, or CAS 2.0). Your external authentication system must be up and running properly before you can begin Alma implementation.
    Alma supports authentication of staff users via the institutional LDAP (Lightweight Directory Access Protocol), using a secure connection. The connection should be secured with a certificate issued by a recognized certificate authority (the list of supported certificates can be found here). To allow LDAP integration, the Alma Data Center IP ranges (mentioned above, according to your location) must be defined. You must also open the port for communication initiated by Alma in the firewall (port 636), as listed in the table below.
    In addition, Alma supports SAML (Security Assertion Markup Language) and CAS, which are XML-based, open standard data formats for exchanging authentication and authorization data between parties via HTTPS—in particular, between an identity provider and a service provider such as Alma. The most important problem that SAML and CAS address is the Web browser single sign-on (SSO) problem. Alma supports the SAML 2.0 Web Browser SSO profile and CAS 2.0 Web Browser SSO profile.
    For more information on authentication, refer to the following pages on the Ex Libris Developers Network:


    Printing from Alma is handled in one of the following ways:
    • Print to a locally defined PC printer, via the Alma Print Queue. For more information, see The Printout Queue and Quick Printing in Alma presentation.
    • Email and corresponding printing rules
      • Each library/institution defines the email addresses of its local printers in Alma, which route staff-oriented, Alma-originating e-mails (including request and transit slips) to the appropriate printer.
      • Newer printers have their own built-in email addresses to support cloud computing. If you are using a new printer, therefore, the email address for notifications should be the printer’s email address.
      • Older printers do not support direct emailing and will therefore require a print proxy. There are several applications available to manage printer routing. For example:
        • MS Outlook printing rules – It is possible to create an email address and link this address to a printer via your MS Outlook printing rules.
        • Automatic Email Manager (AEM) by Namtuk – For details, see
        The above are examples only. Any print proxy that meets your institution's needs can be used.


    Alma sends emails to users, patrons, vendors, and other recipients: acquisition requests, borrower activity status, hold request notifications, overdue reminders, and so forth. In some cases, recipients are expected to send responses to these emails; these responses should be entered manually into Alma (for record keeping; for example, vendor invoices).
    Primo and Summon also send emails: catalog records, search alerts, and so forth. No responses are expected for these emails.
    You can have Alma email directly or use your institution's mail relay server (see Mail Relay Gateways). The default SMTP-Envelope-From address for these emails is what is defined for the From: address in the letter. In Alma, an administrator can configure how Alma sends emails and the From: address using the mail handling integration profile; see Configuring Outgoing Email.
    Note that the SMTP-Envelope-From address is different from the email’s message header From: address, which is used for replies and which can be configured separately for most emails.
    • The SMTP Envelope-From address is used only by the mail server.
    • The email’s message header From: address is used primarily by the email client (such as Outlook or Thunderbird). It may also be looked at by anti-spam filters.
    The customer may want to change these two addresses to be email addresses within the customer’s domain, such as <somename> for one or both of the following reasons:
    • The customer wants all emails sent on their behalf to be branded with their own domain.
    • The customer wants to receive bounce emails (automatic notification of non-delivered emails) directly to a mailbox on their own mail server.
    To change these addresses to be email addresses within the customer’s domain:
    • The customer must change EnvelopeFrom to a valid mailbox in the customer’s domain, for example
    • The customer must change the message header From: addresses in relevant Alma letters to addresses in the same domain used for EnvelopeFrom, for example These addresses do not have to be valid mailboxes.
    The customer must add an SPF Include Entry for the Ex Libris’ mail-relay servers into the SPF record of the customer’s domain (see Mail Relay Gateways).
    Ex Libris supports the DomainKeys Identified Mail (DKIM) standard to help prevent email spoofing for outgoing messages where the “From” address is <some_name>  As of February 2024, DKIM is supported for outgoing messages where the “From” address is set to a customer’s domain. We do offer secure email delivery alternatives – i.e. SPF validation and/or Mail Relaying via customer’s Mail Infrastructure.

    Mail Relay Gateways

    Alma and Primo use dedicated mail-relay servers in each region. Summon does not use such servers.
    You can have Alma email directly or use your institution's mail relay server; see Configuring Outgoing Email.
    Ex Libris supports Transport Layer Security (TLS) 1.2 on the mail-relay servers to deliver mail securely.
    Secure SMTP over TLS allows for encrypted messages; TLS uses Public Key Infrastructure (PKI) to encrypt messages from mail server to mail server.
    The preferred (default) setup of the Alma email servers involves the use of encrypted transactions. If a customer’s email servers support TLS, Ex Libris upgrades the SMTP session to use TLS. If TLS is not supported on the customer’s email servers, Ex Libris establishes the session without TLS.
    Alma email servers support encrypted emails (TLS) signed with a GoDaddy certificate. If a customer’s email servers support TLS, it is recommended that GoDaddy be added as a root certificate authority to the MTA. (Note that when the certificate is not verified, the email is delivered as “untrusted” to the customer.)
    Ex Libris strongly recommends that the customer allows the IP addresses of Ex Libris’ mail-relay servers (see below) as permitted SMTP servers in any anti-spam filters managed by the customer or any email service to which they are subscribed.
    The Ex Libris mail-relay server IPs and hostnames for Alma and Primo are as follows:


    SPF Include Record

    IPs/IP Ranges

    APAC ( - 15) ( - 9)

    Canada ( - 15)

    China ( - 15)

    North America ( - 231) ( - 23)

    Europe ( - 11)

    Only the SPF entry or IP address(s) in the customer’s region need to be included.
    Ex Libris recommends using the SPF include entry listed above, rather than the IPs, since mail-relay IPs may change.
    For allowing mail-relay IPs in mail filters for any European instance of Alma or Primo, both IP addresses must be added.

    Network Communication Diagram and Table

    The following diagram describes the different possible network communications with Alma.
    Alma Communication
    The table below summarizes the complete network communication between the Alma cloud and the customer's network:
    Integration Type Initiator Target Protocol Ports Comments
    Staff workstation Staff workstation Alma HTTPS 443  
    Staff workstation Primo (Back Office) HTTPS 1443 (multi-tenant)
    Staff workstation Summon Admin Console (via Alma) HTTPS 443
    Patron workstation Patron workstation Primo HTTPS 443
    Patron workstation Summon HTTPS 443
    Staff authentication Alma
    CAS (SSO)
    SAML (SSO)
    Social Login
    HTTPS 443  
    Secure LDAP TLS-Secured 636
    Alma-Primo Primo Alma HTTPS 443  
    Primo Central Alma HTTPS 443 Primo central registration with Alma URL
    Alma-Primo end-user authentication Primo CAS (SSO)
    SAML (SSO)
    Social Login
    HTTPS 443  
    Secure LDAP TLS-Secured 636
    Alma-Summon Summon Alma HTTPS 443  
    Alma-Summon end-user authentication Summon (via Alma) CAS (SSO)
    SAML (SSO)
    Social Login
    HTTPS 443  
    Secure LDAP TLS-Secured 636
    Email Alma Email Server SMTP 25 Print via email messages
    S/FTP file-based integrations (outgoing) S/FTP Server
    • ERP/financial
    • Bursar payment fines/fees
    • EDI
    • SMS
    • Publishing platform
    • File-based remote storage
    • Link resolver statistics
    S/FTP 21/22  
    S/FTP Server Publishing platform - Summon S/FTP 2022
    S/FTP file-based integrations (incoming)
    • Student Information Systems (SIS)
    • ERP/financial
    • MD import including EOD
    • EDI
    • Course Loader
    S/FTP Server S/FTP 21/22  
    Ex Libris APIs (for more information, see the Developer Network)
    Client applications
    Alma HTTPS 443  
    Remote storage (for file-based remote storage, see S/FTP file-based integrations - outgoing above) Stunnel workstation (Dematic ASRS remote storage facility system) Alma TLS-secured 6443 Using Stunnel
    Alma Stunnel workstation (Dematic ASRS remote storage facility system) TLS-secured 5001 Using Stunnel
    Self-check Stunnel workstation (SIP2 Self-Check Stations) Alma TLS-secured SIP2 6443 Using Stunnel
    Resource sharing (ILL) system (Alma or non-Alma) Peer to peer resource sharing (ILL) system Alma TCP 9001  
    Alma Peer to peer resource sharing (ILL) system TCP 9001
    Broker resource sharing (ILL) system Alma HTTPS 443
    Alma Broker resource sharing (ILL) system HTTPS 443
    RFID Alma RFID driver installed on a user's PC HTTP Determined by user For more information on port configuration, see the Developer Network.
    OCLC Connexion OCLC Connexion Alma TCP 5500 Accelerated servers are not supported.
    Google Scholar and other third-party electronic service providers Electronic service provider Alma (via Discovery) HTTP or HTTPS 80 or 443 Via Discovery services page directed to Alma’s delivery services
    Z39.50 data providing Z39.50 server Alma TCP 1921 or 210 210 is open on all production environments; sandbox environments support only 210
    OAI-PMH data providing OAI Alma HTTPS 443  
    SRU-SRW data providing SRU-SRW Alma HTTPS 443  
    Aleph Central Catalog for Aleph contribution Alma  Aleph HTTP or HTTPs Institution-specific port definition  
    Aleph Central Catalog for Aleph bibliographic record updates Alma Aleph TCP Institution-specific port definition  
    Aleph Central Catalog for Aleph retrieving bibliographic records (external search) Alma  Aleph TCP Institution-specific port definition  
    Aleph Central Catalog for SBN contribution Alma  SBN HTTP Institution-specific port definition  
    Aleph Central Catalog for SBN retrieving bibliographic/authority records (external search) Alma  SBN HTTP Institution-specific port definition  
    Electronic access proxy (EZProxy, etc.) Alma Proxy HTTPS 443  
    Webhooks Alma  External server HTTPS  443  
    Deposit using SWORD Alma Alma SWORD server HTTPS 443  
    Online payment Alma WPM education system HTTPS 443  
    Primo WPM education system HTTPS 443
    Learning Tools Interoperability (LTI) Course management system Alma HTTPS 443  
    • Was this article helpful?