Deployment

Planning Your Deployment

Use this page to identify the main planning decisions for a MyQ deployment before you start installing or configuring the system.

During planning, evaluate the deployment model, expected capacity, network architecture, availability requirements, upgrade strategy, and long-term growth of the environment. These decisions affect server placement, infrastructure sizing, user authentication, print delivery, fallback options, and maintenance effort.


Before You Start

Consider these questions:

  • Do you want to deploy MyQ on-premises, in a private or hybrid cloud, or use a public cloud print management solution?

  • Do you need one standalone print server, or multiple servers across different locations?

  • What is the expected size of the installation, and how quickly might it grow?

  • How reliable is the network in each location where MyQ will be used?

  • How often can you upgrade servers, embedded terminals, desktop clients, and other connected components?

  • What fallback, failover, backup, and incident response measures do you need?

On-Premises vs Cloud

The right deployment model depends on your infrastructure, security requirements, administration model, and expected maintenance effort.

MyQ X is designed for on-premises and private or hybrid cloud environments. It can be deployed as a standalone Print Server, or as a multi-site environment with one Central Server and several connected Print Servers.

Tip!

For cloud-native environments, consider MyQ Roger. This public cloud print management solution designed for organizations that prefer a SaaS model, reduced infrastructure maintenance, and support for mobile, remote, and hybrid work.

MyQ X in Private Cloud

MyQ X servers can be deployed in a private or hybrid cloud environment, for example on an Azure virtual machine connected to your network.

Common deployment models include:

  • A Central Server running in the cloud with on-premises Print Servers connected to it.

  • Central Server and Print Servers running in a private cloud.

  • Print Servers running close to local printer fleets, with a Central Server used for centralized management and reporting.

MyQ X Releases

MyQ X releases major and minor versions to deliver larger product changes, and patch versions to provide maintenance, security, compatibility, and stability updates.

For access to the latest features, improvements, security updates, and fixes, use the latest supported version and apply patches regularly. For many production environments, the latest Long-Term Support (LTS) version provides a more practical balance between stability, support lifecycle, and upgrade effort.

Before choosing or upgrading to a target version, review the release notes, product end-of-life policy, system requirements, and upgrade instructions for the relevant MyQ server and components. Also consider compatibility with embedded terminals, desktop clients, mobile clients, and other connected components when planning an upgrade.

Product versions are published on the MyQ Community Portal in the Downloads section.

Before Installation

After completing the deployment planning, confirm the following decisions before running the MyQ installers.

Central Server Database

Print Server, whether standalone or site, uses an integrated Firebird database. No database backend decision is required.

Central Server uses the integrated Firebird database by default, but can also use an external Microsoft SQL Server database. Decide the Central Server database approach before installation, especially if you plan to use Microsoft SQL Server or deselect the integrated Firebird database during installation.

Use the integrated Firebird database unless your organization already uses Microsoft SQL Server for similar workloads, or has database management, backup, monitoring, or availability requirements that are better handled in SQL Server.

Installation Order in Multi-Site Environments

The Print Server and Central Server installers can be run in any order. However, starting with the Central Server is the recommended practice. User synchronization runs on the Central Server first, and site servers pull user data from it – synchronizing to a site before the Central Server has users will leave the site empty until the next sync cycle.

If you are adding new Site Servers to an existing Central Server, upgrade the Central Server to the target compatible version before installing the new sites. This allows new sites to be installed at the target version immediately, rather than requiring a second upgrade pass.

Version Compatibility

The Central Server version must be equal to or higher than the version of any connected Site Server. Always use the latest released patch of the version you are deploying. Before rollout, verify the exact supported version combinations in the current release notes and upgrade documentation.

Valid combinations:

Central Server

Site Server

10.3

10.3

10.3

10.2

10.2

10.2

A site server at a higher version than the Central Server is not supported.