The week PaperCut goes live, it is a nice reporting tool. A month later it is the path every page in the office travels - and its server quietly became critical. This guide is the small amount of care that server needs: two services, modest hardware, disk discipline, and a backup you have actually tested.
PaperCut's moving parts are few: the Application Server (the brain - accounts, rules, the database, the admin console) and the Print Provider (the watcher on each print server that intercepts and records jobs). Keeping the system healthy means keeping those two running, giving them unremarkable but sufficient hardware, and being able to rebuild the whole thing from a backup on the worst morning of your year.
If the print server stops, printing through it stops - with or without PaperCut, because the queues live there. PaperCut adds one nuance: if the Application Server is unreachable, jobs on managed queues can be held rather than printed uncontrolled, depending on your configuration. Decide in advance which behaviour your office wants for a server outage, and write the decision down: a hospital-style office may want printing to continue and log later; a cost-controlled office may prefer a hard stop. Either is defensible. Discovering the behaviour by accident during the outage is not.
PaperCut itself is light. For a typical small or mid-size office, the existing print server - a reliable always-on Windows machine with a few GB of RAM genuinely free and fast-enough disk - runs it comfortably alongside the queues. What grows is data: the job log accumulates every job, and if you enabled print archiving (MF) the stored job images grow much faster. Watch free disk space on the PaperCut drive as your main health number, and put the server on the same UPS and backup regime as your other infrastructure. Very large sites can move the database to an external SQL server - a scaling step, not a starting requirement.
Once a week, or on the first complaint: open services.msc and confirm the two PaperCut services and the Print Spooler are running; open the admin console and confirm yesterday's jobs are in the log (a silent recording failure shows up as a mysteriously empty day); glance at the printer list for any queue stuck in an error state; check free disk space. Four glances, two minutes. Most PaperCut outages announce themselves in one of these four places days before they become an office-wide stop.
Your PaperCut data - users, balances, accounts, rules, job history - lives in its database and configuration. PaperCut includes a scheduled database backup option; turn it on, and make sure the backup files land somewhere that survives the server itself, inside your normal backup system. Then do the step everyone skips: once, on a spare machine or VM, restore the backup and open the console. A backup that has never been restored is a hope, not a backup. Keep the PaperCut version matching between backup and restore - note the exact version in your server documentation after every upgrade.
Upgrade PaperCut like a server product, not a phone app: read the release notes, back up first, upgrade outside peak printing hours, and afterwards print test jobs to two or three printers and confirm they land in the log with correct charges before declaring done. Keep the print server's Windows updates on your normal patch cycle too - a print server frozen on an old build becomes a security problem that no print rule can fix. If you run secondary print servers or site servers, upgrade them in step with the main server so versions stay in line.
Watch the video once through before your go-live, and keep this checklist near the server for the first month.
▶️ Watch Full VideoTechnically yes for a small office, and many do exactly that. Just understand what you are combining: that machine now carries two critical roles, so its restarts, updates and failures take down files and printing together. It is an acceptable small-office compromise with good backups - it is not a design to grow into a large site.
The log itself is text-scale data - even a busy office's year of job records is modest next to modern disks. The real space consumer is print archiving on MF, which stores an image of printed jobs; enable it only with a retention limit set and disk budgeted for it. For a normal NG install, running out of space is almost always caused by something else on the server, not by PaperCut.
Not if the database backup is current - balances, accounts, rules and history all live in that data and come back with the restore. This is precisely why the scheduled backup and a tested restore matter more than any other maintenance task on this page.