🖥️ Deployment Scenario

Self-Hosted CMMS: Complete Data Sovereignty for Australian Organisations

How Australian organisations deploy inFM on their own infrastructure — eliminating cloud dependency, achieving full data sovereignty, and breaking free from per-user SaaS pricing.

🇦🇺 Australian Owned & Made — inFM is 100% Australian built and can be deployed entirely within your infrastructure. ABN: 49 698 165 635

Why Australian Organisations Choose Self-Hosted CMMS

The dominant model in enterprise software is cloud SaaS — subscription-based, per-user pricing, data hosted in a vendor's data centre. For many organisations, this is convenient and appropriate. But for a significant segment of Australian industry, cloud hosting creates problems that simply cannot be accepted.

Data Sovereignty Requirements

Australian Privacy Principles require that personal information about Australian individuals be stored and processed in ways that meet Australian privacy law. For industries like healthcare, government, defence, and corrections, the data residency requirements are explicit: operational data must remain on Australian soil, within organisational networks, and under organisational control.

Cloud CMMS platforms frequently host data in US or European data centres. Even where vendors claim to offer Australian data residency, the contractual arrangements, sub-processors, and disaster recovery configurations may not satisfy stringent organisational data governance requirements. An on-premises deployment removes all ambiguity: the data is on your server, in your building, on your network, under your complete control.

Regulatory and Industry Compliance

Various Australian regulatory frameworks impose constraints on information systems used by regulated organisations. Healthcare organisations must comply with the Privacy Act, health records legislation, and data handling requirements aligned with clinical governance frameworks. Government agencies operate under the Protective Security Policy Framework. Defence organisations must comply with ASD ISM controls. In each case, a self-hosted CMMS that operates entirely within the organisation's existing compliant infrastructure is the lowest-risk choice.

Remote and Restricted Connectivity

A significant proportion of Australian industrial operations occur in locations where reliable internet connectivity cannot be assumed: remote mining and resources operations on satellite links, offshore facilities, rural agricultural operations, and areas affected by natural disasters. A cloud-based CMMS that requires continuous internet connectivity is simply not viable in these environments. A local server provides reliable, low-latency access for all users on the site's internal network — regardless of whether the satellite link is up.

Budget Predictability

SaaS CMMS pricing typically scales with user counts. For large organisations with hundreds of tradespeople, FM staff, and contractors who need system access, per-user SaaS fees can become very significant annually. A self-hosted deployment involves an upfront licensing cost and ongoing server infrastructure costs, but eliminates the variable cost component that scales with headcount. For many Australian organisations, this represents a substantially lower total cost of ownership over a 3–5 year horizon.

How to Deploy inFM On-Premises

inFM supports multiple deployment methods to suit your existing infrastructure and IT team capabilities.

🐳

Docker (Recommended)

The quickest and most portable deployment method. Install Docker on any Linux or Windows Server host, run the inFM deployment script, and the application is running within minutes. Docker containers bundle the Node.js API, React frontend build, and manage the MySQL database connection. Easy to update, backup, and migrate. Recommended for new deployments and organisations with existing Docker infrastructure.

🪟

IIS / Windows Server

For organisations with established Windows Server infrastructure, inFM can be deployed via IIS (Internet Information Services). The Node.js API runs as a Windows Service, the built React frontend is served as static files, and MySQL 8.0 runs as a Windows database service. This deployment model integrates with existing Windows Server management, monitoring, and backup processes — and fits naturally into organisations with Windows-centric IT environments.

🐧

CentOS / Nginx

For Linux-based server environments, inFM deploys on CentOS (or compatible distributions) with Nginx as the reverse proxy. The Node.js API runs as a systemd service, Nginx handles SSL termination and static file serving, and MySQL 8.0 provides the database backend. This configuration provides a hardened, production-grade deployment suitable for organisations with Linux expertise and existing CentOS infrastructure.

Full CMMS Capability, On Your Infrastructure

A self-hosted inFM deployment provides all features of the platform — with no limitations based on deployment model.

  • Complete asset register with hierarchical building / site structure
  • Work order management — create, assign, track, and close jobs
  • Preventative maintenance scheduling with automatic work order generation
  • Time tracking for tradespeople and contractors
  • Email notification system (via your internal SMTP relay)
  • Role-based access control — multiple user roles with field-level permissions
  • Multi-domain / multi-site support from a single deployment
  • Full audit trail of all user actions
  • Reporting and analytics dashboards
  • Asset maintenance history — complete records for every asset
  • Mobile-responsive interface — works on any device via browser
  • No per-user licensing — deploy for your entire team
  • Zero external dependencies in production
  • MySQL 8.0 database — standard, well-supported, backup-friendly

Self-Hosted CMMS: Common Questions

What server hardware do I need to run inFM?
inFM is a lightweight application that runs comfortably on modest hardware. A minimum specification server would be: 4 CPU cores, 8 GB RAM, 50 GB storage (SSD recommended). For larger organisations with hundreds of concurrent users and extensive asset histories, a more capable server is recommended: 8+ CPU cores, 16+ GB RAM, 200+ GB SSD storage. The application can also be deployed on a virtual machine within an existing VM infrastructure. Detailed minimum and recommended specifications are available in the inFM deployment documentation.
How is inFM updated when deployed on-premises?
inFM updates are distributed as new deployment packages. For Docker deployments, a new image can be pulled and deployed with a single command. For IIS or CentOS deployments, an update package is applied through a documented process. Updates do not require internet connectivity to apply — packages can be downloaded on an internet-connected system and transferred to the air-gapped server via approved media. Schema changes are automatically applied when the updated application first starts — there is no separate database migration step required.
Can inFM be deployed with an SSL certificate?
Yes. SSL/TLS encryption is strongly recommended for all deployments and is fully supported. For internet-accessible deployments, Let's Encrypt certificates can be used (via Nginx or IIS ACME integration). For internal deployments on private networks without internet access, your organisation's internal CA certificate can be used — Nginx and IIS both support configuring custom SSL certificates. The inFM deployment documentation covers SSL configuration for each deployment method.
How is database backup handled?
inFM uses a standard MySQL 8.0 database. Backup is performed using standard MySQL tools (mysqldump, MySQL Enterprise Backup, or any MySQL-compatible backup solution). Your existing database backup processes and policies can be applied directly to the inFM database. For Docker deployments, the database volume can be backed up using standard Docker volume backup procedures. The inFM deployment documentation provides example backup scripts and recommendations for backup frequency based on operational requirements.
Can I migrate from a cloud CMMS to a self-hosted inFM?
Yes, migration from an existing CMMS to inFM is possible, though the process depends on what data your current system can export. Most CMMS platforms can export asset lists, work order histories, and user data in CSV or spreadsheet format. The inFM team can assist with data migration planning and importing existing data. Asset records, historical work orders, and PM schedules can be imported to provide continuity of maintenance histories. Contact sales@infm.au to discuss your specific migration requirements.

Ready to deploy inFM on your own infrastructure?

Talk to the inFM team about your self-hosted deployment requirements. We can provide deployment packages, documentation, and setup support.

Contact inFM PM Scheduling Use Case