Use this page to plan infrastructure capacity before deploying MyQ X. For exact CPU, RAM, storage, operating system, software, and port requirements, see the current MyQ X Server system requirements.
Do not size production only from a small pilot or initial rollout. Early testing may not expose resource limits that appear later as more users, devices, terminals, and features are added. Many deployments start small and grow as more users, printers, terminals, and features are added, so base your requirements on real and expected workloads:
-
The operating system and Windows services
-
MyQ X server components
-
Database growth
-
Print jobs waiting for release
-
Scan files and scan delivery
-
Logs and diagnostic data
-
Reports and archived reports
-
Job archiving and job preview, if enabled
-
Replication data in Central/Site deployments
-
Other applications running on the same server, if any
Standalone and Central/Site Deployments
In a standalone deployment, one Print Server handles the print, scan, device, user, queue, job, and reporting workload for its environment.
In a Central/Site deployment, Central Server and Site Servers have different roles. Central Server provides centralized licensing, consolidated reporting, user distribution, and selected shared configuration. Site Servers handle local print processing, scanning, printer communication, embedded terminals, and user interaction with devices.
Central/Site deployments usually require more infrastructure planning than standalone deployments. Site Servers still need enough resources for local operations, and Central Server needs enough resources for reporting, user distribution, replication, and coordination across connected sites.
Installing Central Server and a Site Server on the same machine is possible, but should be reserved for small installations and sized accordingly.
Server Sizing Considerations
Recommended system requirements are a baseline, not a guarantee for every environment. Actual resource usage depends on how MyQ is used.
Increase capacity planning when the environment includes:
-
Many printers or embedded terminals
-
High print volume or large print jobs
-
Heavy scan delivery/storage requirements, or OCR workflows
-
Job archiving or job preview
-
Many Desktop Clients
-
Credit, quota, projects, or detailed accounting
-
Heavy API usage or external integrations
-
Large user synchronization sources
-
Central/Site replication and reporting
Do not size MyQ X only for the pilot phase. Use the pilot to validate behavior, but size the infrastructure for the expected production workload, including future users, devices, terminals, print volume, scan volume, reporting, and enabled features.
Signs of insufficient resources can include, for example, jobs not appearing or taking too long to print, slow authentication at devices, outgoing emails getting stuck, and slow loading of the Web Interface, mobile app, or desktop app.
Server Isolation
Install MyQ X on a dedicated server or virtual machine where possible.
Avoid sharing the server with other applications that use databases, web servers, PHP runtimes, mail services, or heavy background processing. Shared services can create resource or service conflicts and make troubleshooting harder. In some cases, conflicts can cause malfunctions in MyQ or in the other application.
Storage Planning
Plan storage before production use. MyQ storage usage can grow quickly depending on print volume, scan volume, job retention, reports, logs, job archiving, and job preview.
When planning storage, consider:
-
Database growth
-
Print jobs waiting for release
-
Scan files and temporary scan data
-
Job archive storage
-
Job preview files
-
Log data and log backups
-
Report data and archived reports
-
Database backups
-
Replication data in Central/Site deployments
Use dedicated storage for MyQ data where appropriate, especially in larger environments. Also consider storage performance, not only available capacity.
Define retention policies before rollout. Decide how long jobs, history, reports, logs, and backups must be kept, and balance those requirements against storage growth and reporting needs. The job and history retention periods you set directly determine how far back reports can reach – once data is deleted, it can only be recovered from a backup that still contains it.
Do not leave debug logging enabled longer than necessary. Debug logs can grow quickly and should normally be used only for troubleshooting.
In Central/Site deployments, monitor replication health. If replication errors accumulate, the Site Server's replication log table can grow rapidly and cause significant database bloat.
Print, Scan, Archive, and Backup Destinations
In larger environments, do not assume that the operating system or application disk is the right place for all MyQ data. Plan which data should remain local and which should use dedicated or external storage.
For larger or fast-growing deployments, decide which data needs dedicated or external storage, such as MyQ data folders, job files, reports, databases, database backups, log backups, scan destinations, and archived jobs.
If users scan to network folders, FTP, cloud storage, or email, include those destinations in storage, network, and availability planning.
If Job Archiving or Job Preview is used, plan the storage impact carefully. These features can significantly increase disk usage. Define destination locations, retention limits, and any applicable size restrictions as part of the initial deployment design.
Network and Firewall Planning
Depending on the selected deployment model and enabled features, MyQ X may require communication between servers, printers, embedded terminals, user workstations, mobile devices, identity providers, mail servers, cloud services, licensing services, and optional supporting components.
Plan network access according to the selected deployment model and enabled features. Pay particular attention to communication between sites, terminal vendor requirements, print and scan traffic, identity providers, mail systems, cloud integrations, and mobile printing.
For exact ports and protocols, use the current MyQ X Server communication ports documentation.
Virtualization
MyQ X can run on virtual servers. When using virtualization, allocate resources according to the current MyQ X Server system requirements and expected workload.
For production deployments, avoid resource contention on the virtualization host, especially for CPU, memory, and storage performance. Monitor the virtual machine during peak usage and adjust resources if print, scan, authentication, reporting, or client operations become slow.