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 runs as two Docker containers on a single machine inside your network. 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.
Docker is process isolation, not a virtual machine. The FloorPulse container shares the host OS kernel but has its own filesystem and network namespace. It starts in under a second, uses ~200 MB of disk, and runs at native speed.
The database runs in a separate container with its data stored in a persistent volume on the host disk. Updating either container does not affect the data.
Docker Engine is Apache 2.0 licensed (free, open source). On Windows, Docker Desktop is free for companies under 250 employees. No licensing cost for the containerization layer.
FloorPulse includes its own PostgreSQL instance inside a Docker container. 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 volume lives at a known 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 Docker container health 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 — reads a static JSON file once daily to check for available software updates. Read-only GET request. No data is sent. | Optional |
ghcr.io |
443 | HTTPS | Docker image download — pulls updated FloorPulse container images when IT runs the update command. Only used during manual updates. | Optional |
api.github.com |
443 | HTTPS | License auto-renewal — checks for a renewed license key file. Read-only GET. Only active if a GitHub token is configured. Can be skipped entirely (paste license manually instead). | Optional |
All three outbound rules are optional. FloorPulse operates fully offline. Without internet access: updates are applied via USB (download image 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 CUPS/IPP | Optional |
| Service | Port | Protocol | Purpose | Scope |
|---|---|---|---|---|
| PostgreSQL | 5432 (default) | TCP | Database — only the FloorPulse application container connects. Not exposed to the network. | Localhost |
FloorPulse checks for updates by fetching a static JSON file from floorpulse.net. This is a read-only HTTP GET — no data is sent, no credentials are transmitted, no cookies are set. The response contains only the latest version number and a summary of changes.
docker compose pull && docker compose up -d at a convenient time.tar.gz file to the FloorPulse server via USB drivedocker load < floorpulse-server.tar.gzdocker compose up -dUpdates 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, Windows Server 2019+, Ubuntu 22.04+ | Any OS that runs Docker (Windows or Linux) | |
| Software | Docker Engine (Linux) or Docker Desktop (Windows/Mac) | No other software dependencies. No .NET, no PostgreSQL, no Java. | |
| Network | Ethernet connection on the production floor LAN | Wi-Fi is acceptable for the server but wired is recommended | |
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: March 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. Docker containers on customer-owned hardware. 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 PostgreSQL database running in a Docker container. Data is stored in a Docker volume 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 container. 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. Three outbound HTTPS endpoints are used for update checks (floorpulse.net), image downloads (ghcr.io), and license renewal (api.github.com). All are read-only GETs. The product functions fully without internet. |
| What ports does the product use? | Inbound: 5000 (HTTP), 5001 (HTTPS) — LAN only. Outbound LAN: 9100 (thermal printers), 631 (laser printers). Internal: 5432 (PostgreSQL, localhost 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 | An emergency password can be configured in the server's local configuration file (appsettings.Production.json). This is a fallback for situations where the database is inaccessible. |
| How are security vulnerabilities identified? | Automated CI/CD pipeline on every code push and weekly schedule: NuGet vulnerability scan (dotnet list package --vulnerable), Docker image scan (Trivy — fails on CRITICAL/HIGH), static analysis (GitHub CodeQL for C# and JavaScript — detects SQL injection, XSS, path traversal). Dependabot monitors NuGet packages, Docker base images, 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 + image 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 Docker image updates. The application checks floorpulse.net/updates/latest.json daily and displays an in-app notification when an update is available. Security patches are flagged with a non-dismissable red banner. Updates are never automatic — IT must run the update command. 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 runs as an embedded application database inside a Docker container, 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. |
| Container security | Docker containers run as non-root where possible. The application container uses the official Microsoft .NET ASP.NET runtime image. The database container uses the official PostgreSQL image. Both are pulled from trusted registries (MCR and Docker Hub). |
| Host OS hardening | Customer-managed. FloorPulse requires only Docker Engine. Host OS selection, patching, and hardening are the customer's responsibility. |
| Logging and monitoring | Application logs are written to a Docker volume. 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 mounting the log volume. |
| 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 (Docker restart: unless-stopped). |
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 | Install Docker on a spare machine, drop in compose file + license key, docker compose up -d, 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 database container, or volume-level snapshots of the Docker pgdata volume. Restore to any machine with Docker installed. |
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). Frontend: JsBarcode (barcode rendering, MIT), SignalR client (Microsoft, MIT). All dependencies are compiled into the Docker image — 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 image. The Docker image is built from official Microsoft base images (MCR). Image digests can be pinned for reproducible builds. |
| 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 Docker image 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 Docker image 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. Previous Docker image versions are retained locally. Rollback: change the image tag in the configuration file and restart. Takes under 30 seconds. |
| 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. The only outbound connection is an optional daily HTTPS GET to check for software updates. This request contains no customer data, no telemetry, no usage statistics. It reads a static file and compares version numbers. This can be disabled by not whitelisting floorpulse.net. |
| 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? | No. The application runs inside Docker containers. It does not modify the host operating system, install system services, or write to system directories. |
| 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 a persistent volume. |
| Can the product be uninstalled cleanly? | Yes. docker compose down -v removes all containers and data volumes. docker rmi removes the images. Nothing remains on the host. |
| 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, Docker containers |
| Internet required | No. Optional for update checks and license renewal. |
| Data egress | None. Production data never leaves the server. |
| Outbound domains | floorpulse.net, ghcr.io, api.github.com — all optional, all HTTPS, all read-only |
| Inbound ports | 5000 (HTTP) and optionally 5001 (HTTPS) — LAN only |
| Outbound LAN ports | 9100 (thermal printers), 631 (laser printers via IPP) |
| Software installed | Docker Engine only. No other 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