Security Statement

InfoLobby runs your business data, so how we store it, who can reach it, and what we do with it should not be a mystery. This page describes what we actually do, in plain terms.

Last updated September 4, 2026

Where your data lives

InfoLobby runs on DigitalOcean infrastructure hosted in Canada. That covers the application servers, the managed MySQL cluster that holds your records, and the S3-compatible object storage that holds your files.

Canada has adequacy status under the EU GDPR, which means personal data can move from the EU to Canada without additional transfer mechanisms. If your organization needs a formal Data Processing Agreement, contact us and we will put one in place.

Your data is isolated, not pooled

This is the part most platforms gloss over, so it is worth being specific.

When you sign up, InfoLobby provisions a real MySQL database of your own, with its own database user and its own credentials. Your tables are actual MySQL tables in that database. Your records are rows in those tables.

What that rules out matters as much as what it provides. Your records do not sit in a giant shared table alongside every other customer's, separated only by an account id column that one bad query could get wrong. There is no shared table to leak from, because the boundary is the database itself.

Files you upload go to managed object storage under a folder prefix that belongs to your account, and deleting your account deletes everything under that prefix.

The managed database cluster is not reachable from the public internet. It accepts connections only from our application servers, and the credentials for your database are held by the platform and never issued to anyone, including you. There is no connection string to leak, no password for you to rotate, and no exposed port for anyone to find. You reach your data through InfoLobby, through the API, or through an export.

Encryption

• In transit. The application is served over HTTPS. Connections to the managed database cluster and to object storage are made over TLS.
• Credentials at rest. Integration credentials (database passwords, S3 keys, FTP logins, SMTP passwords, OAuth tokens, third-party API keys) are encrypted in the database, not stored in the clear.
• Passwords. Account passwords are stored as bcrypt hashes. They are one-way. We cannot read them, and neither can anyone who gets a copy of the database.
• Your record data. Record content is stored in your MySQL database in readable form, because the platform has to query, filter, sort, and report on it. If you need field-level encryption for a specific column, that is something to design with us rather than assume.

Signing in

• Two-factor by default, based on location. When you sign in from a network we have not seen you use before, InfoLobby emails a verification code and will not complete the sign-in without it. This is on by default for every account.
• Google sign-in is available if you would rather not manage another password.
• Brute-force limits. Failed sign-ins are counted per account and per IP address, with lockouts on both. A locked account returns exactly the same response as a wrong password, so an attacker cannot use the error message to confirm that an address is registered, or that they succeeded in locking someone out.
• No account enumeration. Sign-in responses take the same amount of work whether or not the address exists, so response timing does not reveal who has an account. Password reset and signup emails are rate limited per recipient, so our servers cannot be used to send someone repeated mail they did not ask for.
• Session cookies are set Secure, HttpOnly, and SameSite=Lax.

Who can see what

Access is granted per workspace, with three roles:

Role	Can do
Read Only	View records, views, and reports. No changes.
Read & Write	Create, edit, and delete records.
Admin	The above, plus manage tables, fields, flows, and members.

A person only sees the workspaces they were added to. Someone invited to one workspace has no visibility into the rest of your account.

API keys

The public API is authenticated with bearer keys that you create and can revoke or rotate at any time. Keys are 32 bytes of cryptographic randomness, stored encrypted, and shown in full only once at creation.

Each key can be constrained, and we recommend constraining them:

• Read-only, so a leaked key cannot write.
• Scoped to specific workspaces, so it cannot reach the rest of your account. Workspace-level management is refused entirely for scoped keys.
• Restricted by IP address, so it only works from the server you intend to call from.

Personal keys act as you and inherit your permissions. Account keys are separate, are managed by admins, and never gain more access than their scope allows.

Outbound requests

Automations can call external URLs, which is a category worth being honest about.

Platform features that fetch a URL on your behalf (calendar feeds, link previews, image imports, integration endpoints) are validated before the request goes out. The target host is resolved and checked against private and internal address ranges, the connection is pinned to the address that was checked, every redirect hop is re-validated, TLS certificates are verified, and response bodies are never echoed back to the caller.

The HTTP bricks you write yourself in a flow are deliberately not restricted the same way, for the same reason a webhook step in any automation tool is not: calling your own internal endpoints is frequently the point. Those run with the permissions of the account that authored them, and flow authoring is an admin-level capability. Treat it accordingly when you decide who gets Admin.

What you choose to make public

Several InfoLobby features exist specifically to publish data, and they do exactly what you configure them to do:

• Web forms embedded on your site, which write into a table you choose.
• Public embeds and share links.
• Calendar feed URLs, where the unguessable URL is the only credential.
• Apps you publish to the App Market.

These are under your control, and configuring one to expose more than you intended is on your side of the line. Public endpoints are excluded from search engine crawling by default, but a URL you hand out is a URL that can be shared onward. Rotate or remove anything you no longer want reachable.

Deletion and recovery

• Deleted records, fields, tables, workspaces, and flows are captured for 30 days rather than destroyed immediately, so an accidental delete can be recovered. Restoration is handled by our support team.
• The managed database cluster runs on DigitalOcean's managed database service, which takes automated daily backups. These protect against infrastructure failure. They are not a substitute for your own exports.
• Closing your account removes your database and the files stored under your account's prefix.

Getting your data out

The trade-off in the section above is worth stating plainly: a database nobody can dial into directly is safer, but it also means you do not hold a connection string. So the ways out are deliberate, and none of them depends on us cooperating at the time you need them.

• A raw SQL dump. Workspace exports have an option to include a standard .sql file: table definitions plus all the data, per workspace. Load it into your own MySQL, hand it to a DBA, or just keep it as a plain backup. It is a normal SQL file with no InfoLobby-specific format to decode.
• A portable workspace archive containing schema, records, attachments, comments, views, reports, and flows. This is the one that imports into any other InfoLobby account.
• A spreadsheet export of any table from the grid, either the whole table or exactly what your current view is showing.
• The public API, which is how you would script a scheduled backup on your own infrastructure.

The SQL dump is the one that matters for this conversation. It means "we hold the database credentials" and "you can walk away with your database" are both true at the same time, which is the combination you actually want.

And if live direct access is a hard requirement, connect your own MySQL server instead. Your records then sit on infrastructure you administer, with exactly the access you are used to.

We mention all of this in a security document on purpose. Being able to leave is what keeps a vendor honest, and it means a problem on our side is never a total loss on yours.

Third parties we use

Provider	Purpose	What it sees
DigitalOcean	Hosting, managed MySQL, object storage	Operates the infrastructure your data sits on
Bunny CDN	Content delivery	Public assets you upload, such as email images
Postmark	Transactional email	Messages InfoLobby sends on your behalf
Stripe	Payments	Billing details. We never store card numbers.
OpenAI	AI features	Only the content sent as part of an AI request you trigger
Google Analytics	Public website analytics	Visits to our marketing pages, not your app data

A note on AI

AI features are opt-in and run only when you invoke them. When you do, the relevant content is sent to OpenAI for processing and the result comes back. It is not retained by us beyond your session, and OpenAI states that data submitted through its API is not used to train its models. If you never turn AI features on, nothing leaves for AI processing.

How we work

• Security fixes are written with a failing test first, so the specific hole is proven closed and stays closed.
• We act on external security reports whether or not we asked for them. An unsolicited third-party review in August 2026 is what produced the authentication throttling, mail throttling, deferred account provisioning, and outbound request controls described above. We would rather be told than be right.
• Platform access is limited to the people who need it to run the service.

Where we are honest about limits

InfoLobby is a small, independent company, and we would rather tell you what we do not have than let a compliance page imply otherwise.

• We do not currently hold SOC 2 or ISO 27001 certification.
• We do not offer customer-managed encryption keys or field-level encryption at rest.
• We do not run a paid bounty program. Our Open Bug Bounty listing (below) is coordinated disclosure, not cash rewards.

If your procurement process requires any of these, talk to us before you commit. We would rather tell you no early than surprise you later.

Reporting a vulnerability

Email support@infolobby.com with the details and steps to reproduce. We investigate every report, we will tell you what we found, and we will not take legal action against anyone reporting a genuine issue in good faith.

We also participate in Open Bug Bounty, which handles coordinated disclosure and keeps a public record of what was reported and how it was resolved.

Please do not run automated scanners against production, and do not access, modify, or exfiltrate data belonging to another account while testing.