FloorPulse is on-premises software. No data leaves your building. This page documents the network requirements, firewall rules, and security model so IT can review and approve before installation.
FloorPulse installs as a native Windows Service on a single machine inside your network, with PostgreSQL 17 bundled in. No cloud services, no external databases, no SaaS dependencies. The only outbound connections are optional update checks and license renewal — both read-only HTTPS GETs to static files.
FloorPulse installs from a single signed Windows installer (EXE) that registers it as a Windows Service. It starts on boot and survives reboot and logoff with no user logged in, and requires no virtualization or special host configuration.
PostgreSQL 17 is bundled and installed alongside the application; its data lives at a known, ACL-restricted path on the host disk. Updating the application does not affect the data. Schema changes ship inside the application code and apply automatically at startup — they are additive (new tables and columns are added in place), so older installations upgrade cleanly with no data loss and no manual DBA steps. Major PostgreSQL version upgrades are handled by the installer with an automatic pre-upgrade backup, validation, and rollback on failure, and have been tested successfully on production-scale data.
FloorPulse includes its own bundled PostgreSQL 17 instance, installed and managed by the FloorPulse installer. This is an application database — it functions as an internal component of the software, not a shared enterprise resource. It's comparable to the embedded database in a printer controller, a phone system, or a building access panel. It requires no DBA oversight, no backup coordination with other systems, and no shared infrastructure.
Why it must stay embedded:
pg_dump backup restored on a separate machine — never experiment on the live production database.pg_dump command. Recovery is a restore + restart. No coordination with a DBA team or shared maintenance window required.For IT's peace of mind: the database data directory lives at a known, ACL-restricted path on the host filesystem and can be included in your existing host-level backup routines (snapshots, rsync, or any agent you already run). Your monitoring tools can watch the FloorPulse Windows Service status just like any other service. FloorPulse's built-in health dashboard already tracks database connection pool utilization, disk usage, and memory — visible from any browser on the LAN.
FloorPulse requires zero inbound connections from the internet. All external communication is outbound HTTPS to known, static endpoints. The table below is the complete set of network requirements.
| Destination | Port | Protocol | Purpose | Required |
|---|---|---|---|---|
floorpulse.net |
443 | HTTPS | Update check — off by default; opt-in. Only if a supervisor enables update checking in Config does FloorPulse read a static JSON file once daily for available updates (read-only GET, no data sent). Left off, the server makes zero outbound attempts and we notify you of new releases by email. | Optional |
floorpulse.net |
443 | HTTPS | Installer download — downloads the signed FloorPulse update installer (EXE) when IT chooses to update. Only used during manual updates. | Optional |
api.github.com |
443 | HTTPS | License auto-renewal — off by default; opt-in. Only active if you configure a GitHub token in Config; then FloorPulse reads a renewed license-key file (read-only GET). If you don't opt in, renewed license keys are emailed to you and pasted in manually. | Optional |
All three outbound rules are optional. FloorPulse operates fully offline. Without internet access: updates are applied via USB (download the signed installer on any connected machine, transfer to server), licenses are pasted into the configuration UI, and update notifications are not shown.
| Source | Port | Protocol | Purpose | Required |
|---|---|---|---|---|
| LAN browsers (workstations, tablets, phones, supervisors) | 5000 | HTTP | Web UI access — all FloorPulse pages | Required |
| LAN browsers (devices using camera scanning) | 5001 | HTTPS | Camera barcode scanning requires HTTPS (browser security policy). Not needed if using Bluetooth/USB scanners only. | Optional |
| Destination | Port | Protocol | Purpose | Required |
|---|---|---|---|---|
| Thermal printers (Zebra, Microcom) | 9100 | Raw TCP | Tray tag and label printing — direct socket connection to printer | Required |
| Laser printers | 631 | IPP | Pallet placard printing via driverless IPP (FloorPulse is its own IPP client) | Optional |
| Service | Port | Protocol | Purpose | Scope |
|---|---|---|---|---|
| PostgreSQL | 5432 (default) | TCP | Database — bundled PostgreSQL 17, bound to localhost; only the FloorPulse application connects. Not exposed to the network. | Localhost |
If the optional Conveyor Routing add-on is deployed, it runs as a second on-premises service that serves its browser UI on 5010 (HTTP) and 5011 (HTTPS), plus a controls socket API on TCP 10100 that palletizers, robots, and end-of-line controllers connect to for routing decisions. All three are LAN-only — no inbound internet, no additional outbound traffic, the same on-premises security boundary as the core platform.
floorpulse.net. The signature can be verified before installing. Updates are never applied automatically — IT controls when updates are installed, and the installer takes an automatic pre-upgrade backup with rollback on failure.Update checking is opt-in and off by default — out of the box the server makes zero outbound connections. A supervisor can enable it in Config, after which FloorPulse fetches a static JSON file from floorpulse.net (a read-only HTTP GET — no data sent, no credentials, no cookies; the response contains only the latest version number and a summary of changes). If you leave update checking off, we notify you of new releases and deliver renewed license keys by email, and you apply them manually.
Updates are never automatic. FloorPulse will never update itself without explicit action from your IT team. The notification banner is informational only — it tells the supervisor an update exists. The actual update requires someone with terminal access to the server to run the pull command.
Security patches are flagged with a red banner that cannot be dismissed. This ensures visibility without taking any automatic action. The banner persists until the update is applied or a newer version supersedes it.
| Component | Minimum | Recommended | Notes |
|---|---|---|---|
| CPU | 2 cores | 4 cores (i5 or equivalent) | Most operations are I/O-bound (database, network) |
| RAM | 8 GB | 16 GB | PostgreSQL benefits from available memory for caching |
| Disk | 20 GB SSD | 50+ GB SSD | Database size depends on mail volume. SSD strongly recommended. |
| OS | Windows 10/11 or Windows Server 2019+ (primary) | A sealed Ubuntu 22.04+ Linux appliance is also available | |
| Software | None — the signed installer bundles everything | No separate .NET runtime, no separate PostgreSQL, no Java to install. | |
| Network | Ethernet connection on the production floor LAN | Wi-Fi is acceptable for the server but wired is recommended | |
We see no reason FloorPulse can't run on a properly configured VM (Hyper-V, VMware, Proxmox) — and a VM brings useful options, such as the replication-based disaster recovery described below.
One firm exception when you're driving automation. If you use the Routing module to control palletizers, robots, or end-of-line equipment, the fast socket protocol expects sub-20 ms round trips. That host — physical or virtual — should sit on a network segment isolated from general office, file, and backup traffic, with no contention on its NIC. Don't run the automation host on a busy shared VLAN, an oversubscribed hypervisor, or a Wi-Fi link. If you're supporting automation, spec the hardware and network for it — be smart, not cheap.
This section pre-answers the standard vendor security questionnaire (SIG/CAIQ/VSA). If your organization sends an annual security assessment, the answers below cover the typical questions. FloorPulse is on-premises software — many cloud/SaaS questions resolve to "customer-controlled."
Last updated: June 2026. Contact contact@floorpulse.net if your questionnaire includes questions not covered here.
| Legal entity name | FloorPulseNet LLC |
| Product name | FloorPulse |
| Product description | On-premises production floor management software for Mail Service Providers. Barcode-driven tray tagging, pallet placard generation, and real-time job visibility. |
| Deployment model | On-premises only. Native Windows Service on customer-owned hardware (sealed Linux appliance optional). No cloud, no SaaS, no hosted option. |
| What data does the product process? | mail.dat files (USPS DTAC/IDEAlliance standard): job metadata, container/tray definitions, piece-level barcodes (Intelligent Mail barcodes). May include recipient ZIP codes and delivery route codes. All data stays on the customer's local server. |
| Does the vendor have access to customer data? | No. The vendor has no remote access, no API access, and no network path to customer installations. Support access requires the customer to explicitly grant it (e.g., TeamViewer, VPN). |
| Number of employees with access to customer data | Zero. See above. |
| Where is customer data stored? | On the customer's server, in a bundled PostgreSQL 17 database. Data is stored in an ACL-restricted data directory on the local filesystem. No data is stored off-premises. |
| Is data encrypted at rest? | The application does not implement its own disk encryption. Encryption at rest is the responsibility of the host operating system (BitLocker, LUKS, FileVault, etc.). The customer controls this. |
| Is data encrypted in transit? | HTTPS (TLS 1.2+) is supported for browser connections. Internal database communication is localhost-only (no network transit). Printer communication uses raw TCP (ZPL/LDS protocols — industry standard, no TLS variant exists). |
| Is data transmitted to third parties? | No. Production data never leaves the server. No third-party analytics, no subprocessors, no data sharing. |
| Is data transmitted to the vendor? | No. The only outbound connections are optional HTTPS GETs to check for software updates and license renewal. These requests contain no customer data — they read a static JSON file. |
| What PII is processed? | Piece-level records contain Intelligent Mail barcodes encoding delivery point ZIP+4 codes and routing information. No names, addresses, email addresses, phone numbers, SSNs, or financial data are imported. The mail.dat specification includes a CDR (Certificate of Mailing Detail Record) file type that can contain recipient names and addresses — FloorPulse explicitly does not import this file type. Only the seven file types required for production operations are consumed. |
| Data retention policy | Configurable by the customer. Piece-level barcode data can be auto-purged after a configurable number of days (default: 60). Job records can be retained indefinitely or purged on schedule. The customer controls retention through the Configuration UI. |
| Data deletion / right to erasure | The customer has full database access (admin and read-only users) and can delete any data at any time. A "Database Reset" function is available in the Configuration UI. The vendor has no data to delete because the vendor holds no customer data. |
| Data backup | Customer-managed. Standard PostgreSQL backup tools apply: pg_dump from the bundled database. The vendor does not perform or manage backups. |
| Does the product require inbound internet access? | No. No inbound connections from outside the customer's network are required or accepted. |
| Does the product require outbound internet access? | Optional and off by default. Only if enabled in Config are outbound HTTPS endpoints used — update checks + installer downloads (floorpulse.net) and license renewal (api.github.com), all read-only GETs. Left at their defaults the product makes no outbound connections and functions fully without internet; we deliver update notices and renewed license keys by email. |
| What ports does the product use? | Inbound: 5000 (HTTP), 5001 (HTTPS) — LAN only. Outbound LAN: 9100 (thermal printers, raw TCP), 631 (laser printers, IPP). Internal: 5432 (PostgreSQL, localhost only). The optional Conveyor Routing module adds its browser UI on 5010 (HTTP) / 5011 (HTTPS) and a controls socket (TCP 10100) — all LAN-only. See Firewall Rules section for complete details. |
| Does the product open a listening port accessible from the internet? | No. The application listens on LAN interfaces only. Exposing it to the internet is not supported and not recommended. |
| Does the product use a VPN or tunnel? | No. |
| Does the product use WebSockets? | Yes. SignalR (WebSocket) is used for real-time updates between the server and browser clients on the LAN. This is internal traffic only. |
| TLS version | TLS 1.2 and 1.3, determined by the .NET runtime and host OS configuration. |
| Authentication method | Cookie-based session authentication with PBKDF2-SHA256 password hashing (100,000 iterations, 128-bit salt). Single admin password shared by supervisors. Operators do not require authentication. |
| Does the product support SSO/SAML/OIDC? | Not currently. Single shared admin password. SSO integration is on the product roadmap for enterprise deployments. |
| Does the product support MFA? | Not currently. Physical LAN access is the primary security boundary. MFA is on the roadmap. |
| Does the product support RBAC? | Two-tier model: Admin (configuration, job management, database operations) and Operator (scan, print, view — no authentication required). Role-based access control with additional roles is on the roadmap. |
| Session management | HTTP-only cookies, SameSite=Lax, 8-hour sliding expiration. Sessions are not stored server-side — they are stateless signed cookies. |
| Cookies and local storage | FloorPulse uses cookies and browser local storage for operational continuity on production floor devices. Workstation tablets store their workstation identity, assigned printer, sort direction, and active job — so an operator can power-cycle a tablet or refresh the browser and resume scanning immediately without reconfiguring. Supervisor stations store dashboard layout preferences. Blocking cookies or clearing local storage on these devices will force manual reconfiguration after every browser restart. These are first-party cookies from the FloorPulse server on the LAN — no third-party cookies, no tracking cookies, no advertising. Group Policy or MDM rules that clear browser data on close should exclude the FloorPulse server URL. |
| Password policy | No minimum complexity requirements enforced by the application. The admin password is set by the facility supervisor. Password is hashed with PBKDF2-SHA256 and never stored in plaintext. |
| Default credentials | None. The application ships with no admin password set. The first user to set a password becomes the admin. A warning banner prompts password setup on first use. |
| Emergency access / password recovery | Two recovery paths, matched to access level. Recovery code: a one-time code is generated when the admin password is first set; a supervisor can use it from any LAN browser to reset the password (rate-limited, single-use, rotated on use). Filesystem trigger: if the recovery code is also lost, an administrator with OS-level access drops a reset-password.txt file into a permission-protected admin directory (ACL-restricted to SYSTEM + Administrators on Windows); FloorPulse consumes it, resets the password, and writes back a freshly rotated recovery code. No vendor involvement, no cloud — works fully air-gapped. |
| How are security vulnerabilities identified? | Automated CI/CD pipeline on every code push and weekly schedule: NuGet vulnerability scan (dotnet list package --vulnerable), filesystem/dependency scan (Trivy — fails on CRITICAL/HIGH), static analysis (GitHub CodeQL for C# and JavaScript — detects SQL injection, XSS, path traversal). Dependabot monitors NuGet packages and GitHub Actions for updates and creates PRs automatically. Manual code reviews supplement automated tooling. The frontend uses zero JavaScript frameworks (no React, Angular, Vue) — plain HTML/CSS/JS minimizes the attack surface. |
| Security development lifecycle | Monthly: automated dependency scans, GitHub Security tab review. Quarterly: manual endpoint-by-endpoint code review (auth, SQL, XSS, path traversal), vendored library version audit, credential scan, security header verification. Annually: threat model review, manual penetration test, security page accuracy check, patch SLA validation. Full audit process documented in project repository. |
| How are security patches delivered? | As signed installer (EXE) updates. If a supervisor opts in to update checking (off by default), the application checks floorpulse.net/updates/latest.json daily and displays an in-app notification when an update is available; if not, we notify you by email. Security patches are flagged with a non-dismissable red banner. Updates are never automatic — IT must run the installer. See Software Updates. |
| Patch SLA | Critical security vulnerabilities: patch issued within 48 hours of identification. High severity: within 7 days. Medium/Low: included in the next scheduled release. |
| Has the product undergone a penetration test? | Yes. OWASP ZAP full scan (134 automated checks) — all passed. Covers SQL injection (including PostgreSQL time-based), XSS (reflected, stored, DOM-based), path traversal, CSRF, SSRF, remote code execution, Log4Shell, Spring4Shell, NoSQL injection, cookie security, header validation, source code disclosure, and more. ZAP scans are included in the annual audit process. Manual penetration testing supplements the automated scan. |
| Bug bounty program | Not currently. Security issues can be reported to contact@floorpulse.net. |
| OWASP Top 10 coverage | The application is developed with OWASP Top 10 awareness. Input validation at system boundaries, parameterized SQL (no string concatenation), HTML output escaping, CSRF protection via SameSite cookies, no deserialization of untrusted data. Login rate limiting (5 attempts/minute) prevents credential brute-force. Security headers (CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy) are set on all responses. |
| AI/LLM security posture | FloorPulse currently includes no AI or LLM features. A documented AI Integration Checklist is maintained in the project repository for review before any future LLM integration. The checklist addresses: prompt injection via user-controlled database fields (mail.dat free-text fields, configuration values, device names), structured output validation, and prohibition of executing LLM-generated commands or SQL. |
| Cloud provider | None. FloorPulse is on-premises software. No cloud infrastructure is used for the product. (The vendor's website is hosted on Netlify — this is unrelated to the product.) |
| Data center / hosting location | The customer's facility. The customer chooses and controls the hardware. |
| Multi-tenancy | Not applicable. Each installation is a single-tenant deployment on customer-owned hardware. |
| Database architecture | PostgreSQL 17 runs as a bundled application database, version-locked to the application. It is not a shared enterprise database — it functions as an internal component (comparable to the embedded database in a phone system or access control panel). It listens only on localhost, is not exposed to the network, requires no DBA management, and is updated alongside the application. See Architecture Overview for details. |
| Can the database be hosted externally? | Not supported. The application and database are version-locked — each application update includes schema migrations that expect a specific database state. Separating them introduces version drift risk and a larger attack surface. The embedded model is the intentional security and reliability architecture. |
| Service & process hardening | FloorPulse runs as a Windows Service under a dedicated service account. Program files install under C:\Program Files\FloorPulse\; the data directory and logs are ACL-restricted to SYSTEM + Administrators. The bundled PostgreSQL listens only on localhost. |
| Host OS hardening | Customer-managed. FloorPulse requires only a supported Windows version. Host OS patching and hardening are the customer's responsibility. |
| Logging and monitoring | Application logs are written to an ACL-restricted log directory on the host. The built-in health dashboard monitors CPU, memory, disk, database connections, and performance anomalies. Alerts are displayed in the web UI and pushed via WebSocket. Integration with external SIEM/log aggregators is possible by reading the log directory. |
| Uptime SLA | Not applicable. The software runs on customer hardware. Uptime depends on the customer's infrastructure. The application is designed to start automatically after power restoration (the Windows Service is set to start automatically on boot). |
FloorPulse's database contains production state — which trays have been tagged, which pallets are complete, job progress. This data is useful but not irreplaceable. The source of truth is the mail.dat files from your presort software, which you already have. A fresh FloorPulse installation can reimport those files and be production-ready in minutes. This fundamentally changes the DR equation: you're not protecting a database, you're protecting uptime.
Three tiers of protection — choose the one that fits your operation:
| Tier | Method | Recovery Time | Data Loss | Best For |
|---|---|---|---|---|
| 1. Reinstall + Reimport | Run the FloorPulse installer on a spare Windows machine, paste the license key, reimport today's mail.dat files from presort output | ~15 minutes | Production history (which trays were printed, timestamps). Current jobs are rebuilt from mail.dat files. | Single-shift shops, small operations, any shop that wants the simplest possible DR plan |
| 2. VM Replication | Run FloorPulse in a VM (Hyper-V, VMware, Proxmox). Mirror or snapshot the VM to a standby host using your existing replication tools. If the primary fails, start the replica. | 1–5 minutes | None (or minutes, depending on replication interval) | Shops that already manage VMs — uses tools and processes IT already has. No new concepts, no new software. |
| 3. Database Backup | Scheduled pg_dump from the bundled database, or file-level snapshots of the data directory. Restore to any machine running FloorPulse. |
5–15 minutes | Since last backup | Shops that want historical production data preserved (scan logs, tray event history, performance stats) |
| RPO (Recovery Point Objective) | Tier 1: current day's jobs (reimported from presort files). Tier 2: depends on VM replication interval (typically minutes). Tier 3: depends on backup schedule. |
| RTO (Recovery Time Objective) | Tier 1: ~15 minutes. Tier 2: 1–5 minutes (VM failover). Tier 3: 5–15 minutes (restore + restart). |
| Does the product have a single point of failure? | In the standard deployment (Tier 1), yes — one server. If it fails, Tier 1 recovery takes ~15 minutes on any available machine. Tier 2 (VM replication) eliminates the single point of failure entirely using your existing virtualization infrastructure. |
| What happens if the vendor goes out of business? | The software continues to operate indefinitely on existing installations. Perpetual license keys are available and will be issued to all active customers if the company ceases operations. All customer installations auto-check for license renewals weekly — perpetual keys are delivered automatically via this mechanism. Source code is available to customers under a separate agreement. |
| Vendor lock-in / data portability | All data is stored in standard PostgreSQL tables with a documented schema. Customers have full SQL access via a pre-configured read-only database user. Data can be exported at any time using standard PostgreSQL tools. The application uses no proprietary data formats. Note: for reporting and analysis, restore a pg_dump backup on a separate machine rather than running ad-hoc queries against the live production database — an expensive query can consume host resources and impact production floor operations. |
| Subprocessors | None. No customer data is shared with or processed by any third party. |
| Third-party libraries | Server: .NET 10 runtime (Microsoft, MIT), Npgsql (PostgreSQL driver, PostgreSQL License), QuestPDF (PDF generation, MIT), SkiaSharp (graphics, MIT), ZXing.NET (barcode scanning, Apache 2.0), SharpIpp (driverless IPP printing client, MIT). Frontend: JsBarcode and bwip-js (barcode rendering, MIT), SignalR client (Microsoft, MIT). All dependencies ship inside the signed installer — no runtime downloads. |
| Open-source license compliance | All dependencies use permissive licenses (MIT, Apache 2.0, PostgreSQL License). No copyleft (GPL) dependencies. Full dependency list available on request. |
| Supply chain security | Dependencies are restored from NuGet.org during build and compiled into the application. The release installer is code-signed (Authenticode); its signature can be verified before installation. |
| Does the vendor have an incident response plan? | Yes. Security incidents affecting the product (e.g., a vulnerability in a dependency) are handled with: identification, patch development, patch release via a signed installer update, and notification via the in-app update system and direct email to affected customers. |
| Breach notification timeline | Since the vendor holds no customer data, a data breach at the vendor does not expose customer data. If a vulnerability in the product is discovered that could allow unauthorized access, customers are notified within 24 hours via email and the in-app update system. |
| Security contact | contact@floorpulse.net |
| Data center physical security | Not applicable. The product runs on customer-owned hardware in the customer's facility. Physical security is the customer's responsibility. |
| Vendor office security | The vendor's development environment uses full-disk encryption and does not contain customer production data. Source code is stored in a private GitHub repository with 2FA-protected access. |
| Background checks | FloorPulseNet LLC is a small company. Background checks are conducted for employees with access to source code or customer-facing systems. |
| Security training | All developers follow secure coding practices (OWASP guidelines, parameterized queries, input validation). Code is reviewed before merge. |
| Access to customer environments | Zero employees have standing access to any customer environment. Support access is granted on a per-incident basis by the customer and revoked afterward. |
| How are changes to the product managed? | Version-controlled source code (Git). All changes are committed with descriptions. Releases are tagged with semantic versioning (MAJOR.MINOR.PATCH). |
| How are changes deployed to customers? | As signed installer (EXE) updates. Customers control when updates are applied. No changes are pushed automatically. See Software Updates. |
| Can the customer decline or delay an update? | Yes, indefinitely. Updates are never forced. The only consequence of not updating is that the in-app notification banner persists (and cannot be dismissed for security updates). |
| Rollback capability | Yes. The installer takes an automatic pre-upgrade database backup and rolls back automatically if the update fails validation. A prior version can also be reinstalled from its signed EXE. |
| SOC 2 certification | Not applicable. FloorPulse is on-premises software — it does not operate a service that processes customer data. SOC 2 applies to service organizations. FloorPulse is comparable to a locally-installed print server or database application. |
| ISO 27001 | Not currently certified. Planned for evaluation as the customer base grows. |
| HIPAA | FloorPulse does not process protected health information (PHI). Not applicable to mailing operations. |
| PCI DSS | FloorPulse does not process, store, or transmit payment card data. Not applicable. |
| GDPR | FloorPulse processes no EU personal data in its standard use case (USPS domestic mail). If a customer processes international mail containing EU recipient data, the customer is the data controller and FloorPulse is a processor. A Data Processing Agreement (DPA) is available on request. |
| CCPA | Similar to GDPR: FloorPulse is a tool used by the customer. The customer determines what data is imported and how long it is retained. FloorPulse does not sell, share, or transmit personal information to any third party. |
| USPS compliance | FloorPulse generates tray tags and pallet placards in compliance with USPS Domestic Mail Manual (DMM) specifications: tray tags per USPS-L-3216A, pallet placards per DMM 204 Exhibit 3.4.3. Barcode formats: IMb (Intelligent Mail barcode) for tray tags, IMcb (Intelligent Mail Container Barcode) for pallet placards. |
| Does the product phone home? | No — not by default. Update checking is opt-in and off until a supervisor enables it in Config; until then the product makes zero outbound connections. If enabled, it performs a daily read-only HTTPS GET of a static version file (no customer data, no telemetry, no usage statistics). Leave it off and we notify you of updates by email instead. |
| Does the product install agents on other machines? | No. Workstations access FloorPulse through a standard web browser. Nothing is installed on operator devices. |
| Does the product modify the host OS? | It installs as a Windows Service and bundles PostgreSQL 17 under its own program and data directories. It does not alter unrelated system settings or write outside its own install and data locations. |
| Can the product be air-gapped? | Yes. FloorPulse operates fully without internet access. Updates can be applied via USB. Licenses can be pasted manually. No degradation in functionality. |
| What happens during a network outage? | It depends on where the FloorPulse server sits relative to the failure. If the server, workstations, and printers are all on the same switch or network segment, production continues uninterrupted — FloorPulse runs entirely on the local machine with no internet dependency. If the server is on the opposite side of a failed router, WAN link, or inter-building connection, workstations lose access. Recommendation: place the FloorPulse server as close to the production floor as possible — same room, same switch, same network segment as the workstation tablets and printers. For harsh production environments, consider an industrial fanless PC such as the OnLogic Karbon 803 or 804 (designed for dust, vibration, and temperature extremes common on mail production floors). This eliminates the dependency on upstream network infrastructure and IT closets. |
| Does the product support audit logging? | Yes. Every scan, print, reprint, job creation, job status change, and configuration change is logged with timestamps. Logs are queryable via the built-in UI and directly via SQL. Application logs are written to an ACL-restricted log directory on the host. |
| Can the product be uninstalled cleanly? | Yes. Uninstall via Windows Add/Remove Programs (or the installer's uninstall) removes the service, application, and bundled PostgreSQL. The data directory can be retained or deleted at your choice. |
| Insurance coverage | Errors & Omissions (E&O) and Cyber Liability insurance are being evaluated. Details will be available upon request once coverage is in place. |
| Does the product contain AI, machine learning, or LLM components? | No. FloorPulse contains no artificial intelligence features, no machine learning models, no large language model integrations, and no neural networks. All data processing uses deterministic algorithms — fixed-width record parsing, barcode lookup, SQL queries, and ZPL/PDF generation. No customer data is sent to any AI service, cloud inference endpoint, or training pipeline. The product does not use AI to make decisions, generate content, or analyze data. For organizations with policies restricting AI in production systems, FloorPulse is fully compliant — it is conventional software that does exactly what its code specifies, nothing more. |
| Deployment model | On-premises, single machine, native Windows Service |
| Internet required | No. Optional for update checks and license renewal. |
| Data egress | None. Production data never leaves the server. |
| Outbound domains | floorpulse.net, api.github.com — all optional, all HTTPS, all read-only |
| Inbound ports | 5000 (HTTP), 5001 (HTTPS) — LAN only. Optional Routing module: 5010 / 5011 (HTTP/HTTPS) + controls socket 10100, all LAN-only. |
| Outbound LAN ports | 9100 (thermal printers), 631 (laser printers via IPP) |
| Software installed | None to pre-install — the signed installer bundles .NET, PostgreSQL 17, and all dependencies. |
| Auto-updates | Never. Updates require manual IT action. |
| Telemetry | None. |
| Remote access | None built in. Vendor has no access to your installation. |
Questions? Contact contact@floorpulse.net
Generates a formatted PDF with today's date for your compliance records