Loading the page. Nothing has gone wrong.
Security
How your data is held
Server-side authorization, an audit log on every mutation, and a credential vault. This page is usually read by the person who can stop the purchase, so it is written for them.
- Authorization
- Server-side, every action
- Isolation
- Row-level security in Postgres
- Audit
- One event per mutation
- Hosting
- Self-hosted, region agreed
Four properties of the system
- Audit event per mutation
1
Audit event per mutation
Written in the same transaction. No event, no change.
- Layers of tenant isolation
2
Layers of tenant isolation
An orgId on every table, and row-level security under it.
- Credentials in the browser
0
Credentials in the browser
Decrypted server-side at the moment of the call, never serialised.
- Sub-processors, named
4
Sub-processors, named
Most of the stack is ours, so the list stays short.
The short version
Six answers, before the questionnaire.
Written plainly, and with no claim we would not repeat in writing.
- Authorization
- Every server action begins by checking the caller’s permission for that module and that verb. The browser is never asked. A test in the build fails if a single action is written without the check.
- Isolation
- Every record carries the organisation that owns it, and Postgres row-level security enforces it underneath the application. A query written wrongly returns nothing rather than somebody else’s freight.
- Credentials
- Your integration credentials are encrypted in the database and read only at the moment of a call. Not in environment files, not in the page source, not retrievable from a browser.
- Audit
- Every mutation writes an event with the user, the entity, the detail, the timestamp and the source address. Searchable and exportable by the roles you allow.
- Two-factor
- Time-based codes, required rather than offered, for owner and finance. Those are the accounts that can override an advance and read the company P&L.
- Your exit
- A full tenant export while you are a customer and on the day you stop being one. Nightly backups run off the box, and the restore is rehearsed rather than assumed.
Authorization & audit
A permission enforced in the browser is a suggestion.
The prototype this product replaces kept its rules in the page, which is how rules get bypassed at six on a Friday. Here they live on the server, in one place.
Every server action
The check comes first
Each action asserts the caller’s permission for a module and a verb — view, create, edit, delete, approve or export — against the matrix in your database. A sales agent’s scoping to their own book is applied in the query layer, so it holds for exports and reports as well as screens.
A static test in the build fails if any exported action is missing the check. It is not a convention anyone has to remember.
Every mutation
The audit event is not optional
Anything that changes a record writes an audit event in the same transaction. If the event cannot be written, the change does not happen. Administrative impersonation is audited like anything else, and cannot be done quietly.
- user
- action
- entity
- detail
- comments
- timestamp
- ip address
The credential vault
Each tenant’s integration credentials — the FMCSA key, the load-board secrets, the ELD token — are encrypted against your organisation and referenced by the integration record rather than embedded in it. They are decrypted server-side at the moment of an outbound call and never serialised into a page, an API response or a client bundle. They are deliberately not in environment files either: environment variables hold Harbor’s own platform credentials and nothing of yours, so adding a tenant is never a server configuration change.
Where your data lives
Self-hosted, on purpose.
Every part of the system runs on infrastructure we operate, in containers we can move. No vendor can hold your operating history, and no vendor’s outage becomes yours.
The components of the system, what runs each, and what it means for a customer
Database
What runs it
PostgreSQL 16, on infrastructure we operate.What that means for you
Row-level security is switched on, so tenant separation survives an application bug.Documents and files
What runs it
S3-compatible object storage.What that means for you
PODs, insurance certificates and generated PDFs. Never base64 in the database, never a public bucket.Background work
What runs it
A job queue inside Postgres.What that means for you
Compliance reminders, reports, webhook retries. No extra data store, and no third party holding your queue.Sign-in
What runs it
Auth.js with database sessions.What that means for you
Org-scoped, invite-by-link, password policy. Sessions live in your database, not in a token we cannot revoke.Transport
What runs it
Caddy with automatic certificates.What that means for you
TLS on every connection, renewed automatically. There is no unencrypted path into the application.Error tracking and analytics
What runs it
Self-hosted, cookieless.What that means for you
Stack traces stay on infrastructure we run. Error reporting is a common way data leaks to a vendor; here it does not leave.
Data residency
Because the whole system is a set of containers and two volumes, it runs wherever you need it to. The region is agreed before onboarding and written into the DPA — and on a single-tenant deployment it is an instance of your own, not a shared one with your rows tagged.
Encryption
In transit: TLS on every connection, certificates renewed automatically, no unencrypted route in. At rest: the database and object-storage volumes sit on encrypted disks, and per-tenant credentials are encrypted a second time at the row level — so a copy of the database is not a copy of your provider accounts.
Backups & recovery
An untested backup is a belief.
Freight records are the evidence behind an invoice dispute two years after the container moved. They are worth keeping properly.
- Nightly
- A full database dump and an object-storage sync, both written off the machine that serves the application. A backup on the same box is a copy, not a backup.
- Rehearsed
- Restores are practised against a clean environment before launch and after any schema change. An untested backup is not a backup — it is a belief.
- On demand
- A full tenant export — records, documents and audit history — that you take at any time, without asking.
- On the way out
- You export first. Deletion follows on a schedule written into the agreement, not whenever the account happens to close.
Sub-processors
A short list, because most of the stack is ours.
Self-hosting has an unglamorous benefit: very few third parties sit in the path of your data, and the ones that remain are named before you sign.
Sub-processors, what each handles, and the terms they sit under
Hosting provider
What it handles
The machines and encrypted volumes running the application, the database and object storage.Terms
Named in your DPA before signature, with the region agreed with you.Outbound email
What it handles
Invoices, rate confirmations, arrival notices and invitations. Content passes through; nothing is retained beyond delivery records.Terms
Behind a mailer interface, so it is replaceable without touching the product.Payment processor
What it handles
Your subscription billing, and nothing else. It never sees a load, a container, a customer or a carrier.Terms
The one deliberate exception to self-hosting: card processing cannot responsibly be run in-house.Provider integrations you switch on
What it handles
Carrier lookups, board postings, ELD positions, vessel milestones. Each receives only what the call requires.Terms
None is enabled by default. Every outbound call is written to your audit log.
Not sub-processors, because they are ours: the database, the object storage, the job queue, the reverse proxy, error tracking and website analytics. They appear on no vendor’s list because there is no vendor.
Stated plainly
What we do not claim.
Harbor TMS does not hold a SOC 2 report or an ISO 27001 certificate today, and this page will say so until it does. A badge nobody has audited is worse than no badge.
What a reviewer can have now: this page in writing, a signed DPA, a completed vendor questionnaire, and — on a single-tenant deployment — a review of the configuration your data will actually run on.
Report a vulnerability
Incident contact
Suspected vulnerabilities, exposed credentials and anything that looks like unauthorised access go to a monitored address, not a contact form.
We acknowledge it, establish the scope, and tell affected tenants what happened and when we knew. The audit log is what makes a scope statement possible rather than a guess — which is most of the reason it exists.