IT & Security Onboarding

A reference for municipal and county IT departments evaluating Motrix Cloud for a fleet or paratransit maintenance shop. This guide describes the documented application and deployment model. Confirm the deployed version and hosting controls with Motrix during your review.

1. Architecture & Deployment

• SaaS, zero-install web application. No agent, daemon, or executable runs on county workstations.
• No specialized hardware. Existing smartphones and tablets serve as inspection devices through the browser interface.
• No local server footprint. A standard modern web browser is the only requirement.
• Hosting: The active standard-tier production and demo applications use DreamHost shared hosting. The separate AWS HIPAA environment is paused.
• Stack: Laravel 13 on PHP 8.4+, MySQL 8.0, server-rendered Blade templates with Tailwind CSS and Alpine.js, assets built with Vite 8. Dependency audits run in CI on every build.

2. Network Surface (for whitelisting)

Motrix communicates outbound only over HTTPS. No inbound ports, VPN tunnels, or firewall rule changes are required. The documented browser endpoint is below. Confirm any additional domains and mail-sender settings during onboarding:

3. Security & Data Handling

• Encryption: TLS 1.3 in transit. The paused HIPAA reference architecture specifies encrypted AWS storage; verify storage and backup controls for the actual deployment during review.
• Access control: Role-based (Admin, Shop Manager, Driver, and more), with per-user permission overrides.
• Isolation: Company-scoped application queries in a shared standard-tier database; this is not a separate database per customer.
• Backups: Nightly encrypted database backups through failure-sensitive pipelines with atomic publication — a backup that fails partway is never published as if it succeeded — plus weekly file archives. Scheduled jobs are guarded against overlapping runs.
• Authentication hardening: Login and password-reset rate limiting; optional TOTP two-factor authentication (any authenticator app, no SMS). One-time and recovery codes are consumed under a database lock so a code can never be replayed, and "remember this device" cookies carry a server-validated expiry.
• Upload limits: Image uploads are capped at 20 million decoded pixels, and thumbnail generation enforces the same cap, so a crafted image cannot exhaust server memory.
• Immutable records: Filed inspections, defect-resolution history, parts stock movements, and access logs are append-only at the data layer. Companies with retained audit or readiness records cannot be hard-deleted from the platform admin — they are deactivated instead.
• Data ownership: The county retains full ownership of all maintenance and inspection data, with export available at any time.
• No trackers: No advertising or third-party analytics trackers run on inspection workflows.

For a deeper security overview, including infrastructure hardening and independent assessment, see the Security Overview.

4. Browser & Device Support

• Primary: Google Chrome (latest 3 versions).
• Also supported: Microsoft Edge, Apple Safari.
• Legacy Internet Explorer: not supported.

5. Audit Readiness

DVIR inspections in Motrix are photo-verified, signed, timestamped, and immutable once filed — they cannot be edited or deleted after submission, and that guard is enforced at the data layer rather than by the absence of an edit button. This produces a defensible record suitable for FTA triennial reviews, and the export format supports FDOT audit requirements.

For a per-vehicle evidence bundle, an authorized manager can generate a vehicle audit packet: a ZIP with an evidence-index PDF (inspection items, signatures, measurements, defect resolution, maintenance, work orders, and an attachment manifest) plus the private attachments that are available. Packets cover up to one year, 500 records, and 50 MB of attachments; missing or inaccessible attachments are listed explicitly. Packet generation requires fleet-management and report permissions and is access-logged. A packet is supporting evidence, not a compliance certification.

6. Handling Rider PHI (if applicable)

If your workflow involves rider PHI, review the deployment with your privacy officer before entering data. The HIPAA environment is paused and is not accepting PHI onboarding. The documented privacy options are:

• HIPAA tier (paused) — the retained reference architecture describes a dedicated, single-tenant AWS instance under a signed Business Associate Agreement (BAA), with mandatory two-factor authentication and a 6-year, append-only access audit log that records who viewed, changed, or exported each rider record. Document downloads are audited too, and reads of rider records fail closed: if the audit entry cannot be persisted, the record is not served. Device-local inspection drafts are disabled on HIPAA-tier instances without claiming to prevent user downloads, screenshots, or other device storage.
• Client Code mode — the agency stores no rider identities in Motrix at all, only opaque codes (for example C-0001), keeping the name↔code crosswalk on its own systems.

7. Verification & Next Step

Whatever next step is most efficient for your team:

• The live production environment is accessible from any modern browser at app.motrix.io — inspect it directly.
• We will complete any standard security questionnaire or vendor-onboarding form your office uses — send it over and we will turn it around promptly.
• Prefer a call? We will answer technical questions directly.

Confirm the above is sufficient to proceed, send us your security questionnaire, or book a short technical call — email sales@motrix.io. If additional documentation is required from our side, tell us what is needed; we would rather provide complete information upfront than cause delays.