Security
Your load data is
somebody's whole business
Tracking touches customer names, lane rates, carrier relationships and driver phone numbers. This page is what we do about that, written so your IT team can check it rather than take it on trust.
- Hosting
- AWS, us-east-2
- Encryption at rest
- AES-256, customer-managed key
- Encryption in transit
- TLS 1.2 / 1.3 only
- Database backups
- 30 days, point-in-time
- Tenant isolation
- Scoped on every query
- Secrets
- AWS Secrets Manager
Your data at rest
Encrypted everywhere it is stored, with keys we control rather than defaults we inherited.
AES-256 on the database, under our own key
The Aurora PostgreSQL cluster is encrypted with a customer-managed KMS key rather than the AWS default, so key policy and rotation are ours to set. The backup key is replicated to a second region.
Every object store is encrypted
PODs, driver images and exported reports are all written to S3 with server-side encryption on by default — KMS on the buckets holding customer documents. Public access is blocked at the bucket level on all of them.
Thirty days of point-in-time recovery
Automated backups run continuously and are retained for 30 days in production, so the database can be restored to any moment inside that window. Deletion protection is on, so the cluster cannot be dropped by an errant apply.
No credentials in the code or the image
Every API key, database URL and third-party token comes from AWS Secrets Manager and is injected at task start. Nothing sensitive is baked into a container image or committed to a repository.
Your data in motion
Nothing crosses a network in plaintext, and the parts that hold data are not on the internet.
TLS 1.2 or better, no exceptions
The load balancer accepts TLS 1.2 and 1.3 on a restricted cipher policy and nothing else. Plain HTTP is answered with a redirect, never with content.
The database has no public address
Aurora, the caches and every worker sit in private subnets with no route in from the internet. Traffic to AWS services leaves through VPC endpoints rather than the open network, and the one egress path is a managed NAT gateway.
A hardened edge in front of the app
Production traffic reaches the application through Cloudflare, which absorbs volumetric attacks before they reach anything we run.
Who can see what
Isolation and least privilege, enforced in the query rather than in the interface.
Every query is scoped to your company
Multi-tenancy is a filter on the data access itself, not a screen that hides rows. A user's company is resolved from their session and applied to every read and write — there is no code path that returns another tenant's load.
Roles, and a genuinely read-only role
Super Admin, Admin and Tracking User each see and do different things. There is also a demo account type that is blocked from writing at the request layer, so a walkthrough cannot change your data even by accident.
Passwords are never stored
Only a salted hash is kept, and it is compared rather than decrypted. Nobody at TrackFlo can read a password, including us.
API keys are hashed and scoped
Keys are stored as SHA-256 hashes, so the database holds nothing usable if it is ever read. Each key is bound to one tenant and one type: an integration key cannot reach an inbox lookup, and an inbox key cannot reach the write endpoints.
Sessions live on the server and expire
The browser holds a signed reference, not your data. Sessions are stored server-side in Redis, expire after sixteen hours, and the cookie is HttpOnly and SameSite so it cannot be read by scripts or replayed from another site.
How we know
Detection that runs whether or not anyone is looking at it.
Continuous threat detection
GuardDuty watches account, network and workload activity, Security Hub aggregates the findings, and AWS Config records every configuration change so drift is visible rather than discovered.
A complete audit trail
CloudTrail captures every API call made against the infrastructure and ships it to a log group, so who changed what and when is an answerable question months later.
Images scanned on every push, then re-scanned
Amazon Inspector scans each container image as it enters the registry and keeps re-scanning it as new vulnerabilities are published, so a CVE disclosed after a deploy still raises an alert against the running image.
Alerts go to people, not a dashboard
Database memory, CPU credit, swap and replica-lag alarms page the team by email. An integration that stops responding raises a failure the same way rather than going quiet.
Got a security questionnaire?
Send it. We fill them in ourselves, we answer what we can evidence, and where the answer is "not yet" we say "not yet" rather than finding a form of words. If a control you need is missing, you will hear that on the first call rather than in month three.
See it against your own data
A founder-led demo, on your loads, with your questions about how any of this works.