How your data is protected

Your time data is your livelihood — often literally — so keeping it safe and yours is part of the product, not an afterthought.

Two questions matter here: who can reach your data, and what happens if something goes wrong. Most of this page is the first — the security that keeps it yours day to day. Backups are the safety net underneath.

Encrypted in transit and at rest

Everything between you and ProjectPacer travels over HTTPS — nothing about your account crosses the network in the clear.

The secrets you connect are encrypted a second time, on top of that, before they're ever written to the database — with AES-256-GCM, the current standard:

• your calendar feed URL (itself a private link),
• your Clockify API key, if you connect it.

Each is decrypted only for the instant it's used to make a request, and never leaves in an export.

Your password

Passwords are hashed with bcrypt and never stored in a form anyone can read back — not us, not someone who obtained the database. Changing your password immediately revokes every existing session, so a stolen or stale cookie stops working the moment you reset.

Sessions and sign-in

Your session cookie is httpOnly (invisible to page scripts, so a script injection can't steal it), secure (HTTPS only), and sameSite (won't ride along on a cross-site request). Sign-in is rate limited, so a password can't be found by hammering the login endpoint.

Access control

Your data is walled off at two levels, both enforced on the server — not merely hidden in the interface:

• Between workspaces — every query is scoped to the workspace you're in. A member of one workspace cannot reach another's data, full stop.
• Within a workspace — roles & permissions decide who opens what. Money is gated on its own, and split in two — what work bills at, and what it costs. Members and viewers get neither by default; seeing what work costs — including what people are paid — takes the See costs permission, a deliberate grant.

Every privileged action taken on your workspace is written to an append-only audit log, so nothing happens to it without a trail.

Guardrails against the classics

A couple of whole categories of attack are closed off by design:

• No SSRF. When ProjectPacer fetches a calendar feed you provide, the address is validated — and re-validated on every redirect — so a malicious feed can't trick the server into reaching private network addresses.
• No trackers in the middle. There are no analytics or advertising scripts in the app, so your time data isn't copied to anyone's dashboard as a side effect of using it. The complete list of services that ever receive anything is in What we collect.

Deletion that's hard to undo by accident

Deleting an account or a workspace destroys nothing immediately — it opens a 30-day grace window where the data is locked but fully restorable, and only then does a cleanup erase it for good. See Export & delete your data.

Backups, if the worst happens

Security keeps your data yours; backups make sure it's still there. They're layered on the 3-2-1 rule — three copies, two kinds of storage, one held somewhere else — so no single failure (a bad deploy, a dead disk, even losing our hosting account) takes it with it:

• Render Managed Postgres — automated daily backups plus point-in-time recovery, which rewinds to a moment rather than a day.
• Cloudflare R2 — a nightly copy, AES-256 encrypted before it leaves our server, kept for 30 days and held with a separate provider so it survives losing Render entirely.

We periodically restore from that off-site copy to confirm it rebuilds a working database — a backup nobody has restored is a guess. These are disaster recovery for the whole service, not a per-account undo.

You can keep your own backups, too. Nothing here is a lock-in: you can export your data any time — for billing, for your records, or just to hold a copy somewhere you control.