Legal
Security
Last updated
Businesses trust Recoatly with their customers' details, their schedules and their money. This page describes how we protect that information, plainly and without claiming more than we do.
Our approach
Recoatly is deliberately simple: one application and one database, built with no third-party code libraries on the server, which removes a common source of supply-chain risk. Fewer moving parts mean fewer places for things to go wrong.
We are a small company and don't currently hold certifications such as SOC 2 or ISO 27001. We are happy to answer security questionnaires: contact us through the contact page at https://recoatly.com/contact.
Hosting and data location
Recoatly runs on a virtual machine with persistent disk storage in a single United States region of our hosting provider. The database and uploaded files live on that disk. Whether data at rest is encrypted depends on the disk and storage encryption offered by our hosting provider. Backups are encrypted and kept in object storage, separate from the server.
In production, Recoatly refuses to start unless its public address uses HTTPS and its data directory has been explicitly configured, and it will not run while the demo account still has its published password.
Encryption in transit
All traffic to Recoatly in production uses HTTPS. We send HTTP Strict Transport Security (HSTS) headers so that browsers only connect over HTTPS, we upgrade any insecure requests, and our cookies are marked Secure.
Passwords and sign-in
- Passwords are hashed with scrypt, a deliberately slow, memory-hard algorithm, using a unique random salt for each password. We never store your password in readable form.
- Passwords must be at least 8 characters, and very common passwords are refused.
- Sign-in, sign-up, password resets, email confirmation, invitations, customer links and public forms are rate-limited to slow down guessing and abuse.
- Signing in takes about the same time whether or not an account exists, so the sign-in form cannot be used to find out who has an account.
- Sessions use long random tokens that we store only as hashes. The session cookie is HttpOnly, SameSite=Lax and Secure, and expires after 30 days.
- Changing or resetting your password, or changing your sign-in email, signs you out of your other sessions. Password-reset links work once and expire after an hour, and a new email address must be confirmed before it replaces the old one, which we notify.
Permissions and data isolation
- Company isolation. Every query that reads or changes a company's records is limited to that company, enforced where the data is read rather than by hiding buttons. Automated end-to-end checks test these boundaries.
- Roles. Owner, Administrator, Operations manager, Dispatcher, Sales rep, Field technician, Bookkeeper and Read only, with permissions you can adjust for each person. A technician sees only the jobs assigned to them, and a bookkeeper sees the money but not the crew's pay rates.
- API keys act as the person who created them, limited to read or write access. They can never manage billing, the team, settings or integrations, are stored only as hashes, and can be revoked at any time.
Application security
- A strict Content-Security-Policy allows scripts only from Recoatly itself (plus privacy-friendly analytics, when switched on), blocks plugins, and stops other websites from framing our pages.
- Security headers prevent content-type sniffing and clickjacking, limit browser features such as the microphone and payment APIs, and isolate our pages from windows opened by other sites.
- Links to your customers' estimates, invoices and contracts use long random addresses, are kept out of search engines, and don't reveal their address to other websites through the referrer.
- Links in emails and texts are always built from our own configured address, never from details in the incoming request, so nobody can trick Recoatly into sending a link that points somewhere else.
- Requests are size-limited and validated, and the sign-up and contact forms include traps for bots.
Uploaded files
Photos, documents and other uploads are checked against a list of allowed file types, and formats that can carry scripts, such as SVG and HTML, are refused. Each file is stored under a long random name in a folder for its company and served with a sandboxing policy, so it can never run as part of Recoatly. Files that browsers cannot safely display are downloaded rather than opened. Anyone who has a file's link can open it, so share links only with the people they are meant for.
Audit log and monitoring
Recoatly keeps an audit log of significant actions — who did what and when, with their IP address and browser — which owners and administrators can review. Server logs and error alerts help us spot and investigate problems. Webhooks we receive from Stripe and Twilio are verified by their signatures, and webhooks we send to your systems are signed with HMAC-SHA256 and a timestamp so that you can verify them.
Payments
Card details are entered on Stripe's payment pages and never reach our servers. Subscription billing and your customers' online payments are processed by Stripe, which is certified as a PCI Level 1 Service Provider.
Backups and recovery
The database is backed up to encrypted object storage, separate from the server, and a consistent snapshot is taken automatically before every database upgrade. Backups are kept for up to 90 days, so data deleted from Recoatly is gone from our backups within 90 days.
Credentials and secrets
The credentials Recoatly uses to reach payment, email, text-message and AI providers are kept in the server's environment, never in the database, so they cannot leak through a backup or an export.
Privacy by design
- Crew location sharing is off until each technician turns it on, records only while they are on the clock, and is deleted after 14 days, or immediately when they turn it off.
- AI features send information to our AI provider only when someone uses them, and it is not used to train AI models.
- No advertising or tracking cookies, and no third-party scripts on our pages other than privacy-friendly analytics, when switched on.
- Our people access Customer Data only when they need to: to run the service, to help with a support request, to keep Recoatly secure, or to comply with the law.
Our Privacy Policy and Data Processing Addendum explain how we handle personal data.
What you can do
- Use a strong password that you don't use anywhere else.
- Give each person the least access they need, and remove people as soon as they leave.
- Revoke API keys you no longer use, and protect the systems that receive your webhooks.
- Send customer links only to the customer they are for.
- Review the audit log from time to time.
- Store exports carefully: they contain your customers' details.
Reporting a vulnerability
If you believe you have found a security problem in Recoatly, please tell us through the contact page at https://recoatly.com/contact, with enough detail for us to reproduce it. We will acknowledge your report and keep you informed while we fix it.
We won't pursue legal action over good-faith research that stays within these limits: use only your own account and don't access, change or keep other people's data; don't degrade the service for others, including through denial-of-service attacks, spam or social engineering; and give us reasonable time to fix the problem before you disclose it. We don't currently offer a paid bug bounty.
If something goes wrong
If we learn of a security incident affecting your data, we will act quickly to contain and investigate it. If a personal data breach affects your data, we will tell you without undue delay, and within 72 hours of becoming aware of it, with what we know and what we are doing about it, as our Data Processing Addendum sets out.