How Lodge keeps your company safe.

Normal personNerd

Part I

The short version

01. Why I take this personally.

When a company moves its work into Lodge, it trusts me with its messages, its customers and its plans. I don't take that lightly.

I studied cybersecurity in school, and I've worked in the field for the two years since. That's my whole career so far. I'm young, but this is the work I chose on purpose, and I happen to understand it deeply. Lucky for you, the person building Lodge is a security person first.

I care about protecting your data as well as I possibly can. Smaller companies get attacked too, and they usually have fewer people to call when it happens. I want Lodge to be the part of your setup you never have to worry about, and I'd rather you know exactly where you stand than take my word for it.

So this page says plainly what we can see, who else handles your information, and what Lodge doesn't do yet. If you want to go deeper, I'll walk you through it myself.

Drake Bellisari

Talk to me about security

02. What we can see.

Who can read what's in your workspace, and what that means for us.

2.1Your team

Everyone you've let in.

Shared work: tasks, projects, channel messages, the calendar, customers, documents and tickets. Inside your company Lodge is open by design, so every active member can read and edit it.
Direct messages and their files: only the people in the conversation.
A message or comment can be changed only by the person who wrote it.

2.2Your administrators

The people you put in charge.

Who is allowed in, and who is waiting to be let in.
Which other apps are connected to Lodge.
The audit log: every administrator action, and every time a file is opened or downloaded.
Not your direct messages. In Lodge, those stay between their people, administrators included.

2.3Lodge (us)

Because we run it.

We set up and run your workspace's database and hosting from our own accounts. That means the people who run Lodge hold keys that can open everything in it, direct messages and files included.
We use that access only to set your workspace up, to help when you ask us to, to keep it secure, or when the law requires it.
Opening your database through our accounts isn't recorded in your workspace's audit log, which tracks what happens inside Lodge.
We also see what you send through this website's forms, and the request logs our hosting keeps: network address, page and time.

2.4What nobody at Lodge has

Your password. Lodge keeps none: you sign in with an emailed link or your company's Google account.
Your Google password. Google checks it; Lodge never sees it.
Your API keys. They're shown to you once and kept only as a scrambled fingerprint (a hash), so we can't read them back.
Card details. We don't take any.

2.5What we never do

Sell your information, or use it for advertising.
Train AI on it, or hand it to an AI company ourselves. The built-in assistant stays off unless your company turns it on.
Track you on this website. There are no analytics and no ad pixels, just one cookie that remembers light or dark.

03. Who else handles it.

A few companies run parts of Lodge for us. Each one handles your information only to do its part.

WHO	WHAT FOR	WHAT IT HANDLES
Supabase	Your database, sign-in and file storage.	Everything stored in your workspace, encrypted on its disks.
Vercel	Hosting for this website and your workspace.	Each request as it passes through, and standard logs of them.
Resend	Sending email.	The emails Lodge sends: sign-in links, and the notification and morning emails people choose, which name tasks and meetings.
Google	Sign-in and calendars, only if your company turns them on.	Who is signing in, and the calendar events Lodge reads and adds.
Apple, Google or Mozilla	Delivering notifications, if a person allows them.	Encrypted notifications they pass on but can't read.
Your own AI	Only if a member connects one, such as Claude or ChatGPT.	What that member asks it to read, under that member's or your company's own agreement with the AI company.

Your database stays in the region chosen when your workspace was set up: the Americas, Europe or Asia-Pacific.

Read the privacy policy

04. How it's protected.

The main locks, in everyday terms. The full technical version is in Nerd mode.

No passwords to steal: People sign in with an emailed link or their company's Google account. Lodge keeps no password at all, so there's none to leak or guess.
Invitation only: Someone who isn't on your list can't get in. New people wait until an administrator lets them in, and removing someone takes effect on their next click.
A database of your own: Each company's workspace has its own database, kept apart from every other company's.
Every request is checked: Every table in the database checks who is asking before it hands anything over. Someone who isn't signed in gets nothing at all.
Encrypted on the way and at rest: Everything travels over encrypted connections and is stored encrypted. The access Lodge keeps for connected calendars is encrypted a second time.
Uploaded files stay files: A file someone uploads can't run as a web page inside Lodge. Risky types download instead of opening, and every open and download goes in the audit log.
Limits on guessing: Sign-in links, the forms and the API are rate-limited, so repeated attempts are slowed down and then refused.
AI that sees only what you see: A member's own AI assistant reads only what that member can read, can add and update tasks but nothing else, and every call is logged. Each connection can be revoked, and an administrator can turn them all off.
One key per connected app: Each app that connects to Lodge gets its own key, shown once and stored only as a hash. A key can be replaced or switched off at any time.

05. How I run it.

Some of the most important protections aren't in the code. They're habits on the accounts that run Lodge.

Two-factor sign-in everywhere: Every account that runs Lodge (Supabase, Vercel, GitHub, Google and Resend) needs a second step to sign in, not just a password.
An encrypted laptop: The computer Lodge is run from has its disk encrypted and locks when it's left.
Secrets kept out of the code: The keys each workspace needs live in the hosting account's encrypted settings and on that encrypted laptop, with an encrypted backup. They're never written into Lodge's code.
Narrow keys: The key that creates workspaces reaches only the account that holds customers' databases, and nothing else.
Guards against mistakes: Lodge's own tools refuse to change a database they weren't meant for, and every change to a database's structure is written down, tested and checked before it's applied.
Daily backups: Every workspace's database is backed up each day, and each backup is kept for seven days.
Deleted when you leave: When a company stops using Lodge it can take a copy of everything, and we delete the workspace within 30 days. Copies in backups expire within a further 30 days.
Told quickly if something goes wrong: If a breach ever affects your company's information, we'll tell you without undue delay and help you tell anyone you need to.

06. What Lodge doesn't have yet.

Better to hear it from us than to find it out later.

An independent security certification (a SOC 2 report).
Single sign-on through SAML, or automatic account setup through SCIM.
Per-item permissions. Inside your company, shared work is open to every member.
Sign-in with Microsoft accounts. Email links work for anyone on your list.

If one of these matters to your company, tell me. It helps decide what comes next.

That's the short version. The full technical model is one switch away.

Switch to Nerd

Part II

The technical detail.

The same model, in full, for your IT person or a security reviewer.

07. Identity No passwords stored, anywhere.

People sign in with the Google accounts your Workspace manages, or with a one-time email link. A database trigger keeps every password blank, so a password sign-in can never succeed.

Only your Workspace gets in. When Google sign-in is on, three locks, each enough on its own:

Where the Google app is internal to your Workspace, Google's consent screen refuses everyone else.
The database refuses a Google account whose Workspace domain isn't yours.
Every Google sign-in is checked again for its hosted domain.

Signing in isn't enough: a session counts only once the person is active. New people wait as pending until an administrator lets them in; deactivating someone takes effect on their next request.

Email links never go to strangers, and the form answers the same either way, so it can't reveal who's on your roster. Link prefetchers can't use up a sign-in link.

Credential abuse was the way in for 22% of breaches · Verizon DBIR, 2025 (opens in a new tab)

08. Data access Row-level security on every table. Anonymous callers hold nothing.

The access model, said plainly: inside the company, Lodge is open by design. The sign-in gate is the boundary.

Every active member can read and edit shared work.
Direct messages and their files stay between their people.
A message or comment is edited only by its author.
Who gets in, connected apps and the audit log stay with administrators.

Google calendar tokens and calendar links are encrypted (AES-256-GCM) and never reach a browser. API-key hashes and webhook secrets live in a table only the server can read.

09. Files Uploaded files never run as pages.

A file is read under your own session first, so a file you can't see is simply not found.

Shown inline: PDFs, images, audio, video and plain text.
Downloaded instead: HTML, SVG, XML and unknown types.
Every non-PDF file carries a CSP sandbox.
Every open and download is written to the audit log.

10. Application Only scripts Lodge sent can run.

A Content-Security-Policy with a fresh nonce on every request.
Security headers on every response.
Database access through a typed, parameterised client.
Markdown can't load images from other servers, so a message can't quietly send data elsewhere.
Redirects are validated.
Rate limits are counted in the database, so they hold across servers.
Every privileged admin action is written to the audit log.

11. The assistant It can't see more than you can.

A member can connect their own assistant (Claude, ChatGPT, Cursor and others) over MCP with OAuth and PKCE. Every call runs as that member, through the same row-level security, so it sees only what they can.

Writes are tasks only: create and update, as the member. It never deletes and never sends messages.
Its tokens are stored hashed, scoped, expiring and revocable.
What it reads comes back fenced as data, not instructions.
Every call is logged by tool name, and an administrator can switch connections off for everyone.

The built-in assistant is off unless the company turns it on. When on, it searches as you, cites every answer, and writes nothing until you confirm.

12. Connected apps One key per app, stored as a hash.

API keys are random 256-bit values, shown once.
Keys are stored and compared as SHA-256 hashes.
Each key is scoped to one app, and can be rotated or disabled.
Outbound webhooks are signed with HMAC-SHA256 and a timestamp.
The API is rate-limited per app, and per network for bad keys.

A demo key, made in your browser. It works nowhere.

13. Operational Some protections are settings on the accounts, not code.

One Supabase project and one Vercel project per company, in Lodge's own accounts.
Two-factor sign-in on every operator account: Supabase, Vercel, GitHub, Google, Resend.
Daily database backups, kept seven days. No point-in-time recovery yet.
Secrets only in encrypted environment variables and an encrypted, backed-up local store; never in the repository.
The provisioning token is scoped to the organization that holds customer projects.
Schema changes only as numbered migrations, tested and guarded before they're applied.
A health check that verifies the database, not just the server.

Ask us exactly how your workspace is hosted and set up.

14. Known limits Written down, not discovered.

Presence and unread counts are best-effort. They never affect who can see what.
Rate limits fail open if the database can't be reached, so an outage never locks your team out.
When Lodge reads a calendar by link, it checks the address before connecting, but a DNS answer that changes between the check and the fetch isn't pinned.
The Google calendar grant lets Lodge read and write events on a person's calendars. Lodge reads only their primary calendar and writes only meetings made in Lodge; Disconnect in Settings revokes the grant at Google.

15. Not yet What Lodge doesn't have yet.

A SOC 2 report
SAML single sign-on or SCIM provisioning
Per-item permissions
Native mobile apps
Sign-in with Microsoft accounts (email links work for anyone on your roster)

Lodge doesn't have a SOC 2 report yet. We'll walk your reviewer through this model line by line and fill in your security questionnaire.

Ask about security

Want the deeper brief?

About 30 minutes with me. Bring your questions, or bring your IT person.

How your workspace would be set up, and exactly who can reach what.
Your security questionnaire, answered line by line.
Good habits for a team your size: sign-in, devices, phishing emails, and what to do when someone leaves.

No pressure, and no sequence of follow-up emails.